search

openhwgroup / core-v-xif

RISC-V eXtension interface that provides a generalized framework suitable to implement custom coprocessors and ISA extensions
https://docs.openhwgroup.org/projects/openhw-group-core-v-xif/en
Other
53 stars 23 forks source link

[Result interface] Exceptions in the result interface #215

Open mp-17 opened 3 months ago

mp-17 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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

mp-17 commented 3 months ago

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