lowRISC / lowRISC/opentitan

[rom/sram/flash] Memory initialization and read/write operations require tidying

Open
#26,486 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
SystemVerilog
Stars
3.6k
Forks
1.1k
Avg merge
2d 22h
Merged PRs (30d)
141

Description

Description

There are a number of deficiencies in memory initialization and access in the top-level environments presently. Ideally much of the code in the top-level testbenches, e.g. that relating to sw_symbol_backdoor_overwrite()/read(), would be memory-agnostic and have byte-level access with the memory access class/model automatically performing any necessary scrambling/unscrambling of address/data and updating any digests as required.

Placeholder; accumulating related TODOs from Darjeeling DV bring up....

  • The top-level test benches need to be able to modify variables within memories controlled by rom_ctrl, flash_ctrl or sram_ctrl, and for consistency should be able to read those back too. This needs byte-level read and write access. Presently a number of these memories cannot be read or will not return the correctly-unscrambled/decrypted data, which means that 'sw_symbol_backdoor_read()' will not operate correctly.

  • Retaining the memory-specific properties such as 'key' and 'nonce' values is important, but obviously does not belong in any base class since they are specific to the memory type. There are two rom_ctrl instances in Darjeeling already, and at least two sram_ctrl instances with different properties in each of Earl Grey (main and retention) and Darjeeling (main, retention and ctn SRAMs).

  • The SRAM models may or may not employ scrambling and may consist of multiple 'tiles' (sub-memories). This should fact should be concealed from the top-level test bench code, since they are accessed from multiple places within each of multiple test benches.

  • ROM control and flash control are simpler, but the scrambling information (key/nonce) should be stored within the object rather than requiring the test bench code to supply them explicitly. These are build-time values so may readily be supplied in the test bench code (tb.sv) when the memory access is set up.

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 with the top-level testbenches and tb.sv, then trace sw_symbol_backdoor_overwrite() and sw_symbol_backdoor_read() into the memory access models. Review the related rom_ctrl, flash_ctrl and sram_ctrl TODOs and existing memory-specific key, nonce and tile handling. Done means the scope and design are agreed and the listed memories support consistent byte-level read/write access with correct scrambling and digest behavior.

Written by the indexing model from the issue text.

Assessment

Domain
embedded-iot, testing
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.