stages.md

Design and verification stages

In CHERI Mocha we have stages to measure the design and verification progress. Moving from one stage to another requires a formal checklist and sign-off. The design stages are inspired by OpenTitan's development stages. The checklists are inspired by OpenTitan's checklists. Slight modification to the stages and checklists were made to meet the requirements for the COSMIC project.

Current status

This table shows the current design and verification stage for each block in Mocha.

Block name	Design stage	Verification stage
AXI crossbar	D0	V0
Clock manager	D0	V0
CVA6-CHERI	D0	V0
Debug module	D0	V0
Entropy source	D0	V0
GPIO	D0	V0
I2C	D0	V0
KMAC	D0	V0
Mailbox	D0	V0
PLIC	D0	V0
Power manager	D0	V0
Reset manager	D0	V0
ROM control	D0	V0
SPI device	D0	V0
SPI host	D0	V0
SRAM	D0	V0
Tag controller	D0	V0
TileLink crossbar	D0	V1
Timer	D0	V0
UART	D1	V1

Sign-off procedure

To advance a block from one stage to the next you must open a pull request with the checklist in a Markdown file called doc/proj/BLOCK.md, where BLOCK is replaced by the block's name. A checklist template is provided as a starting point. This pull request must be approved by at least three people, one of whom should ideally be someone who has not been involved in the design and the verification of the block. It should also update the table documenting the current status of each block.

Design stages

These are the stages each block goes through.

Stage	Name	Definition
D0	Initial Work	RTL being developed, not functional.
D1	Functional	Feature set finalized, spec complete CSRs identified; RTL/DV/SW collateral generated SW interface automation completed Clock(s) and reset(s) connected to all sub modules Lint run setup
D2	Feature Complete	All features implemented Feature frozen
D2S	Security Countermeasures Complete	In OpenTitan this stage is used to verify that all security countermeasures implemented. In Mocha we don't currently plan to use this stage.
D3	Design Complete	Lint/CDC clean, waivers reviewed Design optimisation for power and/or performance complete

D1 design sign-off checklist

Checklists for signing off a block at D1.

Item name	Description
SPEC_COMPLETED	Specification is 90% complete.
CSR_DEFINED	Registers defined for the primary programming model.
CLKRST_CONNECTED	Clock and reset connected to all submodules.
IP_TOP	There is an IP top that can be included in the top design.
IP_INSTANTIABLE	The IP compiles and elaborates without errors.
PHYSICAL_MACROS_DEFINED_80	Physical macros for memories and analogue components are defined and roughly 80% accurate.
FUNC_IMPLEMENTED	The main functional path is implemented to allow basic testing.
ASSERT_KNOWN_ADDED	Assert that all outputs of the blocks are “known.”
LINT_SETUP	Lint flow is set up, but it is acceptable to have warnings at this point.

D2 and D3 checklists to be added.

Verification stages

These are the verification stages each block goes through. Some items are marked as only for simulation or only for formal depending on which approaches are used in the verification process.

Stage	Name	Definition
V0	Initial Work	Testbench being developed, not functional; testplan being written; decide which methodology to use (simulation-based verification, formal-property verification (FPV), or both).
V1	Under Test	Documentation: Verification document available Testplan completed and reviewed Testbench: Simulation: Device under test (DUT) instantiated with major interfaces hooked up Formal: Testbench with DUT bound to assertion module(s) All available interface assertion monitors hooked up X / unknown checks on DUT outputs added Skeleton environment created with universal verification components Bus connections made from interface monitors to the scoreboard Simulation tests (written and passing): Sanity test accessing basic functionality Register / memory test suite Formal assertions (written and proven): All functional properties identified and described in testplan Assertions for main functional path implemented and passing (smoke check) Each input and each output is part of at least one assertion Regressions: Nightly regression set up
V2	Testing Complete	Documentation: Verification document completely written Design issues: All high priority bugs addressed Low priority bugs root-caused Simulation testbench: All interfaces hooked up and exercised All assertions written and enabled Universal verification methodology (UVM) environment: fully developed with end-to-end checks in scoreboard Formal testbench: All interfaces have assertions checking the protocol All functional assertions written and enabled Assumptions for FPV specified and reviewed Tests (written and passing): all tests planned for in the testplan Simulation functional coverage: all covergroups planned for in the testplan Regression: Simulation: all tests passing in nightly regression with multiple seeds (> 90%) Formal: 90% of properties proven in nightly regression Coverage: 90% code coverage combining simulation and formal Simulation: 90% functional coverage Formal: 75% logic cone of influence (COI) coverage for blocks using formal-only verification
V2S	Security Countermeasures Verified	In OpenTitan this is used to show that all tests are written and passing for the security countermeasures. In Mocha we don't currently plan to use this stage.
V3	Verification Complete	Design issues: all bugs addressed Simulation tests (written and passing): all tests including newly added post-V2 tests (if any) Regression: Simulation: all tests with all seeds passing 100% of properties proven (with reviewed assumptions) Coverage: 100% code coverage combining simulation and formal Simulation: 100% functional coverage with waivers Formal: 100% COI coverage for formal-only testbenches

V1 verification sign-off checklist

Checklist for signing off a block at V1.

Item name	Applies to	Description
DV_DOC_DRAFT_COMPLETED	Both	Verification document drafted with overall goal and strategy.
TESTPLAN_COMPLETED	Both	Initial test plan drafted including test points and a functional coverage plan.
TB_TOP_CREATED	Both	Top-level testbench created with DUT instantiated. Memory bus, clocks, resets and interrupts connected where applicable.
PRELIMINARY_ASSERTION_CHECKS_ADDED	Both	Available interface assertions connected up, like tlul_assert.
PRE_VERIFIED_SUB_MODULES_V1	Both	Pre-verified sub-modules must also have reached V1.
DESIGN_SPEC_REVIEWED	Both	Review the design specification.
TESTPLAN_REVIEWED	Both	Review the software tests proposed by the testplan.
STD_TEST_CATEGORIES_PLANNED	Both	The following categories of post-V1 tests have been focused on during testplan review (where applicable): error scenarios, power, performance, debug and stress.
SIM_TB_ENV_CREATED	Simulation	A UVM environment has been created with major interface agents connected. Any monitors at this point have been connected to the scoreboard.
SIM_SMOKE_TEST_PASSING	Simulation	Smoketest passing in simulation with a particular seed.
SIM_SMOKE_REGRESSION_SETUP	Simulation	Regression smoke tests selected and defined.
SIM_NIGHTLY_REGRESSION_SETUP	Simulation	Regression nightly tests selected and defined.
SIM_COVERAGE_MODEL_ADDED	Simulation	Initial functional coverage model added to the testbench environment.
FPV_MAIN_ASSERTIONS_PROVEN	Formal	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.
FPV_REGRESSION_SETUP	Formal	An FPV regression has been set up and added to top_chip_fpv_ip_cfgs.hjson

V2 and V3 checklists to be added.