Are exceptions generated by a coprocessor a use-case

[christian-herber-nxp]

The current definition of CV-X-IF allows a coprocessor to raise an exception. This is true also without the memory interface implemented. RISC-V has taken an approach to not raise exceptions beyond illegal instruction exceptions for unprivileged instructions. Floating point exceptions only result in a CSR being updated. The vector specification does mention several conditions under which a trap occurs, but those are all illegal instruction exceptions which can be caught in the decoder, i.e. can be communicated via not accepting the instruction for offload.

Long story short, I don't see the use-case for issue_resp.exc, and the exception signals in the result interface are optionally tied to the memory interface.

[Silabs-ArjanB]

issue_resp.exc can be used for offloaded instructions that can cause an exception inside a coprocessor that cannot (easily) be detected in the decode part of the coprocessor. Note that this field is not used to signal an exception, just that an exception might occur. I agree that this would not be needed when only using a coprocessor to implement standard RISC-V extensions that only use the illegal instruction exception. A user might however define custom exceptions.

I am fine removing the bit, but then we need to do the following as well:

• Require from coprocessors that synchronous exceptions are only allowed to be signalled by not accepting an instruction. Exceptions related to loads/stores will originate from the processor only (not sure if this is important, but let's initially make this strict).

We cannot support other exceptions as if the processor does not know when exceptions can happen it cannot allow out of order completion (unless it is mandated to then also implement an expensive rollback mechanism to maintain exception preciseness).

[christian-herber-nxp]

Comment from Davide: Check if imprecise exceptions need to be supported, e.g. for vector load/stores