[BUG] Incorrect handling of PMPADDR register reads in NA4 / NAPOT address matching modes

[zchamski]

Is there an existing CVA6 bug for this?

• I have searched the existing bug issues

Bug Description

The RTL code of CSR read process (https://github.com/openhwgroup/cva6/blob/master/core/csr_regfile.sv#L851C1-L857C71) incorrectly assumes that the last bit of pmpaddr registers should be read as 1 if the corresponding pmpNcfg.A[1] bit is set. Table 19 in the privileged ISA spec (v20240411) states that the value of bit 0 in a pmpaddrN register can be 0 in NA4 mode and must be 0 in NAPOT mode with 8 byte ranges:

@Moschn, can you please have a look at this?

[Moschn]

I think you are correct. I'm not sure where this bug crept in; at some point, this was working correctly (I checked the supported granularity in software a couple years ago). Feel free to propose a fix!

[Moschn]

I checked this again today. In the past, we did not support NA4, which coincides with the current behavior of the code. To clarify, we set G=2 (Granularity of a minimum of $2^{G+2} = 16$ bytes) and thus NA4 to be disabled. The important sentences in the spec:

When $G>=1$, the NA4 mode is not selectable. When $G>=2$ and $pmpcfg_i.A[1]$ is set, i.e. the mode is NAPOT, then bits $pmpaddr_i[G-2:0]$ read as all ones. When $G>=1$ and $pmpcfg_i.A[1]$ is clear, i.e. the mode is OFF or TOR, then bits $pmpaddr_i[G-1:0]$ read as all zeros.

The current code performs exactly this behavior:

if (pmpcfg_q[index].addr_mode[1] == 1'b1) // i.e., A[1] is set
  csr_rdata = {pmpaddr_q[index][CVA6Cfg.PLEN-3:1], 1'b1}; // pmpaddr_i[0:0] = 1
else csr_rdata = {pmpaddr_q[index][CVA6Cfg.PLEN-3:1], 1'b0}; // A[1] is not set -> pmpaddr_i[1:0] = 0

I was also confused at first when I reread the spec and the code, but I think there was a mistake that I thought G=2 means 8-byte granularity. Instead, G=2 means 16-byte granularity, and then also the table is correct, i.e., in NAPOT mode, always force bit 0 to 1.

I believe this still holds with respect to the recent changes (#2685).