riscv-debug-spec icon indicating copy to clipboard operation
riscv-debug-spec copied to clipboard

Elaborate on version detection.

Open timsifive opened this issue 2 years ago • 4 comments

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.

timsifive avatar Jun 23 '22 16:06 timsifive

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).

pdonahue-ventana avatar Jun 23 '22 21:06 pdonahue-ventana

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?

timsifive avatar Jun 24 '22 16:06 timsifive

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.)

pdonahue-ventana avatar Jun 30 '22 21:06 pdonahue-ventana

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.

timsifive avatar Aug 19 '22 16:08 timsifive