Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using non-csr fields as dependencies in warl functions. #106

Open
pawks opened this issue Sep 25, 2022 · 0 comments
Open

Using non-csr fields as dependencies in warl functions. #106

pawks opened this issue Sep 25, 2022 · 0 comments

Comments

@pawks
Copy link
Collaborator

pawks commented Sep 25, 2022

The spec mentions the following constraint on the misa extensions:

Writing misa may increase IALIGN, e.g., by disabling the “C” extension. If an instruction that
would write misa increases IALIGN, and the subsequent instruction’s address is not IALIGN-bit
aligned, the write to misa is suppressed, leaving misa unchanged.

This means that the warl behavior of any csr field can also depend on a few additional states in the hardware. It might be useful to allow for such dependencies to be specified in the warl function itself and add misa checks to ensure that the above is satisfied if C extension can be disabled at run-time. One might argue that this is a very specific scenario which depends largely on the program flow, but I think this should be specified in the warl function. A list of possible fields which can be allowed are:

  • IALIGN
  • XLEN(incase misa.mxl is not implemented and the implementation has a non-standard way of figuring out xlen. Although I am not sure how SAIL will emulate this behavior).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant