riscv-isa-manual
riscv-isa-manual copied to clipboard
riscv
missing extensions and unnamed feature
The Zicount and Zfinx extensions probably should be listed along with all the other unratified extension. In addition, there is another feature that is nameless that probably needs a feature name, HW misalign support (e.g. Zimsalgn)
What would the impact of the presence of Zicount or Zfinx be on the MISA CSR? how can I detect that Zicount has been implemented? How can I detect that Zfinx has been implemented?
The default way is to attempt to access the CSR; if it traps, then it isn't implemented. If it doesn't trap.... then either it is implemented, or the chip has a nonconforming custom extension that re-uses an existing CSR number, or ... something else.
There is a configuration-structure TG that is defining a method and encoding to discover the hart configuration, and which Zextensions are implemented would be at the top of that list. That doesn't help existing implementations, which don't have the capability, of course.
For those, you need to have a platform specific way to discover it, just as if the hart didn't implement MISA (which is not a requirement).
On Thu, Aug 13, 2020 at 10:22 PM Arjan Bink [email protected] wrote:
What would the impact of the presence of Zicount or Zfinx be on the MISA CSR? how can I detect that Zicount has been implemented? How can I detect that Zfinx has been implemented?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-isa-manual/issues/548#issuecomment-673890419, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJV24USDFQESQLFFVR3SATC2RANCNFSM4PGLR7SA .
Thank you for the fast answer. I will start following that configuration-structure TG then.
I don't think this was ever added. However, not convinced that it needs to be added to the current to-be-published version? @allenjbaum Guide me please!
I'm not sure why we wouldn't want to add that. It is basically a list of all the architectural options available to implementers, collected in one place. Some of these are controlled by CSR fields, and have names that define the required values of those CSR fields - those don't need to be listed Some of these are controlled by CSR fields, and are unnamed, which means that SW/firmware may be no easy way to determine how to handle different values
- these need to be listed (often those are WARL fields - risvc-config has a schema that allows defining the precise illegal values and their mapping to legal values. (It is not complete, and still not simple....) Some of these are not controlled by CSR fields, but have names that indicate presence (and maybe absence) - those don't need to be listed Some of these are not controlled by CSR fields, and don't names that indicate presence - these need to be listed (e.g. priority of misaligned vs. page_fault/illegal_access exceptions)
I have a list (attached), but it is both incomplete (even from the time I first created it, but even more so now, outdated (some of these now have names) and unvetted. I tried to find these in the existing specs (at the time I constructed the list) by searching for keywords "may", "can", "option*", etc., but I cannot claim to havefound them all.
This spreadsheet is a list of what the architectural tests need to test spec compatibility with high coverage. Eventually much of these should be in xencfg CSRs, at which point can be removed from this list. (and might inform the definition of what should be in those CSRs)
On Fri, Apr 5, 2024 at 8:47 AM Kersten Richter @.***> wrote:
I don't think this was ever added. However, not convinced that it needs to be added to the current to-be-published version? @allenjbaum https://github.com/allenjbaum Guide me please!
— Reply to this email directly, view it on GitHub https://github.com/riscv/riscv-isa-manual/issues/548#issuecomment-2040135509, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHPXVJTFBBLPUJY72E5ZAVDY33BQNAVCNFSM4PGLR7SKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBUGAYTGNJVGA4Q . You are receiving this because you were mentioned.Message ID: @.***>
I think I sent you the xpreadsheet outside of this issue, but the answer I gave above (try accessing the CSR, see if it traps) may no longer be true; the spec was changed at some point to make access to undefined CSRs be RSVD, which means it coulde do anything, and you shouldn't touch it. In the absence of a configuration structure extension definition that include ALL the extensions and the presence or absence of its CSRs, I'm not sure if my statement above is true, or is only true for existing extensions until the point that the configure structure is nailed down.