cva6
cva6 copied to clipboard
openhwgroup
[BUG] PMPCFG WARL behavior
Is there an existing CVA6 bug for this?
- [X] I have searched the existing bug issues
Bug Description
Hello, In the RISCV spec section 3.7 Physical Memory Protection :
So in the pmpxcfg has the combination of X, W, R is reserved when W = 1 & R = 0 (as X, W, R form a collective WARL), so if we write a value in pmpxcfg which have this combination, we should not update the WARL (X - R - W).
Spike in the other hand : I write 0xffff_ff0f to pmpcfg1 (R = 1 & W = 1) I read 0xffff_ff0f from pmpcfg1 (normal behavior, no illegal combination between R & W field) Then I write 0xffff_ff02 to pmpcfg1 (R = 1 & W = 0 => illegal combination) I read 0xffff_ff00 from pmpcfg1 (spike consider all the pmp entrie as a WARL), normally we should read 0xffff_ff07 with not Update on the WARL X-R-W
As far as I understand the spec, this is not a bug of CVA6 nor of spike. Both CVA6 and spike behave correctly according to spec: They both always read legal values and allow writing any values (WARL).
Based on your observation, there seems to be a discrepancy between spike and CVA6 as spike just fills WRX with 0s upon a reserved write (W=1, R=0). CVA6 instead just maintains the previous values in the pmpcfg. Both of these behaviors are allowed by the spec.
But here spike, miss information on 'A' & 'L' by clearing all the pmp entry
Ah now I get it. TBH, I think that marking the entire field as WARL would make more sense anyways. If a user writes something illegal, all the bits remain legal. Now there could be a case, where a user writes 1 to the L bit but the other entries are illegal. This means the entry is now locked, but not with the values the user intended.
I am no expert in the spec though, so maybe my interpretation of WARL/CSR fields is incorrect. It could very well be that spike is correct by considering every entry collectively WARL.
In that case, this should be a bug report to spike no?
yes this issue is for spike !!
But then why is this issue here and not in the main spike repo (https://github.com/riscv-software-src/riscv-isa-sim)? Are we maintaining a separate spike tree?
But then why is this issue here and not in the main spike repo (https://github.com/riscv-software-src/riscv-isa-sim)? Are we maintaining a separate spike tree?
we fix in our vendorize spike, adding also the patch for the fix
First the 65x specification need to be updated @zchamski then RTL (and maybe Spike) to be fixed @JeanRochCoulon .
