You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The RISC-V spec (v0.13.2) defines the dmcontrol.haltreq bit with access "W" (Section 3.12.2), which is defined as "Write-only. When read this field returns 0" (Table 1.2). However, the current implementation allows this bit to be read as 1 after a write sets it to 1.
The text was updated successfully, but these errors were encountered:
I'm looking at the RISC-V external debug support spec, version 0.13.2 (e.g. here).
I think you're right about this behaviour. Looking at the code, the behaviour comes from dm_csrs.sv, where a read of DMControl is handled like this:
dm::DMControl: resp_queue_inp.data = dmcontrol_q;
(picking up all the bits of dmcontrol_q, including the halt request).
This code actually comes from the pulp project. I suspect we won't fix it locally (because it doesn't feel very important) and will take a fix by getting it fixed upstream and then vendoring in the change. Would you be happy to file a report there?
andreaskurth
changed the title
[top_darjeeling] dmcontrol.haltreq should always read as 0
[rv_dm] dmcontrol.haltreq should always read as 0
May 21, 2024
desc
The RISC-V spec (v0.13.2) defines the dmcontrol.haltreq bit with access "W" (Section 3.12.2), which is defined as "Write-only. When read this field returns 0" (Table 1.2). However, the current implementation allows this bit to be read as 1 after a write sets it to 1.
The text was updated successfully, but these errors were encountered: