WALLY-cbom test fails

[davidharrishmc]

After rerunning make with the latest GCC (newer than 2023-12-20), WALLY-cbom fails:

Error on test rv64i_m/privilege/src/WALLY-cbom-01.S result         214: adr = 00000000800037c0 sim (D$) 0000000000000000 sim (DTIM_SUPPORTED) = 0bad0bad0bad0bad, signature = ffffffffffffff

run-elf.bash --elf /home/harris/cvw/tests/riscof/work/wally-riscv-arch-test/rv64i_m/privilege/src/WALLY-cbom-01.S/ref/ref.elf

# Info (IDV) testbench.idv_trace2log.process_event @ 16540: RET,0,1108,80000428,“0005a00f cbo.inval x11          “,,,,CSRb00(mcycle)=0000000000000671 CSRb02(minstret)=0000000000000454,
# Info (IDV) testbench.idv_trace2log.process_event @ 16550: RET,0,1109,8000042c,“00002517 auipc   x10,0x2        “,x10=000000008000242c,,,CSRb00(mcycle)=0000000000000672 CSRb02(minstret)=0000000000000455,
# Info (IDV) testbench.idv_trace2log.process_event @ 16660: RET,0,1110,80000430,“bd450513 addi    x10,x10,-1068  “,x10=0000000080002000,,,CSRb00(mcycle)=000000000000067d CSRb02(minstret)=0000000000000456,
# Info (IDV) testbench.idv_trace2log.process_event @ 16670: RET,0,1111,80000434,“00003597 auipc   x11,0x3        “,x11=0000000080003434,,,CSRb00(mcycle)=000000000000067e CSRb02(minstret)=0000000000000457,
# Info (IDV) testbench.idv_trace2log.process_event @ 16680: RET,0,1112,80000438,“d4c58593 addi    x11,x11,-692   “,x11=0000000080003180,,,CSRb00(mcycle)=000000000000067f CSRb02(minstret)=0000000000000458,
# Info (IDV) testbench.idv_trace2log.process_event @ 16690: RET,0,1113,8000043c,“00800613 addi    x12,x0,8       “,x12=0000000000000008,,,CSRb00(mcycle)=0000000000000680 CSRb02(minstret)=0000000000000459,
# Info (IDV) testbench.idv_trace2log.process_event @ 16700: RET,0,1114,80000440,“6a8000ef jal     x1,80000ae8    “,x1=0000000080000444,,,CSRb00(mcycle)=0000000000000681 CSRb02(minstret)=000000000000045a,
# Info (IDV) testbench.idv_trace2log.process_event @ 16730: RET,0,1115,80000ae8,“00050293 mv      x5,x10         “,x5=0000000080002000,,,CSRb00(mcycle)=0000000000000684 CSRb02(minstret)=000000000000045b,
# Info (IDV) testbench.idv_trace2log.process_event @ 16740: RET,0,1116,80000aec,“00058313 mv      x6,x11         “,x6=0000000080003180,,,CSRb00(mcycle)=0000000000000685 CSRb02(minstret)=000000000000045c,
# Info (IDV) testbench.idv_trace2log.process_event @ 16850: RET,0,1117,80000af0,“00000393 mv      x7,x0          “,x7=0000000000000000,,,CSRb00(mcycle)=0000000000000690 CSRb02(minstret)=000000000000045d,
# Info (IDV) testbench.idv_trace2log.process_event @ 16960: RET,0,1118,80000af4,“0002be03 ld      x28,0(x5)      “,x28=deadbeefdeadbeef,,,CSRb00(mcycle)=000000000000069b CSRb02(minstret)=000000000000045e,
# Info (IDV) testbench.idv_trace2log.process_event @ 16970: RET,0,1119,80000af8,“00033e83 ld      x29,0(x6)      “,x29=deadbeefdeadbeef,,,CSRb00(mcycle)=000000000000069c CSRb02(minstret)=000000000000045f,
# Info (IDV) Instruction executed prior to mismatch ‘0x80000af8(memcmp8_loop+4): 00033e83 ld      x29,0(x6)’
# Error (IDV) GPR register value mismatch (HartId:0, PC:0x0000000080000af8 memcmp8_loop+4):
# Error (IDV) Mismatch 0> GPR x29
# Error (IDV)   . dut:0xdeadbeefdeadbeef
# Error (IDV)   . ref:0x0000000100000000

[davidharrishmc]

Same issue happened on old gcc.

[rosethompson]

The issue is a combination of things. The #delay removal for some reason doesn't include the cache LRU state. And we are using blocking statements (=) in the always_ff block because of verilator issues. These combined cause the relative timing to get screwed up and break the simulation. I'm becoming increasingly uncomfortable with this use of blocking statements in the always_ff block.

However, removing the #1 does solve the issue. Swapping to using non-blocking (<=) also solves the issue. Both also solves the issue.

[davidharrishmc]

This issue is back after redoing the LRU.

wsim rv64gc cbom --elf $WALLY/tests/riscof/work/wally-riscv-arch-test/rv64i_m/privilege/src/WALLY-cbom-01.S/ref/ref.elf --lockstep ``` # Info (RISCV_PMP) CPU 'refRoot/cpu': PMP PRIV=rwx 0x00000000:0xffffffffffffff (mode Machine) # Info (IDV) Instruction executed prior to mismatch '0x80000af8(memcmp8_loop+4): 00033e83 ld x29,0(x6)' # Error (IDV) GPR register value mismatch (HartId:0, PC:0x0000000080000af8 memcmp8_loop+4): # Error (IDV) Mismatch 0> GPR x29 # Error (IDV) . dut:0xdeadbeefdeadbeef # Error (IDV) . ref:0x0000000100000000 # Error (IDV) testbench.idv_trace2api.state_compare @ 17150: MISMATCH ```

[davidharrishmc]

I think the issue is that ImperasDV does not yet model caches, so it cannot correctly simulate cbo.inval. The DUT is correct and the ref is wrong.

[eroom1966]

Hi David, can you provide the files to reproduce the testcase please, I am struggling to configure my environment to rebuild your tests

thx Lee

[eroom1966]

Ignore this request - I have been able to build the testcase

[davidharrishmc]

Confirmed that this test will fail ImperasDV because ImperasDV does not model caches to properly handle CMO instructions.

[davidharrishmc]

Failure wavied with PR #880