-
Notifications
You must be signed in to change notification settings - Fork 24
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
Comments
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. |
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. |
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. |
This would be great input. For which CPU and coprocessor would that be? |
We are trying to use XIF 1.0 on CVA6 and Ara, the vector processor: https://github.com/pulp-platform/ara |
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
The text was updated successfully, but these errors were encountered: