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

[Result interface] Exceptions in the result interface #215

Open
mp-17 opened this issue Mar 20, 2024 · 5 comments
Open

[Result interface] Exceptions in the result interface #215

mp-17 opened this issue Mar 20, 2024 · 5 comments
Labels
question Further information is requested

Comments

@mp-17
Copy link

mp-17 commented Mar 20, 2024

From my understanding, the only way for the coprocessor to signal an illegal instruction exception is through the accept signal of the issue interface.

If the coprocessor has a more involved decode stage and checks to determine if an offloaded instruction is legal, the coprocessor answer on the issue interface can be slow.
In the previous version of the specs (0.2.0), the result interface had an exception signal through which it was possible to delay the full checks on the offloaded instruction to determine if it was legal or not.
I see how this is a bit of a hack to handle the situation, but it was quite handy to reduce the pressure in the decode stage of more complex coprocessors.

Were the exception-related signals removed from the result interface to force the coprocessor to signal illegal instruction exceptions through the issue interface only?

Thank you,
Matteo

@christian-herber-nxp
Copy link
Contributor

the current model is that illegal instruction traps must be indicated by not accepting the instruction. For performant implementations, this does indeed require the decision to be quick (usually single cycle). It is possible to delay the issue response, but that would have a performance impact.
The assumption placed here is that a CPU would handle illegal instruction traps only in the decode stage.

@christian-herber-nxp christian-herber-nxp added the question Further information is requested label Mar 28, 2024
@christian-herber-nxp
Copy link
Contributor

to add to this: the exceptions are only there for the memory interface. RISC-V unprivileged extensions do not raise any exceptions outside of illegal instruction if they do not do loads/stores.

@mp-17
Copy link
Author

mp-17 commented Mar 28, 2024

Hi @christian-herber-nxp, thanks for your response. It seems that the trade-off between critical path length of the issue response signal and IPC (if the the issue response is delayed) is mandatory for complex decoders with this implementation of the XIF. We will try to assess the IPC loss and/or the max freq degradation for our implementation under these hypotheses. Worst case, we will add a "delayed exception" set of signals in the result interface to signal a "delayed" illegal instruction.

@christian-herber-nxp
Copy link
Contributor

This would be great input. For which CPU and coprocessor would that be?

@mp-17
Copy link
Author

mp-17 commented Mar 28, 2024

We are trying to use XIF 1.0 on CVA6 and Ara, the vector processor: https://github.com/pulp-platform/ara

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants