Mismatch in CoSpike co-simulation about WLRL CSR registers

[ZhongYic00]

Background Work

• Yes, I searched the mailing list
• Yes, I searched prior issues
• Yes, I searched the documentation

Chipyard Version and Hash

1.13.0-47-gdd2ce08f

OS Setup

Everything ok following instructions.
Linux 4c69a5ab553b 4.15.0-163-generic #171-Ubuntu SMP Fri Nov 5 11:55:11 UTC 2021 x86_64 GNU/Linux
Distributor ID: Ubuntu
Description: Ubuntu 22.04.3 LTS
Release: 22.04
Codename: jammy

Other Setup

1. build cosim with make verilator TARGET_CONFIG=FireSimLargeBoomCospikeConfig
2. run VFireSim with the same args as in make run-verilator

Current Behavior

When running cosim, many false positive mismatches deteced around mcause/mtval... CSRs.

Expected Behavior

The false positive mismatches may be avoided by syncing the behaviors of BOOM to spike

Other Information

A minimal PoC testcase:

csrwi mcause,0
li t0,0xfffffffffffffff6
csrw mcause,t0
csrr t6,mcause

and the cospike yields:

Cosim: 346 commit: 80000000
core   0: 3 0x0000000080000000 (0x34205073) c834_mcause 0x0000000000000000
Cosim: 358 commit: 80000004
core   0: 3 0x0000000080000004 (0x52d9) x5  0xfffffffffffffff6
Cosim: 364 commit: 80000006
core   0: 3 0x0000000080000006 (0x34229073) c834_mcause 0xfffffffffffffff6
Cosim: 376 commit: 8000000a
core   0: 3 0x000000008000000a (0x34202ff3) x31 0xfffffffffffffff6
Cosim: CSR read 342
Cosim: 178 wdata mismatch reg 31 fffffffffffffff6 != 8000000000000006

Simulation complete.
*** FAILED *** (code = 1) after 3458 cycles

Look further into the mismatch, it's because CSRs like xcause/xtval... are WLRL in RISC-V spec. As hardware, BOOM only implements lower and higher bits of them, leaving middle bits hard-zero. So when written 0xfffffff6, it's only guaranteed to hold supported exception codes i.e. holds {0x1 for interrupt bit, 00..0, 0x6 for cause code}.