[design] Integrate debug module into Mocha top

[marnovandermaas]

Based on https://github.com/pulp-platform/riscv-dbg/tree/master

Part of this task includes:

• Integrate the RTL like we did for SPI device in this PR: [hw,fpga] Add SPI device hardware #259
• Use the correct memory map as declared here: https://github.com/lowRISC/mocha?tab=readme-ov-file#memory-map
• The debug module must be a manager on the AXI crossbar.
• Add a section to our readme to say how we can use the debug module with the Genesys 2 board.

[PRugg-Cap]

Thanks for the guidance, and sorry for the delay with getting started on this.

The debug module is instantiated here, and is completely unmodified for CHERI currently:
https://github.com/Capabilities-Limited/cheri-cva6/blob/cd6e8d029ea66d1d3dbec8c8c8fb942b139403f3/corev_apu/fpga/src/ariane_xilinx.sv#L441

It has 4 interesting ports:

• Some interactions directly with the CPU, e.g. an interrupt-like wire to request entering debug mode, which should be easy enough to hook up.
• A DMI "debug module interface" port that is converted to JTAG here: https://github.com/Capabilities-Limited/cheri-cva6/blob/cd6e8d029ea66d1d3dbec8c8c8fb942b139403f3/corev_apu/fpga/src/ariane_xilinx.sv#L401. Presumably it's okay for me to instantiate that IP.
• A subordinate port for requests from the core. That's converted to AXI here by yet another IP, which hopefully is suitable to instantiate https://github.com/Capabilities-Limited/cheri-cva6/blob/cd6e8d029ea66d1d3dbec8c8c8fb942b139403f3/corev_apu/fpga/src/ariane_xilinx.sv#L477
• A manager port for access to the system bus. This is converted to AXI by yet another component here: https://github.com/Capabilities-Limited/cheri-cva6/blob/cd6e8d029ea66d1d3dbec8c8c8fb942b139403f3/corev_apu/fpga/src/ariane_xilinx.sv#L650.

I'll try to get something initial together this evening or tomorrow.

[PRugg-Cap]

@marnovandermaas @raylau1 Started on this, but hit a roadblock fairly quickly. I was copying over the pin constraints from the upstream SoC, and seems the SPI device is using the pins the JTAG needs, namely W27-29 and AD27. Do you have any thoughts on how to proceed?

[marnovandermaas]

@PRugg-Cap thanks for looking into this. Please feel free to disconnect the SPI device from the JTAG for now to get the debug module working on FPGA. You should also be able to get this running in simulation using OpenTitan's JTAG DPI.

[PRugg-Cap]

Okay, makes sense: thanks!

[alexandrecapltd]

I had a go at trying to setup the debug module in simulation. So far I have done the following:

• I vendored in the pulp riscv-dbg (hw/vendor/pulp_riscv_dbg.vendor.hjson)
• I edited the vendored lowrisc_ip (hw/vendor/lowrisc_ip.vendor.hjson) to also pull the jtagdpi and tcp_server ips
• I added a jtagdpi instance in hw/top_chip/dv/verilator/top_chip_verilator.sv, and connected it up to jtag pins I exported out of the top_chip_system module
• I edited hw/top_chip/rtl/top_chip_system.sv to export jtag pins, added an instance of the riscv-dbg with the converter modules it needs (dmi_jtag for the debug module interface, axi_adapter for the master interface and axi_to_mem for the slave interface) and connected those to the rest of the system. I also connected the debug_req_irq to the CVA6 core, and swapped reset signals that previously used rst_ni to use ndmreset_n = (~ndmreset) & rst_ni
• I updated the SoC configuration in hw/top_chip/rtl/top_pkg.sv to reflect the presence on the bus of both of the debug module's axi interfaces, memory mapping the debug module at address 64'h0000_0000
• spent some time fixing some warnings / adding linter exceptions

The simulator is now building fine and I am able to see a printout of the jtagdpi listening on a port when running it.

On the testing front, I have taken the openocd configuration from opentitan earlgrey and tried to connect to the simulator. At this stage, from looking at traces, it seems we can see some traffic coming on the jtag interface to the debug module, eventually causing the debug irq to trigger, at which point CVA6 stops being verbose, at least on its noc_req signals. OpenOCD reports that the core failed to halt, so this is what we will be looking at next.

[marnovandermaas]

Conversation with Jon captured here:

Hey Marno!  I'm looking at the u_clk_mgr; is there a reset that you all had envisiged being used for the ndmreset_n?  The debug module spits out a reset that CVA6 and things connected to it are generally reset by.  I guess this should go through the new reset manager in some way?

Hi Jon, I tend to look at OpenTitan to see what is done there. It is connected here in the debug module: https://github.com/lowRISC/opentitan/blob/222916aeaa415d16f6aba9201a367f3d5447f78c/hw/top_earlgrey/rtl/autogen/top_earlgrey.sv#L2417 and is fed into the power manager: https://github.com/lowRISC/opentitan/blob/222916aeaa415d16f6aba9201a367f3d5447f78c/hw/top_earlgrey/rtl/autogen/top_earlgrey.sv#L1910 Let me know if that helps.

Ok, I'm a bit stuck in the mud.  In Earl Grey, there are lc resets and sys resets.  The lc  ones reset ~everything except the debug module, and sys  resets everything. This is documented here, and reflected in the source that you linked me to.
In the lowrisc/main branch of mocha (as of last week), in top_chip_system.sv, instead we have some io  signals and main  signals.  Deeper in the hierarchy, we do still have lc  and sys  signals, but when I chase them through, I can't convince myself that they correspond in some clear way to io  and main .
I guess Earl Grey and Mocha have diverged so much as far as resets are concerned that it's not possible to trivially pattern-match to hook up the debug module.  I suppose someone over there is trying to go in a new direction with the Mocha soc for some reason?  I guess whoever that is needs to think about what they are going to do about the ndmreset, and will need to solve the problem that was previously solved with the lc  and sys  signals.  (For all I know, they have something in mind, but I haven't been able to parse it yet!)

Yes, you're right that we have different reset domains in Mocha, I had stripped out the lc domain because Mocha does not have a life-cycle controller, but I think you're right that I do need separate lc and sys resets for the ndmreset input to the power manager to work. I saw another mistake where the debug enable for the power manager must be set to Off to be able to deal with NDM reset:

mocha/hw/top_chip/rtl/top_chip_system.sv

Line 898 in d051a93

.lc_hw_debug_en_i (lc_ctrl_pkg::On),

[marnovandermaas]

This issue is currently blocked on: #571

[marnovandermaas]

This issue should now be unblocked as #593 was merged which integrates a non-debug module reset in the reset manager and the Mocha top.