cva6
cva6 copied to clipboard
[BUG] : mip.MSIP and mie.MSIE are read-only zeros
Is there an existing CVA6 bug for this?
- [x] I have searched the existing bug issues
Bug Description
According to CV32A65X Spec, As the system has only one hart then mip.MSIP and mie.MSIE are read-only zeros.
So there's a bug on RTL, it allow modifying mip.MSIP and mie.MSIE
This issue has not been detected up-to-now, the reason is maybe linked to the fact that Spike get the same RTL behavior allowing to modify mip.MSIP and mie.MSIE. So, there' maybe a bug in Spike.
This issue has not been detected up-to-now, the reason is maybe linked to the fact that Spike get the same RTL behavior allowing to modify mip.MSIP and mie.MSIE. So, there' maybe a bug in Spike.
I opened an issue on core-v-verif related to the same bug in (https://github.com/openhwgroup/core-v-verif/issues/2531)
When building the mask of modifiable mie bits at https://github.com/openhwgroup/cva6/blob/master/core/csr_regfile.sv#L1440, the mask for bit mie.MSIE should only be set if the configuration of the core supports multi-core setups.
This issue is present in both Spike and RTL. It was hidden by SpikeTandem
The Spike side was fixed in https://github.com/openhwgroup/cva6/pull/2523. The remaining action is to update the RTL and add an appropriate RTL configuration parameter, as pointed out by @AyoubJalali.
The CSR embedded regression test is failing because of this.
Mismatch example :
mismatch_description: 'CSR 304 Mismatch [REF]: 0x880 [CORE]: 0x888 '
mismatches:
- 0: null
core:
insn: 0000000030419073
insn_disasm: csrrw zero, mie, gp
mode: 3
pc_rdata: 00000000800036ac
pc_wdata: 0
rd1_addr: 0
rd1_rdata: 0
rs1_addr: 3
rs1_rdata: 0000000000000008
rs2_addr: 4
rs2_rdata: 196
trap: 0
reference_model:
insn: 0000000030419073
insn_disasm: csrrw zero, mie, gp
mode: 3
pc_rdata: 00000000800036ac
pc_wdata: 0
rd1_addr: 0
rd1_rdata: 0
rs1_addr: 3
rs1_rdata: 0000000000000008
rs2_addr: 4
rs2_rdata: 0000000080000000
trap: 0
This should be resolved as soon as the RTL is aligned on Spike
#2711 closes the issue