ImperasDV mismatch on cbo* tests

[davidharrishmc]

The WALLY-cboz and com tests are not passing ImperasDV.

~/cvw/tests/riscof/work/wally-riscv-arch-test/rv64i_m/privilege/src$ run-elf.bash --elf WALLY-cboz-01.S/ref/ref.elf --verbose

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

Here is the coz mismatch report.

# Info (IDV) testbench.idv_trace2log.process_event @ 17240: RET,0,1148,800006f4,"00033e83 ld      x29,0(x6)      ",x29=0000000000000000,,,CSRb00(mcycle)=00000000000006b7 CSRb02(minstret)=000000000000047c,
# Info 1148: 'refRoot/cpu', 0x00000000800006f4(memcmp8_loop+4): Machine 00033e83 ld      x29,0(x6)
# Info   MEMX 0x800006f4 0x800006f4 2 3e83
# Info   MEMX 0x800006f6 0x800006f6 2 0003
# Info   MEMR 0x800025a0 0x800025a0 8 0000000900000008
# Info   x29 0000000000000000 -> 0000000900000008
# Info (IDV) Instruction executed prior to mismatch '0x800006f4(memcmp8_loop+4): 00033e83 ld      x29,0(x6)'
# Error (IDV) GPR register value mismatch (HartId:0, PC:0x00000000800006f4 memcmp8_loop+4):
# Error (IDV) Mismatch 0> GPR x29
# Error (IDV)   . dut:0x0000000000000000
# Error (IDV)   . ref:0x0000000900000008
# Error (IDV) testbench.idv_trace2api.state_compare @ 17240: MISMATCH

[rosethompson]

@eroom1966 and @duncangraham-Imperas

Hi Lee and Duncan,

This bug occurs after executing cbo.inval. I am thinking ImperasDV is configured wrong and maybe doesn't understand our data cache configuration. The test is as follows. Statically initialize a destination region of memory with copies of "deadbeef" Copy 512 bytes (8 cache lines) into that region. Verify that region is correct. Then invalidate 1 cacheline so the copied data is discarded and now memory should contain "deadbeef". Verify that one cacheline contains "deadbeef". ImperasDV is reporting that correct load data is not deadbeef but the copied data.

[duncangraham-Imperas]

We do not include cache models for riscv so I suspect this is the issue.

[rosethompson]

Since IDV does not model a cache the tests are written will not function correctly. Can IDV setup a non-coherent DMA device? We could test these instructions in their intended use case rather than my contrived single hart scenario.

[davidharrishmc]

According to the spec, cbo.zero is supposed to zero out a range of memory locations (typically 64 consecutive bytes, but implementation-specific), whether or not there is a cache or the memory is catchable. Thus, I think the ImperasDV reference model is not correct right now, even if cache models are not included.

-------- from the spec:

Cache-block zero instructions store zeros independently of whether data from the underlying memory locations are cacheable. In addition, this specification does not constrain how the bytes are written.

[eroom1966]

Something seems broken for me, I tried the following command to reproduce the testcase

git clone https://github.com/openhwgroup/cvw --recurse-submodules

Submodule path 'addins/embench-iot': checked out '4c5eb87983f51ca7fcf7855306877b3d1c3aabf1' fatal: remote error: upload-pack: not our ref 2c5675d7a58e98d47bef3a6cf5a8373397b0d0be fatal: The remote end hung up unexpectedly Fetched in submodule path 'addins/riscv-arch-test', but it did not contain 2c5675d7a58e98d47bef3a6cf5a8373397b0d0be. Direct fetching of that commit failed.

[eroom1966]

The issue is unrelated to caches, but the configuration of the following parameters cmomp_bytes cmoz_bytes

I am sending a document via email to explain this. Thx Lee

[davidharrishmc]

I’m also having trouble with addins/embench-iot. I’ll see what I can find.

On Nov 15, 2023, at 3:48 AM, Lee Moore @.***> wrote:

Somethnig seems broken for me, I tried the following command Submodule path 'addins/embench-iot': checked out '4c5eb87983f51ca7fcf7855306877b3d1c3aabf1' fatal: remote error: upload-pack: not our ref 2c5675d7a58e98d47bef3a6cf5a8373397b0d0be fatal: The remote end hung up unexpectedly Fetched in submodule path 'addins/riscv-arch-test', but it did not contain 2c5675d7a58e98d47bef3a6cf5a8373397b0d0be. Direct fetching of that commit failed.

— Reply to this email directly, view it on GitHub https://github.com/openhwgroup/cvw/issues/461#issuecomment-1812388225, or unsubscribe https://github.com/notifications/unsubscribe-auth/AR4AA34T3WYR7LO7GNJF5YDYESTYJAVCNFSM6AAAAAA7GIC5V2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJSGM4DQMRSGU. You are receiving this because you authored the thread.

[davidharrishmc]

Sorry, that is riscv-arch-test that I’m having trouble with.

I’ve removed it from the repo and added it back. PR 479. When Rose accepts it, lets see if that fixes the issue.

David

On Nov 15, 2023, at 5:34 AM, David Harris @.***> wrote:

I’m also having trouble with addins/embench-iot. I’ll see what I can find.

On Nov 15, 2023, at 3:48 AM, Lee Moore @.***> wrote:

Somethnig seems broken for me, I tried the following command Submodule path 'addins/embench-iot': checked out '4c5eb87983f51ca7fcf7855306877b3d1c3aabf1' fatal: remote error: upload-pack: not our ref 2c5675d7a58e98d47bef3a6cf5a8373397b0d0be fatal: The remote end hung up unexpectedly Fetched in submodule path 'addins/riscv-arch-test', but it did not contain 2c5675d7a58e98d47bef3a6cf5a8373397b0d0be. Direct fetching of that commit failed.

— Reply to this email directly, view it on GitHub https://github.com/openhwgroup/cvw/issues/461#issuecomment-1812388225, or unsubscribe https://github.com/notifications/unsubscribe-auth/AR4AA34T3WYR7LO7GNJF5YDYESTYJAVCNFSM6AAAAAA7GIC5V2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJSGM4DQMRSGU. You are receiving this because you authored the thread.

[davidharrishmc]

The new cache parameters fixed cboz. Thanks, Lee!

I don't think our cbom test will be able to pass against ImperasDV because ImperasDV doesn't model caches.

Rose, I think we can close this unless you have any other concerns.