question on dmcs2

[田进]

I have some questions regarding the bit fields of the dmcs2 register.
1. When does hgselect take effect? Does it only function when hgwrite is asserted? Is it solely used to select whether to assign a hart or an external trigger to a specific group?2. If I only implement the hgselect field within dmcs
2: after I set hgselect to 1, will halting harts via the debug module work as intended? In other words, will the halt operation be masked when hgselect equals 1 at that moment?
3. My design contains only one hart and one external trigger. To achieve a minimal implementation, is it mandatory to implement the dmcs2 register entirely?

[Greg Favor]

On Thu, Jun 11, 2026 at 3:02 AM 田进 <sxti...@126.com> wrote:

I have some questions regarding the bit fields of the dmcs2 register.
1. When does hgselect take effect? Does it only function when hgwrite is asserted?

Yes, only when this register is written, and written with hgwrite=1.

 

Is it solely used to select whether to assign a hart or an external trigger to a specific group?

Yes.

 

2. If I only implement the hgselect field within dmcs
2: after I set hgselect to 1, will halting harts via the debug module work as intended? In other words, will the halt operation be masked when hgselect equals 1 at that moment?

As confirmed above, hgselect only has meaning when dmcs2 is being written with hgwrite=1.

 

3. My design contains only one hart and one external trigger. To achieve a minimal implementation, is it mandatory to implement the dmcs2 register entirely?

The dmcs2 register is not optional, but the spec says that all the fields are optional, i.e. they could be hardwired to zero.  In the extreme, the register exists and is accessible, but it is simply a hardwired read-as-zero register.

 Greg

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To view this discussion visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/686e2273-ff33-49c4-811e-da45aa959579n%40groups.riscv.org.

[田进（tian）]

thanks for your reply。1. I have not implemented group functionality, and there is one hart plus one external trigger in the design. Are they therefore placed in group 0 by default? 2. When referencing hart states described in Section 3.4 of THE RISC-V DEBUG SPECIFICATON, do we need to take into account the states of harts or non-hart devices associated with external triggers within the same group? 3. If the answer to Question 1 is yes: when the debug module asserts an internal haltreq to halt the hart, and the group sends a halt request to the external trigger,

should the local anyhalted/allhalted status signals reflect the state of the external trigger? The same uncertainty applies when issuing resume requests, as well as to any/all running/halted status signals in general. 4. If the answer to Question 1 is no, what is the specified behavior for the scenario raised in Question 3?

[田进（tian）]

In short，When a halt/resume group contains one hart and one external trigger, shall the allhalted, anyhalted, allrunning and anyrunning bit fields in the dmstatus register take the external trigger into account if it is unknown whether the external trigger is connected to a hart or a non-hart device

[Greg Favor]

These bits reflect the status of the currently selected harts.  It doesn't reflect the status of triggers (irrespective of where they come from).

Greg

[田进（tian）]

Thanks for your explanation. I confused several concepts before, but now it’s clear to me.