The following sub-modules are pre-verified:
Only toggle coverage on the IOs of these sub-modules is enabled for coverage collection.
For detailed information on SRAM_CTRL design features, please see the SRAM_CTRL HWIP technical specification.
SRAM_CTRL testbench has been constructed based on the CIP testbench architecture. Note that there are 2 separate TLUL interfaces exposed to the rest of the OpenTitan system - one for CSR accesses, and one for accessing memory directly. This is because the “full” DUT consists of the actual SRAM memory controller (which contains the CSR file) connected to a scrambling RAM primitive, with a TLUL adapter module to convert TL requests on the memory TL interface into SRAM format for the RAM primitive.
Top level testbench is located at hw/ip/sram_ctrl/dv/tb/tb.sv. It instantiates the SRAM_CTRL DUT module hw/ip/sram_ctrl/rtl/sram_ctrl.sv. In addition, it instantiates the following interfaces, connects them to the DUT and sets their handle into uvm_config_db:
pins_if)alert_esc_if)pins_if)The following utilities provide generic helper tasks and functions to perform activities that are common across the project:
Two compile-time configurations are tested:
sram_ctrl_main - this configuration uses a 15-bit wide address space to emulate the main SRAM used in the full design and enables parameter INSTR_EXEC to allow TLUL instruction fetching when some runtime conditions are met.sram_ctrl_ret - this configuration uses a 10-bit-wide address space to emulate the retention SRAM used in the full design and turns off parameter INSTR_EXEC to disable TLUL instruction fetching altogether.A macro-define SRAM_ADDR_WIDTH is defined as a build option in hw/ip/sram_ctrl/dv/sram_ctrl_base_sim_cfg.hjson, which is used to set the correct compile-time settings for each configuration.
All common types and methods defined at the package level can be found in sram_ctrl_env_pkg. Some of them in use are:
// number of bits in a full KDI transactions parameter int KDI_DATA_SIZE = 1 + otp_ctrl_pkg::SramKeyWidth + otp_ctrl_pkg::SramNonceWidth; // a completed KDI transaction takes 4 cycles to be fully synchronized into the // SRAM clock domain parameter int KDI_PROPAGATION_CYCLES = 4; // a LC escalation request needs 3 cycles to be fully propagated through the DUT parameter int LC_ESCALATION_PROPAGATION_CYCLES = 3; typedef enum bit { SramCtrlRenewScrKey = 0, SramCtrlInit = 1 } sram_ctrl_e; typedef enum bit [2:0] { SramCtrlError = 0, SramCtrlEscalated = 1, SramCtrlScrKeyValid = 2, SramCtrlScrKeySeedValid = 3, SramCtrlInitDone = 4 } sram_ctrl_status_e;
SRAM_CTRL testbench instantiates (already handled in CIP base env) tl_agent which provides the ability to drive and independently monitor random traffic via TL host interface into SRAM_CTRL device.
The SRAM_CTRL testbench instantiates 2 alert agents for:
The alert agents provide the ability to independently drive and monitor both alert handshakes.
The SRAM_CTRL IP has a simple sideband interface to the LC_CTRL to receive escalation requests. This interface initializes the escalation bus and utilizes a simple task to drive escalation requests.
The SRAM_CTRL IP has an interface to enable instruction execution from SRAM - allowing the Icache to fetch instruction data from the SRAM for the CPU. This interface contains the necessary Lifecycle and OTP structs to enable and disable this functionality.
The SRAM_CTRL RAL model is created with the ralgen FuseSoC generator script automatically when the simulation is at the build stage.
It can be created manually by invoking regtool:
Besides default RAL that provides the access to CSRs, there is another RAL for SRAM memory. This RAL is in sram_ctrl_prim_ral_pkg.sv, it is added manually and enabled with all the common CSR and memory tests, such as mem_walk, tl_errors, tl_intg_err, etc.
There are 3 DV reference models used in this testbench.
sram_scrambler_pkg is tightly integrated with the mem_bkdr_util for ease of use such that we can choose to enable encryption on any backdoor access.mem_model is also enabled in cip_base_scoreboard. The model is invoked at the end of the transaction as follows:There are some limitations in the frontdoor check as follows:
mem_bkdr_scb is used to ensure frontdoor access matches with the backdoor expected value. The sram_scrambler_pkg is invoked in mem_bkdr_scb This backdoor check covers all the limitations of frontdoor check. There is a limitation as follows, which can be covered by frontdoor check.All test sequences reside in hw/ip/sram_ctrl/dv/env/seq_lib. The sram_ctrl_base_vseq virtual sequence is extended from cip_base_vseq and serves as a starting point. All test sequences are extended from sram_ctrl_base_vseq. It provides commonly used handles, variables, functions and tasks that the test sequences can simple use / call. Some of the most commonly used tasks / functions are as follows:
To ensure high quality constrained random stimulus, it is necessary to develop a functional coverage model. The following covergroups have been developed to prove that the test intent has been adequately met:
The sram_ctrl_scoreboard is primarily used for end to end checking. It creates the following analysis ports to retrieve the data monitored by corresponding interface agents:
All CSR accesses made to the SRAM_CTRL register file are tracked and predicted by the scoreboard.
Verifying memory accesses is somewhat involved, and makes heavy use of the mem_bkdr_util.
At a high level, whenever a TL access is made to memory, all relevant information is stored in an sram_trans_t struct.
Refer to section “Reference models” for the SRAM memory checking.
The testbench will also sporadically trigger the DUT to issue a request for a new key and nonce from the OTP controller. After receiving the fresh key and nonce from the KDI agent, those new values will then be used for all encryption/decryption accesses using the memory backdoor interface.
If a lifecycle escalation request is issued during SRAM operation, the scoreboard will detect it and then check that no further memory requests are accepted. The testbench will then issue a system-level reset, as a lifecycle escalation is a terminal state.
To check that the SRAM‘s executable configurations are functioning correct is relatively more straightforward. First, it’s important to note that all incoming TL memory transactions are tagged as either InstrType or DataType, indicating whether the transaction is fetching an instruction word or a data word. If the scoreboard detects that an incoming transaction is tagged as InstrType, we first check that the SRAM is properly configured in executable mode to accept InstrType transactions. If the DUT is configured correctly the scoreboard will let the memory transaction finish being checked, otherwise the scoreboard will discard that transaction - this approach makes it easy to check whether the design is behaving correctly as well.
tb/sram_ctrl_bind.sv binds the tlul_assert assertions to the IP to ensure TileLink interface protocol compliance.We are using our in-house developed regression tool for building and running our tests and regressions. Please take a look at the link for detailed information on the usage, capabilities, features and known issues. Here's how to run a smoke test:
$ $REPO_TOP/util/dvsim/dvsim.py $REPO_TOP/hw/ip/sram_ctrl/dv/sram_ctrl_${VARIANT}_sim_cfg.hjson -i sram_ctrl_smoke
In this run command, $VARIANT can be main or ret.