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

Coprocessor should take RV32E into account #64

Open
Silabs-ArjanB opened this issue Nov 1, 2022 · 3 comments
Open

Coprocessor should take RV32E into account #64

Silabs-ArjanB opened this issue Nov 1, 2022 · 3 comments
Labels
enhancement New feature or request post-v1.0 To be fixed after v1.0.0 release

Comments

@Silabs-ArjanB
Copy link
Contributor

CORE-V-XIF needs to define how XIF can be used together with RV32E.

An initial proposal:

  • A processor configured to use RV32E will declare all instructions that would use a source or destination register within x16-x31 if the RV32I base would have been used as illegal and attempt them for offload.
  • A processor will never indicate that a register file source is valid via rs_valid if the related source is within x16-x31
  • A coprocessor shall only be allowed to accept such instructions if it is not actually using any register file register within the x16-x31 range (i.e. a coprocessor shall not wait for validity via rs_valid if the related source is within x16-x31 as it will never happen and the coprocessor shall ignore rs if the related source is within x16-x31. The coprocessor shall also never write to x16-x31 via the result interface)
@christian-herber-nxp
Copy link
Contributor

Fully agree to the first bullet. As the encoding space with any operand in the x16-x31 range is considered custom.
Second bullet, agree
Third bullet: Is this really a special case within RV32E? If a custom instruction is defined from a standard instruction with out of range source or destination register(s), then those encoding bits are simply not meant to designate a register. Sounds to me the same if I have a custom instruction without source or destination register.

@Silabs-ArjanB
Copy link
Contributor Author

Fully agree to the first bullet. As the encoding space with any operand in the x16-x31 range is considered custom.

Actually these encodings are no longer considered 'custom'. They are considered 'reserved'. Either way, the proposal it to offer such encodings for offload.

Third bullet: Is this really a special case within RV32E? If a custom instruction is defined from a standard instruction with out of range source or destination register(s), then those encoding bits are simply not meant to designate a register. Sounds to me the same if I have a custom instruction without source or destination register.

You are right about that. At the same time 'out of range source or destination registers' are not possible in RV32I, that is why I specifically mentioned it for RV32E. It does not imply any additional hardware (it is just something that could be verified for a coprocessor intended to work with a CPU using RV32E).

@christian-herber-nxp
Copy link
Contributor

Actually these encodings are no longer considered 'custom'. They are considered 'reserved'. Either way, the proposal it to offer such encodings for offload.

Ok, I didn't observe this change until now. Then, I guess it is consistent with the general approach of the interface, that reserved means offered for offload.

@christian-herber-nxp christian-herber-nxp added enhancement New feature or request post-v1.0 To be fixed after v1.0.0 release labels Feb 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request post-v1.0 To be fixed after v1.0.0 release
Projects
None yet
Development

No branches or pull requests

2 participants