[top_darjeeling] Top level csr_rw test failure(s)
Nobody has claimed this yet.
- Dominant language
- SystemVerilog
- Stars
- 3.6k
- Forks
- 1.1k
- Avg merge
- 2d 22h
- Merged PRs (30d)
- 141
Description
Top-level csr_rw test fails as a result of multiple IP block interacting, and the lack of RACL modeling in DV.
Running the top-level csr_rw test induces a failure because of the interaction between multiple IP blocks.
util/dvsim/dvsim.py hw/top_darjeeling/dv/chip_sim_cfg.hjson -i chip_csr_rw --tool xcelium --fi 1
What's happening with that fixed seed of 1 is that the csr_rw sequence reprograms the permissions in racl_ctrl and prevents itself from subsequently accessing the ac_range_check module, yielding an unexpected d_error assertion (which is a RACL error) but the DV environment presently does not model the RACL logic/error generation.
@rswarbrick @Razer6 @andreaskurth for awareness.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by running the listed chip_csr_rw command through util/dvsim/dvsim.py with hw/top_darjeeling/dv/chip_sim_cfg.hjson and the fixed seed. Trace the csr_rw sequence's changes to racl_ctrl and its access to ac_range_check; done means the DV environment models the RACL logic and error generation without the unexpected d_error assertion.
Written by the indexing model from the issue text.
Assessment
- Domain
- security, testing
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100