riscv_mmu_stress_test test fail

[zjuwlh]

Hi ,

when IBEX_CONFIG=small, SEED=27754, ISS=OVPSIM, riscv_mmu_stress_test test failed. it is failed because there are some mismatches between rtl sim csv log and ovpsim csv log, could you please help double check if it is a RTL issue or test case issue?

Thanks, Lihua

[GregAC]

The 'small' config doesn't contain a pmp unit so the mmu stress test won't do anything meaningful. What I'm slightly surprised about it is you get mostly passed tests and a couple of failures, I'd expect all failed for instance as it's testing for a PMP that doesn't exist. @udinator any comments?

[zjuwlh]

is there a doc that indicates what kinds of tests for each core config?

[GregAC]

I'm afraid not, though enabling/disabling tests based on the current config is something I am planning.

Turns out I'm mistaken about the riscv_mmu_stress_test too, it's not actuallly a PMP test (those all have 'pmp' in the name). It exists because RISCV-DV exists to target many processors some of which may have page table support with an MMU. Ibex doesn't so that test is effectively just trying out different memory patterns.

I can reproduce a couple of failures there so I will look into them.

[udinator]

Hi @GregAC @zjuwlh I also am surprised that this test is failing with the 'small' config since all this test does is to inject some random memory access streams into the generated assembly program. I'll take a look into this.

[udinator]

Update: seems like this issue is likely due to the ISS not liking the requested memory address being out-of-bounds relative to the data/stack setup done by riscv-dv. I suspect a fix will be somewhat involved so it likely will not be ready right away.

@zjuwlh in the meantime here is a temporary workaround for the issue. If you open up dv/uvm/core_ibex/riscv_dv_extension/testlist.yaml, you can find the test entry named riscv_mmu_stress_test. In this test entry, remove the line: +directed_instr_3=riscv_load_store_rand_addr_instr_stream,40 from the gen_opts sub-section. This should prevent the problematic memory accesses from being generated.

[zjuwlh]

ok, thanks all.

[rswarbrick]

@udinator: Has this now been fixed?

[udinator]

@rswarbrick unfortunately I haven't had much spare time to look into this, I should have some time soon.