riscv / riscv-aia

https://jira.riscv.org/browse/RVG-59
Creative Commons Attribution 4.0 International
81 stars 19 forks source link

Detecting the extension #40

Closed timsifive closed 1 year ago

timsifive commented 1 year ago

How can a debugger (or other software) detect which CSRs are available, without trying to access each CSR individually?

I think if miselect is can be read without getting an exception, then miselect, mireg, mtopei, mtopi, mvien, and mvip are all implemented, and if XLEN=32 then midelegh, mieh, mvienh, mviph, and miph are also implemented.

Then if misa.S is set, the Section 2.2. CSRs are also implemented, and if misa.H is set, then the Section 2.3 CSRs are also implemented.

So I can detect everything I need by just attempting to read miselect. Is that right?

timsifive commented 1 year ago

Looks like at least I need to also read mtopei because that's only readable with an IMSIC.

ved-rivos commented 1 year ago

Tim Newsome wrote:

I think if miselect is can be read without getting an exception, then miselect, mireg, mtopei, mtopi, mvien, and mvip are all implemented, and if XLEN=32 then midelegh, mieh, mvienh, mviph, and miph are also implemented.

There has been discussion about generalizing the miselect/mireg to apply to extensions besides AiA. So a stronger detection may be to not just detect presence of iselect/ireg CSRs but to detect if the specific extensions state can be accessed using these CSRs.

regards ved

timsifive commented 1 year ago

If someone could double check my logic at https://github.com/riscv/riscv-openocd/pull/815/files#diff-b4aa16f9e42cb8f0934baa7c8e0ec9c70a369bef98b99b26ae2e896c8aa95d6aR5402 that'd be very helpful.

timsifive commented 1 year ago

Presumably by accessing extension state you mean writing a CSR and seeing if the new value is accepted. For a debugger, that means:

  1. Read the CSR
  2. Write a new value
  3. Read it back to see if the value was accepted
  4. Write back the original value, so we don't interfere with the running code. That's quite a process. I much prefer a single read (and even that will grow out of control if the debugger has to do a read for every extension that adds CSRs). Hopefully some day Unified Discovery can streamline this process.

Personally I'm only interested in whether the CSRs are implemented or not (so the debugger can show them to the user or not.) Would it still be necessary to try to access the state to see which CSRs are implemented?

ved-rivos commented 1 year ago

Personally I'm only interested in whether the CSRs are implemented or not (so the debugger can show them to the user or not.) Would it still be necessary to try to access the state to see which CSRs are implemented?

It depends on what the goal is. If the goal is to show that miselect/mireg are implemented then just accessing them suffices. If the goal is to show that the IMSIC is implemented based on existence of miselect/mireg then it may not be sufficient as these may be implemented to support a different extension than IMSIC. From the PR you posted seems like you are discovering mtopi and using that to infer existence of miselect/mireg as well as AIA. That sounds okay to me.

timsifive commented 1 year ago

It depends on what the goal is. If the goal is to show that miselect/mireg are implemented then just accessing them suffices.

That is my goal. Thanks for looking over my PR.

I imagine a more sophisticated debugger would like to show whether IMSIC is supported.