Upgrade on-chip-debugger

[stnolting]

This PR upgrades the NEORV32 on-chip debugger (OCD) to debug spec. version 1.0, which is fully backwards-compatible to version 0.13.

This PR also provides some major optimizations:

• reduce the hardware utilization of the OCD
• improve debugging speed and response time (optimized park loop)
• fixing minor rtl issues, design flaws and spec. incompatibilities
• fixed issue that openOCD cannot reconnect after the core is halted once
• much more stable operation of debugger

[GideonZ]

I am looking forward to testing this! Thank you for your amazing efforts on this project!

[stokdam]

Hi,
what do you mean with "fully backwards-compatible"? I'm working with a ProAsic3 device, for which I'm forced to use their modified version of openocd, which includes support for their proprietary FlashPro programmer. Unfortunately, this version is not updated, and only supports 0.13. If I try to connect to the latest version of neorv32 it gives the following error:

OpenOCD only supports Debug Module version 2 (0.13) not 3

If I manually set (in neorv32_debug_dm.vhd) the version number to 2, then I got the following error:

Error: unable to halt hart 0
Error:   dmcontrol=0x00000001
Error:   dmstatus =0x00400c82
Error: Fatal: Hart 0 failed to halt during examine()

Version 1.7.9 works fine,

[stnolting]

Hey @stokdam!

I'm forced to use their modified version of openocd, which includes support for their proprietary FlashPro programmer. Unfortunately, this version is not updated, and only supports 0.13. If I try to connect to the latest version of neorv32 it gives the following error:

I assume you are using some FPGA-specifc JTAG tap, right? However, you could still use some FPGA pins to connect an external JTAG adapter.

what do you mean with "fully backwards-compatible"?

Seems like I was way too optimistic there 😅

The main difference is that that the DM's haltsum0 register has been removed as there is only a single hart in the system. This is also noted in the RISC-V debug spec.:

[stokdam]

I assume you are using some FPGA-specifc JTAG tap, right? However, you could still use some FPGA pins to connect an external JTAG adapter.

The point is that only FPGA programming logic is directly exposed to "raw" JTAG. In order to access user instantiated modules, they developed a tunneling protocol which is implemented inside the openocd binary they distribute (I'm pretty sure there is a GPL violation there...).
More info here:
https://www.microsemi.com/document-portal/doc_view/1245255-corejtagdebug-hb

Unfortunately, using other FPGA pins is not an option.

[stnolting]

The point is that only FPGA programming logic is directly exposed to "raw" JTAG. In order to access user instantiated modules, they developed a tunneling protocol

Oh I see. I know this concept from Intel and Xilinx FPGAs. Good to hear that the Microsemi approach works so seamlessly - especially the Xilinx approach can be quite tricky... 😅

Anyway, it should not be too hard to re-add the missing DM register(s) that seems to be causing this backward-incompatibility issue. From a hardware point of view, this should not add too much additional logic, so I would be fine with this.

I can open a PR to work on this if you like, but you would be the one who needs to test the modifications 😉

[stokdam]

If there is not any other major incompatibility I'm fine. Wouldn't be better to stick with 0.13.2 at the moment? 1.0 became stable just a couple of months ago, and it is still not approved as standard.

[stnolting]

Good point! I think the best solution would be adding a new generic to select the actual version. I'll start a PR for this.