[BUG] cv32e20 fails to raise issue_valid on X-IF for coprocessor CSR instructions

[anecorral]

Bug Description

Bug Description

We have been attempting to integrate the cv32e20 with our coprocessor. We noticed that when a coprocessor csr read/write instruction is called, no issue_valid is raised through the X-IF.
This occurs because cve2_id_stage only considers illegality originating from the decoder (illegal_insn_dec) when making an X-IF request. Consequently, the cv32e20 stalls on a CSR illegality exception, treating it as a local fault within the main core.

However, we observed that the cv32e40x correctly supports sending requests through the X-IF for CSR instructions that are not supported by the CPU.

For reference, here is the corresponding implementation in the cv32e40x id_stage.

Furthermore, we noticed that the misa value is not adapted when X_EXT is enabled, preventing the CPU from being expanded with additional extensions. Is this intentional, or should it feature an implementation similar to the cv32e40x?

Thanks for your time.

[MikeOpenHWGroup]

Hi @anecorral, thanks for this Issue. I am not sure this is a bug, it might be a feature. Does the CORE-V eXtension Interface specification indicate that an illegal CSR access should automatically initiate an X-IF request?

[anecorral]

Thanks for the quick reply!
My understanding is that the X-IF is intended to handle custom CSRs, if the core doesn't recognise an address, it initiates a request to give the coprocessor a chance to handle it. If this weren't the case, would there be another intended mechanism for the coprocessor to manage its own internal states?
Thanks again for the help!

[MikeOpenHWGroup]

I would recommend you post a question (issue) about that on the CORE-V eXtension Interface repository.