---
title: "Signoff Checklist"
---

This document explains the recommended checklist items to review when transitioning from one [Development Stage]({{<relref "/doc/project/development_stages.md" >}}) to another, for design, verification, and [software device interface function (DIF)]({{< relref "doc/rm/device_interface_functions.md" >}}) stages.
It is expected that the items in each stage (D1, V1, S1, etc) are completed.

## D1

For a transition from D0 to D1, the following items are expected to be completed.

### SPEC_COMPLETE

The specification is 90% complete, all features are defined.
The specification is submitted into the repository as a markdown document.
It is acceptable to make changes for further clarification or more details after the D1 stage.

### CSR_DEFINED

The CSRs required to implement the primary programming model are defined.
The Hjson file defining the CSRs is checked into the repository.
It is acceptable to add or modify registers during the D2 stage in order to complete implementation.

### CLKRST_CONNECTED

Clock(s) and reset(s) are connected to all sub-modules.

### IP_TOP

The unit `.sv` exists and meets comportability requirements.

### IP_INSTANTIABLE

The unit is able to be instantiated and connected in top level RTL files.
The design must compile and elaborate cleanly without errors.
The unit must not break top level functionality such as propagating X through TL-UL interfaces, continuously asserting alerts or interrupts, or creating undesired TL-UL transactions.

### PHYSICAL_MACROS_DEFINED_80

All expected memories have been identified and representative macros instantiated.
All other physical elements (analog components, pads, etc) are identified and represented with a behavioral model.
It is acceptable to make changes to these physical macros after the D1 stage as long as they do not have a large impact on the expected resulting area (roughly "80% accurate").

### FUNC_IMPLEMENTED

The mainline functional path is implemented to allow for a basic functionality test by verification.
("Feature complete" is the target for D2 status.)

### ASSERT_KNOWN_ADDED

All the outputs of the IP have `ASSERT_KNOWN` assertions.

### LINT_SETUP

A lint flow is setup which compiles and runs.
It is acceptable to have lint warnings at this stage.

## D2

### NEW_FEATURES

Any new features added since D1 are documented and reviewed with DV/SW/FPGA.
The GitHub Issue, Pull Request, or RFC where the feature was discussed should be linked in the `Notes` section.

### BLOCK_DIAGRAM

Block diagrams have been updated to reflect the current design.

### DOC_INTERFACE

All IP block interfaces that are not autogenerated are documented.

### MISSING_FUNC

Any missing functionality is documented.

### FEATURE_FROZEN

Feature requests for this IP version are frozen at this time.

### FEATURE_COMPLETE

All features specified are implemented.

### AREA_CHECK

An area check has been completed either on FPGA or using Synopsys Design Compiler.

### PORT_FROZEN

All ports are implemented and their specification is frozen.

### ARCHITECTURE_FROZEN

All architectural state (RAMs, CSRs, etc) is implemented and the specification frozen.

### REVIEW_TODO

All TODOs have been reviewed and signed off.

### STYLE_X

The IP block conforms to the [style guide regarding X usage](https://github.com/lowRISC/style-guides/blob/master/VerilogCodingStyle.md#dont-cares-xs).

### LINT_PASS

The lint flow passes cleanly.
Any lint waiver files have been reviewed.

### CDC_SETUP

A CDC checking run has been set up (if tooling is available).
The CDC checking run shows no must-fix errors, and a waiver file has been created.

### FPGA_TIMING

The IP block is synthesized as part of the continuous integration checking and meets timing there.

### CDC_SYNCMACRO

All CDC synchronization flops use behavioral synchronization macros (e.g. `prim_flop_2sync`) not manually created flops.

### SEC_CM_DOCUMENTED

Any appropriate security counter-measures have been documented and reviewed.
The implementation of security countermeasures can be delayed until D3 if:
- The addition of those countermeasures would not negatively impact PPA by more than 10%, and
- The software interface would not be materially affected by those countermeasures

Where the area impact of countermeasures can be reliably estimated, it is acceptable to insert dummy logic at D2 in order to meet the above criteria.

### SEC_RND_CNST

Compile-time random netlist constants (such as LFSR seeds or scrambling constants) are exposed to topgen via the `randtype` parameter mechanism in the comportable IP Hjson file.
Default random seeds and permutations for LFSRs can be generated with [the gen-lfsr-seed.py script](https://github.com/lowRISC/opentitan/blob/master/util/design/gen-lfsr-seed.py).
See also the related [GitHub issue #2229](https://github.com/lowRISC/opentitan/issues/2229).

## D2S

### SEC_CM_ASSETS_LISTED

List the assets and corresponding countermeasures in canonical format in the IP Hjson (the canonical naming is checked by the reggen tool for correctness).

This list could look, for example, as follows:
```python
# Inside the rstmgr.hjson

countermeasures: [
  { name: "BUS.INTEGRITY",
    desc: "Bus integrity check."
  },
  { name: "RST.INTEGRITY",
    desc: "Reset integrity checks."
  },
  { name: "RST.SHADOW_LOGIC",
    desc: "Shadow reset logic."
  }
  # ...
]

```

For a full list of permitted asset and countermeasure types, see the [countermeasure.py](https://github.com/lowRISC/opentitan/blob/master/util/reggen/countermeasure.py) script that implements the name checks.

Note the SEC_CM_DOCUMENTED item in the D2 checklist, which is a precursor to this step.

### SEC_CM_IMPLEMENTED

Any appropriate security counter-measures are implemented.


Note:

- For duplicated counters [`prim_count`](https://github.com/lowRISC/opentitan/blob/master/hw/ip/prim/rtl/prim_count.sv) must be used.
- For duplicated LFSRs [`prim_double_lfsr`](https://github.com/lowRISC/opentitan/blob/master/hw/ip/prim/rtl/prim_double_lfsr.sv) must be used.
- For redundantly encoded FSMs, [the sparse-fsm-encode.py script](https://github.com/lowRISC/opentitan/blob/master/util/design/sparse-fsm-encode.py) must be used to generate the encoding (in conjunction with the [`prim_sparse_fsm_flop`](https://github.com/lowRISC/opentitan/blob/master/hw/ip/prim/rtl/prim_sparse_fsm_flop.sv)) primitive.
- For multibit signals, the `mubi` types in [`prim_mubi_pkg`](https://github.com/lowRISC/opentitan/blob/master/hw/ip/prim/rtl/prim_mubi_pkg.sv) should be used if possible.

### SEC_CM_RTL_REVIEWED

If deemed necessary by the security council, an offline review of the RTL code sections pertaining to the assets and countermeasures listed in SEC_CM_ASSETS_LISTED has been performed.

### SEC_CM_COUNCIL_REVIEWED

Security council has reviewed the asset list and associated documentation (SEC_CM_ASSETS_LISTED, SEC_CM_DOCUMENTED) and deems the defenses implemented appropriate.

The security council decides whether an additional RTL review of the relevant code sections is necessary (SEC_CM_RTL_REVIEWED).

## D3

### NEW_FEATURES_D3

Any approved new features since D2 have been documented and reviewed with DV/SW/FPGA

### TODO_COMPLETE

All TODOs are resolved.

### LINT_COMPLETE

The lint checking flow is clean.
Any lint waiver files have been reviewed and signed off by the technical steering committee.

### CDC_COMPLETE

The CDC checking flow is clean.
CDC waiver files have been reviewed and signed off by the technical steering committee.

### REVIEW_RTL

A simple design review has been conducted by an independent designer.

### REVIEW_DELETED_FF

Any deleted flops have been reviewed and signed off.

### REVIEW_SW_CSR

Any design changes which affect CSRs have been reviewed by the software team.

### REVIEW_SW_FATAL_ERR

Any fatal error mechanisms have been reviewed by the software team.

### REVIEW_SW_CHANGE

Any other software-visible design changes have been reviewed by the software team.

### REVIEW_SW_ERRATA

All known "Won't Fix" bugs and "Errata" have been reviewed by the software team.

### SEC_NON_RESET_FLOPS

A review of sensitive security-critical storage flops was completed.
Where appropriate, non-reset flops are used to store secure material.

### SEC_SHADOW_REGS

Shadow registers are implemented for all appropriate storage of critical control functions.

## V1

To transition from V0 to V1, the following items are expected to be completed.
The prefix "SIM" is applicable for simulation-based DV approaches, whereas the prefix "FPV" is applicable for formal property-based verification approaches.

### DV_DOC_DRAFT_COMPLETED

A DV document has been drafted, indicating the overall DV goals, strategy, the testbench environment details with diagram(s) depicting the flow of data, UVCs, checkers, scoreboard, interfaces, assertions and the rationale for the chosen functional coverage plan.
Details may be missing since most of these items are not expected to be fully understood at this stage.

### TESTPLAN_COMPLETED

A testplan has been written (in HJson format) indicating:
- Testpoints (a list of planned tests), each mapping to a design feature, with a description highlighting the goal of the test and optionally, the stimulus and the checking procedure.
- The functional coverage plan captured as a list of covergroups, with a description highlighting which feature is expected to be covered by each covergroup.
  It may optionally contain additional details such as coverpoints and crosses of individual aspects of the said feature that is covered.

### TB_TOP_CREATED

A top level testbench has been created with the DUT instantiated.
The following interfaces are connected (as applicable): TileLink, clocks and resets, interrupts and major DUT interfaces.
Some minor interfaces may not be connected at this point.
Inputs for which interfaces have not yet been created are tied off to 0.

### PRELIMINARY_ASSERTION_CHECKS_ADDED

All available interface assertion monitors are connected (example: tlul_assert).

### SIM_TB_ENV_CREATED

A UVM environment has been created with major interface agents and UVCs connected and instantiated.
TLM port connections have been made from UVC monitors to the scoreboard.

### SIM_RAL_MODEL_GEN_AUTOMATED

A RAL model is generated using [regtool]({{< relref "/util/reggen/README.md" >}}) and instantiated in the UVM environment.

### CSR_CHECK_GEN_AUTOMATED

A CSR check is generated using [regtool]({{< relref "/util/reggen/README.md" >}}) and bound in the TB environment.

### TB_GEN_AUTOMATED

Full testbench automation has been completed if applicable.
This may be required for verifying multiple flavors of parameterized DUT designs.

### SIM_SMOKE_TEST_PASSING

A smoke test exercising the basic functionality of the main DUT datapath is passing.
The functionality to test (and to what level) may be driven by higher level (e.g. chip) integration requirements.
These requirements are captured when the testplan is reviewed by the key stakeholders, and the test(s) updated as necessary.

### SIM_CSR_MEM_TEST_SUITE_PASSING

CSR test suites have been added for ALL interfaces (including, but not limited to the DUT's SW device acess port, JTAG access port etc.) that have access to the system memory map:
- HW reset test (test all resets)
- CSR read/write
- Bit Bash
- Aliasing

Memory test suites have been added for ALL interfaces that have access to the system memory map if the DUT has memories:
- Mem walk

All these tests should verify back to back accesses with zero delays, along with partial reads and partial writes.

### FPV_MAIN_ASSERTIONS_PROVEN

Each input and each output of the module is part of at least one assertion.
Assertions for the main functional path are implemented and proven.

### SIM_ALT_TOOL_SETUP

The smoke regression passes cleanly (with no warnings) with one additional tool apart from the primary tool selected for signoff.

### SIM_SMOKE_REGRESSION_SETUP

A small suite of tests has been identified as the smoke regression suite and is run regularly to check code health.
If the testbench has more than one build configuration, then each configuration has at least one test added to the smoke regression suite.

### SIM_NIGHTLY_REGRESSION_SETUP

A nightly regression for running all constrained-random tests with multiple random seeds (iterations) has been setup.
Directed, non-random tests need not be run with multiple iterations.
Selecting the number of iterations depends on the coverage, the mean time between failure and the available compute resources.
For starters, it is recommended to set the number of iterations to 100 for each test.
It may be trimmed down once the test has stabilized, and the same level of coverage is achieved with fewer iterations.
The nightly regression should finish overnight so that the results are available the next morning for triage.

### FPV_REGRESSION_SETUP

An FPV regression has been set up by adding the module to the `hw/formal/fpv_all` script.

### SIM_COVERAGE_MODEL_ADDED

A structural coverage collection model has been checked in.
This is a simulator-specific file (i.e. proprietary format) that captures which hierarchies and what types of coverage are collected.
For example, pre-verified sub-modules (including some `prim` components pre-verified thoroughly with FPV) can be black-boxed - it is sufficient to only enable the IO toggle coverage of their ports.
A functional coverage shell object has been created - this may not contain coverpoints or covergroups yet, but it is primed for development post-V1.

### TB_LINT_SETUP

[VeribleLint](https://google.github.io/verible/verilog_lint.html) for the testbench is [set up]({{< relref "hw/lint/doc/README.md" >}}) to run in nightly regression, with appropriate waivers.
* For a constrained random testbench, an entry has been added to `hw/<top-level-design>/lint/<top-level-design>_dv_lint_cfgs.hjson`
* For an FPV testbench, an entry has been added to `hw/<top-level-design>/lint/<top-level-design>_fpv_lint_cfgs.hjson`

### PRE_VERIFIED_SUB_MODULES_V1

Sub-modules that are pre-verified with their own testbenches have already reached V1 or a higher stage.
The coverage level of the pre-verified sub-modules that are not tracked (i.e., not taken through the verification milestones), meets or exceeds the V1 milestone requirement.
They are clearly cited in the DV document and the coverage of these sub-modules can be excluded in the IP-level testbench.

### DESIGN_SPEC_REVIEWED

The design / micro-architecture specification has been reviewed and signed off.
If a product requirements document (PRD) exists, then ensure that the design specification meets the product requirements.

### TESTPLAN_REVIEWED

The draft DV document (proposed testbench architecture) and the complete testplan have been reviewed with key stakeholders (as applicable):
- DUT designer(s)
- 1-2 peer DV engineers
- Software engineer (DIF developer)
- Chip architect / design lead
- Chip DV lead
- Security architect

### STD_TEST_CATEGORIES_PLANNED

The following categories of post-V1 tests have been focused on during the testplan review (as applicable):
- Security / leakage
- Error scenarios
- Power
- Performance
- Debug
- Stress

### V2_CHECKLIST_SCOPED

The V2 checklist has been reviewed to understand the scope and estimate effort.

## V2

To transition from V1 to V2, the following items are expected to be completed.
The prefix "SIM" is applicable for simulation-based DV approaches, whereas the prefix "FPV" is applicable for formal property-based verification approaches.

### DESIGN_DELTAS_CAPTURED_V2

It is possible for the design to have undergone some changes since the DV document and testplan were reviewed in the V0 stage.
All design deltas have been captured adequately and appropriately in the DV document and the testplan.

### DV_DOC_COMPLETED

The DV document is fully complete.

### FUNCTIONAL_COVERAGE_IMPLEMENTED

The functional coverage plan is fully implemented.
All covergoups have been created and sampled in the reactive components of the testbench (passive interfaces, monitors and scoreboards).

### ALL_INTERFACES_EXERCISED

For simulations, all interfaces are connected to all sidebands and exercised.
For an FPV testbench, assertions have been added for all interfaces including sidebands.

### ALL_ASSERTION_CHECKS_ADDED

All planned assertions have been written and enabled.

### SIM_TB_ENV_COMPLETED

A UVM environment has been fully developed with end-to-end checks in the scoreboard enabled.

### SIM_ALL_TESTS_PASSING

All tests in the testplan have been written and are passing with at least one random seed.

### FPV_ALL_ASSERTIONS_WRITTEN

All assertions (except security countermeasure assertions) are implemented and are 90% proven.
Each output of the module has at least one forward and one backward assertion check.
The FPV proof run converges within reasonable runtime.

### FPV_ALL_ASSUMPTIONS_REVIEWED

All assumptions have been implemented and reviewed.

### SIM_FW_SIMULATED

Chip-level tests exist to verify example firmware code (DIFs) in simulation.

### SIM_NIGHTLY_REGRESSION_V2

A nightly regression with multiple random seeds is 90% passing.

### SIM_CODE_COVERAGE_V2

Line, toggle, fsm (state & transition), branch and assertion code coverage has reached 90%.

### SIM_FUNCTIONAL_COVERAGE_V2

Functional coverage has reached 70%.

### FPV_CODE_COVERAGE_V2

Branch, statement and functional code coverage for FPV testbenches has reached 90%.

### FPV_COI_COVERAGE_V2

COI coverage for FPV testbenches has reached 75%.

### TB_LINT_PASS

The lint checking flow for the testbench passes cleanly.
Any waiver files have been reviewed.

### PRE_VERIFIED_SUB_MODULES_V2

Sub-modules that are pre-verified with their own testbenches have already reached V2 or a higher stage.
The coverage level of the pre-verified sub-modules that are not tracked (i.e., not taken through the verification milestones), meets or exceeds the V2 milestone requirement.

### SEC_CM_PLANNED

<!-- TODO, add the link to security hardening guidelines doc -->
Security countermeasures are planned and documented.
- Common countermeasure features (such as shadowed reg, hardened counter etc) can be tested by importing common sec_cm testplans, tests and adding the bind file `cm_sec_bind`.
- Additional checks and sequences may be needed to verify those features. Document those in the individual testplan.
- Create testplan for non-common countermeasures.

### NO_HIGH_PRIORITY_ISSUES_PENDING

All high priority (tagged P0 and P1) design bugs have been addressed and closed.
If the bugs were found elsewhere, ensure that they are reproduced deterministically in DV (through additional tests or by tweaking existing tests as needed) and have the design fixes adequately verified.

### ALL_LOW_PRIORITY_ISSUES_ROOT_CAUSED

All low priority (tagged P2 and P3) design bugs have been root-caused.
They may be deferred to post V2 for closure.

### DV_DOC_TESTPLAN_REVIEWED

The DV document and testplan are complete and have been reviewed by key stakeholders (as applicable):
- DUT designer(s)
- 1-2 peer DV engineers
- Chip architect / design lead
- Chip DV lead
- Security architect

This review will focus on the design deltas captured in the tesplan since the last review.
In addition, the fully implemented functional coverage plan, the observed coverage and the coverage exclusions are expected to be scrutinized to ensure there are no verification holes or any gaps in achieving the required stimulus quality, before the work towards progressing to V3 can commence.

### V3_CHECKLIST_SCOPED

The V3 checklist has been reviewed to understand the scope and estimate effort.

## V2S

### FPV_SEC_CM_PROVEN

<!-- TODO, add the link to cm verif methodology doc -->
All security countermeasure assertions are proven in FPV.

### SIM_SEC_CM_VERIFIED

<!-- TODO, add the link to cm verif methodology doc -->
Security countermeasures are verified in simulation.

## V3

To transition from V2 to V3, the following items are expected to be completed.
The prefix "SIM" is applicable for simulation-based DV approaches, whereas the prefix "FPV" is applicable for formal property-based verification approaches.

### DESIGN_DELTAS_CAPTURED_V3

Although rare, it is possible for the design to have undergone some last-minute changes since V2.
All additional design deltas have been captured adequately and appropriately in the DV document and the testplan.

### X_PROP_ANALYSIS_COMPLETED

X Propagation analysis has been completed.

### FPV_ASSERTIONS_PROVEN_AT_V3

All assertions are implemented and 100% proven.
There are no undetermined or unreachable properties.

### SIM_NIGHTLY_REGRESSION_AT_V3

A nightly regression with multiple random seeds is 100% passing (with 1 week minimum soak time).

### SIM_CODE_COVERAGE_AT_100

Line, toggle, fsm (state & transition), branch and assertion code coverage has reached 100%.

### SIM_FUNCTIONAL_COVERAGE_AT_100

Functional coverage has reached 100%.

### FPV_CODE_COVERAGE_AT_100

Branch, statement and functional code coverage for FPV testbenches has reached 100%.

### FPV_COI_COVERAGE_AT_100

COI coverage for FPV testbenches has reached 100%.

### ALL_TODOS_RESOLVED

There are no remaining TODO items anywhere in the testbench code, including common components and UVCs.

### NO_TOOL_WARNINGS_THROWN

There are no compile-time or run-time warnings thrown by the simulator.

### TB_LINT_COMPLETE

The lint flow for the testbench is clean.
Any lint waiver files have been reviewed and signed off by the technical steering committee.

### PRE_VERIFIED_SUB_MODULES_V3

Sub-modules that are pre-verified with their own testbenches have already reached the V3 stage.
The coverage level of the pre-verified sub-modules that are not tracked (i.e., not taken through the verification milestones), meets the V3 milestone requirement.

### NO_ISSUES_PENDING

All design and testbench bugs have been addressed and closed.

## S1

For a transition from S0 to S1, the following items are expected to be completed.

### DIF_EXISTS

`dif_<ip>.h` and, optionally, `dif_<ip>.c` exist in `sw/device/lib/dif`.

### DIF_USED_IN_TREE

All existing non-production code in the tree which uses the device does so via the DIF or a production driver.

### DIF_TEST_UNIT

Software unit tests exist for the DIF in `sw/device/tests/dif` named `dif_<ip>_unittest.cc`.

### DIF_TEST_SMOKE

Smoke tests exist for the DIF in `sw/device/tests` named `<ip>_smoketest.c`.

This should perform a basic test of the main datapath of the hardware module by the embedded core, via the DIF, and should be able to be run on all OpenTitan platforms (including FPGA, simulation, and DV).
This test will be shared with DV.

Smoke tests are for diagnosing major issues in both software and hardware, and with this in mind, they should execute quickly.
Initially we expect this kind of test to be written by hardware designers for debugging issues during module development.
This happens long before a DIF is implemented, so there are no requirements on how these should work, though we suggest they are placed in `sw/device/tests/<ip>/<ip>.c` as this has been the convention until now.
Later, when a DIF is written, the DIF author is responsible for updating this test to use the DIF, and for moving this test into the aforementioned location.

## S2

For a transition from S1 to S2, the following items are expected to be completed.

### DIF_FEATURES

The DIF has functions to cover all specified hardware functionality.

### DIF_HW_USAGE_REVIEWED

The DIF's usage of its respective IP device has been reviewed by the device's hardware designer.

### DIF_HW_FEATURE_COMPLETE

The DIF's respective device IP is at least stage D2.

### DIF_HW_PARAMS

The DIF uses automatically generated HW parameters and register definitions.

### DIF_DOC_HW

The HW IP Programmer's guide references specific DIF APIs that can be used for operations.

### DIF_CODE_STYLE

The DIF follows DIF-specific guidelines in [`sw/device/lib/dif/README.md`]({{< relref "sw/device/lib/dif/README.md" >}}) and the OpenTitan C style guidelines.

### DIF_DV_TESTS

Chip-level DV testing for the IP using DIFs has been started.

## S3

For a transition from S2 to S3, the following items are expected to be completed.

### DIF_HW_DESIGN_COMPLETE

The DIF's respective device IP is at least stage D3.

### DIF_HW_VERIFICATION_COMPLETE

The DIF's respective device IP is at least stage V3.

### DIF_REVIEW_C_STABLE

The C interface and its implementation have been fully re-reviewed, with a view to the interface not changing in future.

### DIF_TEST_UNIT_COMPLETE

Unit tests exist to cover (at least):

- Device Initialisation
- All Device FIFOs (including when empty, full, and adding data)
- All Device Registers
- All DIF Functions
- All DIF return codes

### DIF_TODO_COMPLETE

All DIF TODOs are complete.