lowRISC / lowRISC/ibex

[dv] Consider explicit PMP fail/pass checking

Open
#1,709 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

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

Description

Our currently co-simulation setup checks all memory accesses, ensuring both Spike and the RTL do the same byte accesses in the same order.

When a load or store generates a PMP failure no memory access occurs, thus nothing is checked.

It is implicitly checked because both RTL and Spike need to enter the exception handler so if the RTL fails to generate the PMP error for instance a co-simulation mismatch will occur.

However bus errors (an access returns an error response) trigger the same exception handler (same `mcause`). If the RTL let an access occur that should see a PMP failure and that access sees a bus error we'll still get a mismatch because that access will be cross checked against Spike (which won't have generated the mismatch).

So I don't think we'd miss PMP bugs with our current setup but some may prove tricky to debug.

Some explicit check that captures PMP failures and ensures spike sees the same PMP failure may be prudent. How simple would it be to implement? What changes (if any) would be required from Spike?

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 tracing the co-simulation checks for load and store accesses, PMP failures, bus errors, and the shared exception handler. Compare how the RTL and Spike represent these outcomes, then determine whether an explicit matching check is feasible and what Spike changes would be required. Done means the approach and required changes are defined and PMP failures are checked consistently.

Written by the indexing model from the issue text.

Assessment

Domain
embedded-iot, testing-qa
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.