For detailed information on OTP_CTRL design features, please see the OTP_CTRL HW IP technical specification.
OTP_CTRL testbench has been constructed based on the CIP testbench architecture.
Top level testbench is located at hw/ip/otp_ctrl/dv/tb.sv. It instantiates the OTP_CTRL DUT module hw/ip/otp_ctrl/rtl/otp_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:
All common types and methods defined at the package level can be found in otp_ctrl_env_pkg. Some of them in use are:
parameter uint SCRAMBLE_DATA_SIZE = 64; parameter uint SCRAMBLE_KEY_SIZE = 128; parameter uint NUM_ROUND = 31; typedef enum bit [2:0] { OtpNoError, OtpMacroError, OtpMacroEccCorrError, OtpMacroEccUncorrError, OtpMacroWriteBlankError, OtpAccessError, OtpCheckFailError, OtpFsmStateError } otp_err_code_e;
OTP_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 OTP_CTRL device.
OTP_CTRL testbench instantiates (already handled in CIP base env) two alert_agents: fatal_check_alert and fatal_macro_alert. The alert_agents provide the ability to drive and independently monitor alert handshakes via alert interfaces in OTP_CTRL device.
OTP_CTRL design has specific inputs and outputs to communicate with other IPs including LC_CTRL, OTBN, SRAM, FLASH etc. This interface is created to initialize, use simple task to drive, and use assertions to monitor these signals.
OTP_CTRL testbench binds design‘s non-volatile OTP memory with a mem_bkdr_util, which supports read, write, and injection of ECC errors to design’s OTP memory.
The OTP_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.
The OTP_CTRL‘s utilizes [PRESENT](../../prim/doc/prim_present.md as the cipher to scramble and protect secrets. Thus OTP_CTRL’s scoreboard adopted PRESENT's C reference model, located under hw/ip/prim/dv/prim_present/ folder, for encryption and decryption purpose.
All test sequences reside in hw/ip/otp_ctrl/dv/env/seq_lib. The otp_ctrl_base_vseq virtual sequence is extended from cip_base_vseq and serves as a starting point. All test sequences are extended from otp_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 two files declared OTP_CTRL's covergroups:
dv/env/otp_ctrl_env_cov.sv declares functional or CSR related covergroups. The functional coverage is collected manually inside OTP_CTRL's scoreboard by invoking the sample function.dv/cov/otp_ctrl_cov_if.sv declares interface signal related covergroups. The functional coverage is collected automatically when the sampled signal is active.The otp_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:
For all requests to OTP_CTRL as listed above, scoreboard has a corresponding task to process request, check OTP_CTRL's response value against encryption, and collect coverage.
OTP_CTRL‘s scoreboard has an internal array otp_a that tracks OTP memory data. Every successful OTP write operation will update this internal array, and every successful OTP read operation will check the readout value against this internal array. Note that in design, secret partitions will go through a encryption before writing to the actually OTP memory, and will be decrypted upon a read request. For the simplicity of this internal array, we will skip this procedure. However, if scoreboard backdoor read any secret partitions, we will decrypt the data then write the decrypted data to the internal array. For any operation that fails, the scoreboard will predict the status and err_code according to the failure type. If the error can trigger alert, scoreboard will use set_exp_alert task to check if the alert is firing correctly. If a HW digest operation is triggered by sequence, scoreboard will calculate digest value with partition data from its internal array and update the digest value. According to design spec, scoreboard won’t lock the partition and predict the digest value to digest registers until next power cycle.
If a reset or lc_escalation_en is issued during an OTP_CTRL write operation, scoreboard cannot accurately predict how many bits have been programmed into OTP memory. To avoid mismatches, scoreboard utilizes flags dai_wr_ip and dai_digest_ip to track otp write operations, and issue a backdoor read if the write operation is interrupted.
tb/otp_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/otp_ctrl/dv/otp_ctrl_sim_cfg.hjson -i otp_ctrl_smoke