What is the meaning of dtmcs.dmihardreset?

[hyf6661669]

I find that many implementations about riscv-debug modules don't even use dtmcs.dmihardreset, but we can still debug these opensource cores by using riscv-gdb and openocd.

Below are some opensource cores that could be debugged successfully but their debug-module implementations don't use dtmcs.dmihardreset.

https://github.com/pulp-platform/ariane
https://github.com/riscv/riscv-isa-sim (The official riscv golden reference simulator only uses dtmcs.dmireset)
https://github.com/syntacore/scr1 
https://github.com/westerndigitalcorporation/swerv_eh1 (This core from WesternDigital don't use dtmcs.dmihardreset and dtmcs.dmireset, but can still be debugged)

It seems that I could just ignore this signal. Could you please give some information on when and how to use this signal?

Much thanks!

[timsifive]

I don't understand the question.

This bit resets the debug transport module, as the description says. Evidently it's not widely implemented. If there is no need to ever reset the DTM, that seems defensible.

The debugger would use the signal if for some reason the DTM is in a state where it can't perform accesses to the Debug Module.

[hyf6661669]

@timsifive Thanks, I just want to know whether it is a must to implement dtmcontrol.dmihardreset. I think your reply means that without dtmcontrol.dmihardreset we could also debug cores.

[quB123]

@timsifive So this bit is optional? If the implementation doesn't support these bit, could it still be advertised as conforming to the “RISC-V Debug Specification 1.0.0-STABLE, with JTAG DTM?”

[timsifive]

The spec as written says the bit is required. It seems like a very cheap bit to implement. Is this causing problems for you?

[quB123]

@timsifive Can we expect that after dmihardreset, the next dmi transaction will succeed, or it may still fail since we only reset the dmi state in DTM, but the transaction in DMI or the target debug module is still not completed yet, which may be the real reason that caused dmi transaction can't complete?

[timsifive]

dmihardreset only resets the DTM. If the Debug Module is inaccessible for some reason (DMI bus problem or whatever) then resetting the DTM won't resolve that. Maybe this bit should really be called dtmhardreset.

[AlphonseVA]

Hiya,

@timsifive Does the scope of all DTM registers for dtmhardreset include resetting the shift register of TAP controller, state register of TAP controller, and instruction register (IR) of TAP controller?

I understand this as that IR has to be already pointing to dtmcs, IR=0x11 with the bit 17 of DR being 1 when the TAP controller state is Update-DR state in order for dtmhardreset to take place. With this understanding, I interpreted that at the next cycle of TCK, the IR will need to reset and be pointing to IDCODE, IR=0x01. Similarly, the state of the TAP controller should reset back to Test-Logic-Reset. Implementing this feature can be slightly expensive as there will be a need to latched the condition of dtmhardreset_occured or a separate register that stores IR and is decoupled from the shift register.

On the side of the TAP controller, I can't find a good reason that we would be just saving 3 TCK cycles just for the TAP controller to enter Test-Logic-Reset state after Update-DR state where the dtmhardreset took place. In addition to this, won't this complicate the implementation of the debugger as the debugger would have to be also aware of the debugger issuing dtmhardreset so that the correct timing of TMS can be driven?

---

I am suggesting that that dtmhardreset should be reworded such that "returning all registers and internal state to their reset value" should not include the JTAG TAP controller in the DTM which would mean resetting the TAP controller registers like the shift registers and the instruction registers.

[timsifive]

Does the scope of all DTM registers for dtmhardreset include resetting the shift register of TAP controller, state register of TAP controller, and instruction register (IR) of TAP controller?

I think that is what the spec says, and I agree with you that there really isn't a good reason to require it.

Unfortunately we've stopped making substantive changes to the spec. I'm not sure if this qualifies as a bug that needs fixing, or simply something that could have been thought out better but we'll just have to live with. The cost seems to be an extra FF to store the value of dtmhardreset, and a little bit of logic to make the reset happen. That might be significant relatively to the TAP controller, but in the scheme of a RISC-V hart with Debug Module it seems insignificant.