Closed timsifive closed 5 years ago
@gravikumar92, I assume you have an implementation that does something such that dmstatus.version is not accessible until dmactive is 1. How much more complicated does your design get if there is a requirement to always have dmstatus.version accessible? What other costs are there to that?
I have to check with the design team. As per our understanding, dmactive should be 1(init sequence) to read dmstatus register.
@gravikumar92 IMO the behavior of reading dmstatus should be unspecified when dmactive=0.
@aswaterman Even the version field, which should be a constant and isn't dependent on any system state? Is this because it's expensive to implement a register returning a constant when dmactive=0, some philosophical issue, or something else?
The dmactive bit in 0.13 holds the place of fullreset in 0.11. Always writing dmactive and then checking version would result in resetting 0.11 systems.
I think that you shouldn’t necessarily be able to connect to a system that has already powered itself down or clock gated or whatever dmactive is going to prevent.
"connect to a system" is not very specific. I think it would be nice to be able read the version field of dmstatus even when dmactive is 0. If the DM is completely powered down, this could be achieved by simply intercepting the read of dmstatus when dmactive is 0, and returning the constant with the correct version. That sounds pretty cheap.
In the end the question is: do we want to require slightly more hardware in 0.13, in order to be backwards compatible with 0.11. 0.11 was not widely implemented, but the 0.13 hardware cost is also low.
Ok, it seems like we would perhaps want an exception for reading DMSTATUS (or even only DMSTATUS.version?) even when dmactive=0? But that's not a strictly backwards compatible change for either SW or Hardware... if it was vague before, the clarification will both put more restrictions on HW and limit what SW can assume.
I would like to require version to always be readable, but since that's a backwards-incompatible change I don't want to make it now. I'll make a PR to make this unambiguous, and to state that the behavior/position of the dmactive bit won't change in the future.
@gravikumar92 raised the following problem in https://github.com/riscv/riscv-openocd/issues/316:
While dmactive is 0, the spec says:
The former implies that dmstatus.version is readable, but the latter implies it might not be. Currently OpenOCD assumes the version is always available, and it uses this to automatically detect 0.11 vs. 0.13. Since 0.11 doesn't have a dmactive bit automatic detection gets trickier (but probably still doable) if we can't assume the version is always accessible.