cv32e40x
cv32e40x copied to clipboard
openhwgroup
[XIF] Too many instructions can execute after interrupt becomes pending and enabled
Version 1.12 of the Privileged Spec states:
After execution of each instruction in program order, if the conditions for an interrupt trap are true, the trap occurs immediately, before another instruction executes.
The CV32E40X (and CV32E40S) break this requirement in case mip is already set and an interrupt should be taken due to enabling it via a CSR write (mip, mie, mstatus, and mideleg) or xRET.
This should become part of the VPLAN as well and should be checked with formal techniques.
Possible fixes include:
- Stall for specific CSR write - load/store/X itf combinations (xRET is likely not an issue thanks to its pipe flush)
- Forwarding of relevant CSR bits into the interrupt logic
We managed to reproduce this exact issue when we ran a test called "corev_rand_interrupt_0.elf" I cannot recall how this was generated, but I am presuming from cv_regress ?
Does this also apply for enabling CLIC interrupts by writes to external CLIC? Or can we for CLIC only regard core internal CSRs that directly impact the decision (thresholds and levels for instance).
This is only about internal CSRs, not about memory mapped registers (although there is a separate issue about #507 as well that relates to regular stores).
@Silabs-ArjanB are these 2 last posts questions ? If so, who are they intended for ?
@eroom1966 The post from Øystein was a question (I assume to me as I created this issue) and I answered it in the post below his question.
PR #650 addresses this issue when X_EXT=0. If not using X_EXT, this issue should now be solved for both basic and CLIC modes.
With X_EXT=1, there are several other issues that is not directly related to this that would need to be fixed in order to have a working X-interface.
Issue has been fixed for X_EXT = 0. The issue will remain open to look at it again once we start fixing the X interface (X_EXT = 1) (and therefore its title has been prefixed with [XIF]).