PMP CSRs access mode failures

[spidugu444]

Three issues have been encountered while verifying the access mode behaviour of the PMP CSRs.

1. PMPADDR[8]- PMPADDR[15] : read zero after writing it with non-zero value.
2. PMPCFG[0]- PMPCFG[1] : while writing any random value it is always reading the value that we write after reset.
3. PMPCFG[2] - PMPCFG[3] : read zero even after writing it with non-zero value.

[MikeOpenHWGroup]

Hi @spidugu444, thanks for creating this issue. I took the liberty of editing it because you are reporting three issues here.

I believe (do not know for sure) that issues 1 and 3 are documentation issues and not an RTL problem. By inspection, it seems that for the CV32A60X, the number of PMP Entries is 8. That would imply that PMPADDR[8..15] and PMPCFG[2..3] do not exist.

If that is true, then we need to update the CV32A6 Control Status Registers chapter in the CVA6 User Manual to indicate:

• That only PMPADDR[0..7] and PMPCFG[0..1] exist.
• What is the correct behaviour if PMPADDR[8..15] and PMPCFG[2..3] are read.

@JeanRochCoulon or @ASintzoff can you comment on this?

Issue 2 is more interesting. @spidugu444 do you have a test-program we can use to reproduce this?

[spidugu444]

Hi @MikeOpenHWGroup, please find the steps to replicate PMPCFG0 issue as mentioned below.

1.git clone https://github.com/spidugu444/core-v-verif.git 2.git checkout pmpcfg0_issue 3. Command to run PMPCFG0 test source cva6/regress/smoke-tests.sh 4. Test file path core-v-verif/cva6/tests/custom/csr_access_tests/riscv_pmpcfg0_csr_test_0.S 5. Yaml file path core-v-verif/cva6/tests/custom/csr_access_yaml/cva6_pmpcfg0_csr_test.yaml

[MikeOpenHWGroup]

Thanks for the additional information @spidugu444.

@ASintzoff and @JeanRochCoulon, I have assigned this issue to you. I believe this issue should be split into two issues:

1. Documentation: what is the correct behaviour if PMPADDR[8..15] and PMPCFG[2..3] are read?
2. RTL: why do PMPCFG[2] - PMPCFG[3] read zero even after writing it with non-zero value?

What do you think?

[spidugu444]

PMPCFG[0]- PMPCFG[1] : while writing any random value it is always reading the value that we write after reset.

As per riscv privileged specification

The lock bit is enabled by the riscv-dv generated test because of that, in PMPCFG[0]- PMPCFG[1], while writing any random value I am reading the lock bit enable value. this values will be locked untill the hart is reset.

With manual test, I am reading expected values on RTL end, but there is a spike dependence problem.

[spidugu444]

@RanjanThales

[Moschn]

Hi @spidugu444,

I do not understand the issues that you observe.

Why should PMPCFG[0-1] not read the value that were written? I also do not get the locked issue. Could you please provide a sequence of instructions that trigger the behavior?

The other two issues mentioned in the initial report are documentation issues. @MikeOpenHWGroup is correct: only 8 PMP entries are enabled in the default configuration. Therefore, any write to PMPADDR[8-15] or PMPCFG[2-3] will not have any effect, and any read will read 0s.

[MikeOpenHWGroup]

Hi @spidugu444, can you respond to @Moschn's question?

[zchamski]

Further investigation of dynamic behavior in RTL and Spike is needed as the order of writes into the PMPCFGn registers impacts their future operation (L bit, reserved combination R=0, W=1). In particular, it will be interesting to analyze the CSR description of PMPCFGn properties as captured by riscv-config (https://github.com/riscv-software-src/riscv-config, vendorized in CVA6 as of #2045).