This issue can be encountered in most tests in the testlist_riscv-tests-XXXX-v test list, let's focus on the first one : rv64ui-v-add, with the target cv64a6_imafdc_sv39 (as an "all inclusive" target).
The failure comes from the trap adress read in stval which differs from 0x2002 (SPIKE) to 0x2004 (SIMU)
After some research, I think that the issue might be related to the exception data path. In the file frontend.sv and its involved subentities, icache_dreq_i.ex.tval is somehow 'forgotten' to be replaced by icache_dreq_i.vaddr to form the new tval.
But, icache_dreq_i.vaddr depends on the icache activity and also on its topology (cache size, associativity). I have the feeling that the right trapping adress that should be used for tval is in icache_dreq_i.ex.tval, and that the following icache_dreq_i.vaddr continues to run during the exception handling, not reflecting the adress that caused the exception anymore.
Is there an existing CVA6 bug for this?
Bug Description
This issue can be encountered in most tests in the testlist_riscv-tests-XXXX-v test list, let's focus on the first one : rv64ui-v-add, with the target cv64a6_imafdc_sv39 (as an "all inclusive" target).
The original Icache settings for the target are :
If we change these settings to something else, for instance
the test rv64ui-v-add is failed.
The failure comes from the trap adress read in stval which differs from 0x2002 (SPIKE) to 0x2004 (SIMU)
After some research, I think that the issue might be related to the exception data path. In the file frontend.sv and its involved subentities, icache_dreq_i.ex.tval is somehow 'forgotten' to be replaced by icache_dreq_i.vaddr to form the new tval. But, icache_dreq_i.vaddr depends on the icache activity and also on its topology (cache size, associativity). I have the feeling that the right trapping adress that should be used for tval is in icache_dreq_i.ex.tval, and that the following icache_dreq_i.vaddr continues to run during the exception handling, not reflecting the adress that caused the exception anymore.