several possible PMP nonconformances?

[sorear]

While looking for solutions to #427 I looked over the PMP implementation. Some possible issues I noticed:

1. From the privilege spec:

Software may determine the PMP granularity by writing zero to pmp0cfg, then writing all ones to pmpaddr0, then reading back pmpaddr0. If G is the index of the least-significant bit set, the PMP granularity is 2^(G+2) bytes.

However no such mechanism appears to be implemented; mpmpaddrNNN read and write 32 bits regardless of EN_NAPOT_RULE_nnn.

It is unclear if the EN_NAPOT_RULE_nnn feature is needed: the entire switch statement is a very long way of writing:

start_addr[i] = pmp_addr_i[i] & (pmp_addr_i[i] + 1);

(The subsequent mode checks also appear redundant: you already have start_addr and stop_addr calculated for every mode.)

1. Inclusive/exclusive inconsistency

When PMP i is in TOR mode, stop_addr[i] is set to the first address past the PMP's range; but in NAPOT mode stop_addr[i] is set to the last address in the PMP's range.

1. Boundary conditions

The lowest-numbered PMP entry that matches any byte of an access determines whether that access succeeds or fails. The matching PMP entry must match all bytes of an access, or the access fails, irrespective of the L, R, W, and X bits. For example, if a PMP entry is configured to match the four-byte range 0xC–0xF, then an 8-byte access to the range 0x8–0xF will fail, assuming that PMP entry is the highest-priority entry that matches those addresses.

The code appears to only check the first byte of any operation. The PMP should have access to the length of the attempted access and check for range overlaps.

(Since ranges are always an aligned multiple of 4 bytes, this is not an issue if all accesses are less than 4 bytes and if misaligned accesses are split prior to the PMP check. If misaligned accesses are split after the PMP check, it would be needed to check the full range.)

1. Reversed logic for RWX bits and no locking

Otherwise, if the L bit is set or the privilege mode of the access is S or U, then the access succeeds only if the R, W, or X bit corresponding to the access type is set.

https://github.com/openhwgroup/cv32e40p/blob/master/rtl/cv32e40p_pmp.sv#L580 ignores PMPs if the RWX bits are clear, effectively treating them as deny bits instead of the defined allow bits.

The entries are also ignored entirely in M-mode.

[Silabs-ArjanB]

Hi @sorear Thank you for your detailed report. Please be aware that the CV32E40P does not include the PMP. That being said, we do intend to revive this functionality on a next core and address the PMP issues (maybe by starting with the PMP design from Ibex instead as it has various issues solved and is written in a cleaner manner). Please let us know if you actually want to take on this task?