lowRISC / lowRISC/ibex

[pmp]: Custom `PMPRstCfg` values bypass PMP WARL normalization

Open
#2,490 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Type:Bug
Dominant language
SystemVerilog
Stars
2.1k
Forks
810
Avg merge
5d 23h
Merged PRs (30d)
9

Description

## Observed Behavior

Ibex accepts custom `PMPRstCfg` values without applying the WARL handling used by ordinary `pmpcfg` CSR writes.

The test uses `PMPGranularity=1` and supplies:

```text
PMPRstCfg[0] = A=NA4, R=1
PMPRstCfg[1] = A=NAPOT, R=0, W=1
mseccfg.MML = 0
```

The current RTL reads back:

```text
observed: 0x00001a11
expected: 0x00001801
```

The reset state therefore retains an NA4 mode even though NA4 is unavailable at G=1, and retains the reserved `R=0,W=1` permission combination.

The same reset state changes the architectural access result. A U-mode-effective store to the region configured by `PMPRstCfg[1]` succeeds and writes `0xdead0001` to the result location.

## Expected Behavior

The reset state should contain legal PMP WARL values. With `PMPGranularity=1`, the NA4 entry should read as `A=OFF`. With `mseccfg.MML=0`, the reserved `R=0,W=1` combination should have W cleared.

The expected `pmpcfg0` readback is `0x00001801`. The store performed with `mstatus.MPRV=1` and `mstatus.MPP=U` should raise a store access fault (`mcause=7`) instead of reaching the external data interface.

## Steps to Reproduce

1. Run `./evidence/run_ibex_core_pmp_custom_reset_na4.sh`.
2. The test instantiates `ibex_core` with `PMPGranularity=1`, `PMPNumRegions=2`, and the custom `PMPRstCfg` values above.
3. The assembly reads `pmpcfg0` immediately after reset and stores the value to memory.
4. Observe `0x00001a11` instead of `0x00001801`.
5. Run `./evidence/run_ibex_core_pmp_custom_reset_access.sh`.
6. The assembly enables `mstatus.MPRV` with `mstatus.MPP=U` and stores to the reset-configured NAPOT region.
7. Observe a successful store marker `0xdead0001` instead of a store access fault.

The test intentionally exits through `$fatal` when the observed reset state or access result does not match the expected WARL behavior.
[programs.zip](https://github.com/user-attachments/files/31787489/programs.zip)
## Testbench

```text
evidence/ibex_core_pmp_custom_reset_na4_tb.sv
evidence/ibex_core_pmp_custom_reset_access_tb.sv
```

## Environment

Ibex source revision: `57d37bf9008640415532d23ad59018b795c642aa`.

The test uses Verilator and the real `ibex_core` with `PMPEnable=1`, `PMPGranularity=1`, and `PMPNumRegions=2`.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by running evidence/run_ibex_core_pmp_custom_reset_na4.sh and evidence/run_ibex_core_pmp_custom_reset_access.sh, then read evidence/ibex_core_pmp_custom_reset_na4_tb.sv and evidence/ibex_core_pmp_custom_reset_access_tb.sv. Trace the ibex_core PMP reset configuration and WARL handling; done means readback is 0x00001801 and the effective U-mode store raises mcause=7 instead of reaching the external data interface.

Written by the indexing model from the issue text.

Assessment

Domain
embedded-iot, testing
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
64/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.