Clarification on debug spec conceptual bits: resethaltreq vs halt-on-reset terminology

[nadime15]

I posted this on the mailing lists, but it seems the github repo is much more active.

The spec states that the Debug Module tracks 4 conceptual bits: halt request, resume ack, halt-on-reset request, and hart reset.

Later, when describing the dmcontrol register fields, it introduces the setresethaltreq and clrresethaltreq bits, which control the halt-on-reset functionality.

resethaltreq itself is described as “.. is an optional internal bit of per-hart state that cannot be read, but can be written with setresethaltreq and clrresethaltreq.”

Are “halt-on-reset request” and “resethaltreq” meant to refer to the same conceptual bit? In section 4.9.1, halt-on-reset seems to be dropped entirely, and only resethaltreq is mentioned.

If that’s the case, would it be more consistent for the spec to just use resethaltreq throughout (or halt-on-reset)? Or is there a subtle distinction I’m missing between these two terms?

[pdonahue-ventana]

I posted this on the mailing lists, but it seems the github repo is much more active.

What mailing list? The tech-debug mailing list is deprecated: https://lists.riscv.org/g/tech-debug/message/1876. The successor is the sig-debug-trace-perf-mon mailing list.

Are “halt-on-reset request” and “resethaltreq” meant to refer to the same conceptual bit?

Yes.

I count 8 places that refer to halt-on-reset and 5 that refer to resethaltreq. All 13 should use the same name. I prefer resethaltreq.

This can be batched up with some other clarifications that will eventually go in.

[nadime15]

What mailing list? The tech-debug mailing list is deprecated: https://lists.riscv.org/g/tech-debug/message/1876. The successor is the sig-debug-trace-perf-mon mailing list.

Ahh good to know, I was not aware of that, thank you!

I prefer resethaltreq.

Yes sounds good, me too!