Feature request (not for CV32E40P): Implement error pin for instruction and data bus interfaces

[Silabs-ArjanB]

The original RI5CY used to have an error pin for its instruction and data bus interfaces to signal bus errors. Unfortunately these were removed once the PMP was introduced.

Proposal is to re-add these pins on future cores (i.e. not yet in CV32E40P as this feature was not agreed upon) and their associated functionality (i.e. possibility to raise instruction/load/store access faults).

Related issue: #289

[Silabs-ArjanB]

Implementation for this will need tot take into account the out of order completion of instructions, see #466

[klion717]

Hi, @Silabs-ArjanB . Currently, I generated an interrupt when there is error response at the bus and I intended to connect this interrupt to the NMI interrupt of the core. But I could not find the nmi interface in the latest version of the core. From the ri5cy document, I found the description about MIE/MIP as follows: 31 | R | Non-maskable interrupt pending: If set, irq_nmi_i is pending. It seems the MSB of MIE/MIP is used for nmi irq. I made a case to test the irq[31] and got the result that it still can be masked by MIE[31]. So, can I get the conclusion that the nmi irq interface is removed at the latest RTL version?

[Silabs-ArjanB]

Hi @klion717 Yes, the NMI has been removed a couple of months ago as it was a proprietary feature and (very likely) not compliant to the forthcoming official RISC-V spec with respect to NMI. You can find the documentation for CV32E40P at https://core-v-docs-verif-strat.readthedocs.io/projects/cv32e40p_um/en/latest/ (the RI5CY user manual is not a valid reference for CV32E40P; if we refer to that manual from somewhere in the OpenHW repos / web site, please let me know as then we should remove that).

[klion717]

Hi, @Silabs-ArjanB The OBI interface of core(both instr and data access) supports all combinations of the be signal(byte enable), while the AHB bus SOC system only supports byte/halfword/word transfer(be is among [0001 0010 0100 1000 1100 0011 1111]). Is the any way to avoid the core to generate the ahb-unsupported transfer? Since I do not want to implement a complicated obi2ahb bridge, neither give too much constraint for software coding.

[Silabs-ArjanB]

Hi @klion717 There is no way to limit the RTL to only issue AHB compatible transactions (other than modifying the RTL in the load-store unit itself). The recommended way is to either add an external adapter to AHB (or AXI which is a closer fit) or to prevent the compiler from generating misaligned transactions.