riscv-debug-spec
riscv-debug-spec copied to clipboard
Elaborate on version detection.
The side effects only really occur in an extreme corner case.
I think. I don't remember anything about why this section was written, and I wonder if I'm forgetting about something.
I agree that the write doesn't need to happen if the initial read showed that dmactive=1. But does the write need to happen if dmactive=ndmreset=1? I question "or \FdmDmcontrolNdmreset is 1" since I didn't think that ndmreset caused dmstatus to become inaccessible.
And can the side-effects actually happen? If dmactive=1 then the new recipe says there's no write so there's no problem. If dmactive=0 then ndmreset=0 (the reset value), so a write of dmactive=1 and ndmreset=0 doesn't change that. Same thing with haltreq. And resumereq is W1 so writing 0 has no effect and this was never a problem. The only real side-effect is that the DM becomes active, though the spec correctly says that this isn't really visible outside the DM (until more writes are performed).
I agree that the write doesn't need to happen if the initial read showed that dmactive=1. But does the write need to happen if dmactive=ndmreset=1? I question "or \FdmDmcontrolNdmreset is 1" since I didn't think that ndmreset caused dmstatus to become inaccessible.
I included the bit about ndmreset, because the description of dmcontrol includes:
For forward compatibility, \FdmDmstatusVersion will always be readable when bit 1 (\FdmDmcontrolNdmreset) is 0 and bit 0 (\FdmDmcontrolDmactive) is 1.
And can the side-effects actually happen?
I'm not convinced that they can. But this was in the spec presumably for a reason. It must have come from something. Is there an older version of the spec where they can happen, just not in 1.0?
I see now. If dmactive=1 and ndmreset=1 then you'll do the write and not preserve ndmreset or haltreq or resumereq. That will definitely have side-effects for ndmreset and haltreq. It won't have an adverse effect on resumereq in 1.0 but it will in 0.13 (when resumereq was R/W instead of W1). And if dmactive=0 then you'll do a write which sets dmactive=1. So the recipe "might have" all 4 side-effects, though not all at the same time.
If the recipe preserved the value of ndmreset, haltreq, and resumereq in addition to hasel, hartsello, etc. then the first 3 could probably be avoided. Thoughts? (I don't have a strong preference since this would be a very unusual case.)
We can't preserve ndmreset, because:
For forward compatibility, \FdmDmstatusVersion will always be readable when bit 1 (\FdmDmcontrolNdmreset) is 0 and bit 0 (\FdmDmcontrolDmactive) is 1. which implies that version might not be readable when ndmreset is 1.
We can't preserve haltreq because it's WARZ.
We can't preserve resumereq because it's W1.
I still think this PR is good as written.