Bug : PMPCFG.A field

[AyoubJalali]

Hello, according to the CV32A65X Spec, the pmpcfg[x].A support only 2 modes disable/TOR, so the only legal value for pmpcfg.A is 2'b01 | 2'b00.
but spike support all A flied modes, so this need some mask based on a config, the bug is in solo & tandem mode.

[MikeOpenHWGroup]

See also CVA6 #2024.

[zchamski]

We need to specify in detail the behavior of pmpcfg.A writes: when the high bit of the assigned value is set, should the write be discarded altogether (no state change), or should it be masked and only affect the low bit of pmpcfg.A?

[MikeOpenHWGroup]

pmpcfg.A is a WARL field and Section 2.3 CSR Field Specifications of the privileged spec says:

Implementations will not raise an exception on writes of unsupported values to a WARL field.
Implementations can return any legal value on the read of a WARL field when the last write was of
an illegal value, but the legal value returned should deterministically depend on the illegal written
value and the architectural state of the hart.

So it all depends on the interpretation of the legal value returned should deterministically depend on the illegal written value. My interpretation of this is that a write of 2'b1X should be ignored, no exception should be raised and the value of pmpcfg.A should not change.

Consider the scenario where the current value of pmpcfg.A is 2'b00 (OFF) and software writes 2'b11 (NAPOT).

In this situation, the only deterministic outcomes are that pmpcfg.A should be either NAPOT or OFF. In our case it is OFF, since NAPOT is not supported. If the write is "masked and only affect the low bit", then the value is updated to TOR, which software would not be expecting.

[AyoubJalali]

Normally we should igonre changing the pmpcfg.A when trying to write an illegal value, so the last legal value should be keeped