The current default IOBinder for Debug Module does not punch out the ndreset (and hartResetReq)?

[DecodeTheEncoded]

Background Work

• Yes, I searched the mailing list
• Yes, I searched prior issues
• Yes, I searched the documentation

OS Setup

Not-relevant

Other Setup

Ex: Prior steps taken / Documentation Followed / etc...

Current Behavior

Hi Community,
Our team is taping out a chipyard based design and we have confusion on the JTAG interface. Currently, it seems that the iobinder for HasPeripheryDebug punched out only JTAGChipIO(4 wires) out of chip. After going thru the code, it seems that the ndreset are left unconnected, this means that the debugger can not write ndmreset field of dmcontrol to reset the whole system(except the DTM AND DM), also the system.resetctrl.hartResetReq seems also unconnected, indicating that we can not reset the specific hart by asserting hartreset in dmcontrol. So, If we leave the iobinder as it currently is, does this mean that there is no way for debuggers to forcefully reset the whole system or a speicific hart. Since this is our first tapout, I wonder if this is the default debugging configuration for other team that had tapped out chipyard based design before.
Can anyone shed some light into this? Any help will be appreciated. Thanks for you work.

Expected Behavior

See above

Other Information

No response

[DecodeTheEncoded]

@jerryz123 Jerry, sorry to bother, do you have any comment on this? Any reply will be very appreciated.

[jerryz123]

We haven't used the JTAG-driven reset in our test chips.

There is a PR right now to expose the reset pin for the JTAG state machine, but this isn't exactly what you are asking for.

We generally wire up the reset of the chip to the host FPGA, and use different FPGA bitstreams or FPGA capabilities to reset the chip during bringup, not JTAG.

For resetting harts, we haven't used hartResetReq. We instead use the TileResetter memory-mapped control registers, which we can write to with serial-TL. Resetting harts during execution is also risky... it can put the memory interconnect and caches in a weird state, so I personally try to avoid it.

I'd be open to reviewing and merging any PRs that add debug-module-driven-bringup features.

[DecodeTheEncoded]

We haven't used the JTAG-driven reset in our test chips.

There is a PR right now to expose the reset pin for the JTAG state machine, but this isn't exactly what you are asking for.

We generally wire up the reset of the chip to the host FPGA, and use different FPGA bitstreams or FPGA capabilities to reset the chip during bringup, not JTAG.

For resetting harts, we haven't used hartResetReq. We instead use the TileResetter memory-mapped control registers, which we can write to with serial-TL. Resetting harts during execution is also risky... it can put the memory interconnect and caches in a weird state, so I personally try to avoid it.

I'd be open to reviewing and merging any PRs that add debug-module-driven-bringup features.

Thanks for your reply, Jerry, I really appreiciate your comment on this. In terms of use different FPGA bitstreams or FPGA capabilities to reset the chip during bringup, I think this is very typical way to reset the system. But I have some confusion on the current Debug IOBinder, it seems that the the system reset will reset the whole soc, including the DTM and DM.

          d.systemjtag.map { j =>
            **j.reset := ResetCatchAndSync(j.jtag.TCK, clockBundle.reset.asBool)**
            j.mfr_id := p(JtagDTMKey).idcodeManufId.U(11.W)
            j.part_number := p(JtagDTMKey).idcodePartNum.U(16.W)
            j.version := p(JtagDTMKey).idcodeVersion.U(4.W)
          }

I think many people expect a debuging functionality that the core can jump right into the DebugROM out of reset. But it seems that there is no way to accomplish this under the current IOBinder configration because the system reset or power on reset will reset all part of SOC, including the TLDebugOuter which is in charge of handling the dmcontrol logic. Could you please confirm this? @jerryz123

[DecodeTheEncoded]

After pondering about this again, I feel like jumping directly to DebugRom out of reset is actually not very necessary if you use the current chipyard BOOTROM, the wfi keeps waiting for interrupts, and program counter will go nowhere without interrupts, therefore this is almost the same as jumping to DebugROM and wait for command from DMI. Even though the system reset also resets the DM and DTM, when the core is awake, you still can send the haltreq to the core through dmcontrol dmi register, the side effect is minor, because the core is wfi(waiting for interrupts), and will not jump out of BootROM.

[EmJunaid]

Hi @DecodeTheEncoded ,
I'm validating the Rocket-Chip's Debug Module to see what feature of RISCV Debug spec 0.13 it supports and below are my observations regarding ndmreset and hartreset:

• We don't need a physical pin at chip boundary for ndmreset. The way you use ndmreset to reset the chip (other than DM) is by writing to the ndmreset field of dmcontrol register. Once this field is written (via OpenOcd/gdb), the Debug Module asserts the ndreset, which is output of DM. Now this signal is available to the chip which can be OR with the chip level reset to reset the chip. Or you can have a bootstrap system that can take this signal and reset the whole chip. Currently this feature is not supported in Chipyard, Chipyard just don't use this output signal ndreset, even though writing to ndmreset of dmcontrol register does work. I have verified it by looking at waveforms!
• Similarly, Chipyard does not support hartreset feature. The Debug Module does support these both features, it's the Chipyard Platform that does not support both these features.

These are my observations and I could be wrong, do let me know if you figured out a way around these resets, I would love to know about it.