Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 29 additions & 1 deletion doc/proj/rstmgr.md
Original file line number Diff line number Diff line change
Expand Up @@ -44,7 +44,26 @@ This sign-off is based on commit [`d918b3e`][d1-commit].

### V1

*Not yet started - see [stages.md][verification stages].*
All checklist items refer to the [V1 verification sign-off checklist][V1 checklist].
This sign-off is based on commit [`d918b3e`][v1-commit].

| Type | Item | Status | Note/Collaterals |
|---------------|------------------------------------|--------|------------------|
| Documentation | DV_DOC_DRAFT_COMPLETED | Done | [Reset manager DV document][] describes the goals, testbench architecture, stimulus, coverage, and checking strategy |
| Documentation | TESTPLAN_COMPLETED | Done | [Reset manager testplan][] defines the V1 smoke test and post-V1 reset, crash dump capture, software reset and stress testpoints |
| Testbench | TB_TOP_CREATED | Done | [tb.sv][] instantiates the four clocks, TileLink, alert and reset manager interfaces along with the reset manager DUT; the block has no interrupts |
| Testbench | PRELIMINARY_ASSERTION_CHECKS_ADDED | Done | [rstmgr_bind.sv][] binds the TLUL protocol, CSR and reset cascading assertions; the reset manager RTL checks that outputs are known after reset |
| Integration | PRE_VERIFIED_SUB_MODULES_V1 | Waived | Generated from the OpenTitan template, where the block reached V2S ([OpenTitan rstmgr checklist][]); `rstmgr_cnsty_chk` has its own DV environment, not yet in the Mocha config |
| Review | DESIGN_SPEC_REVIEWED | Done | The specification was reviewed through the OpenTitan sign-off process, and the [theory of operation][theory] was reviewed against the Mocha instantiation for this sign-off. It describes the reset trees and their behaviour correctly but is written for the OpenTitan configuration; the differences, including that `ALERT_INFO` and `CPU_INFO` never record real state because the dump inputs are tied off, are listed alongside Mocha's reset tree, power domains and software resets in the [reset domains section][arch resets] of the architecture document |
| Review | TESTPLAN_REVIEWED | Done | The generated [OpenTitan rstmgr checklist][] records the testplan review as complete upstream. The [Reset manager testplan][] is identical to the one in `ip_templates/rstmgr` and has not been revised for Mocha. Its V1 testpoints are `smoke` plus the six imported from [`csr_testplan.hjson`][csr testplan], all written generically and covering the Mocha reset set as instantiated |
| Review | STD_TEST_CATEGORIES_PLANNED | Done | Reset race, stress, and the debug and low-power reset paths are covered in the [Reset manager testplan][] |
| Simulation | SIM_TB_ENV_CREATED | Done | CIP-based UVM environment with TL agent and scoreboard |
| Tests | SIM_SMOKE_TEST_PASSING | Done | `rstmgr_smoke`: 1/1 passed with Xcelium on September 30, 2026 at commit `d918b3e` |
Comment thread
martin-velay marked this conversation as resolved.
| Regression | SIM_SMOKE_REGRESSION_SETUP | Done | `smoke` regression in `rstmgr_sim_cfg.hjson` selects `rstmgr_smoke`; the aggregate Mocha config imports the reset manager simulation config |
| Regression | SIM_NIGHTLY_REGRESSION_SETUP | Done | The Reset manager is included in `mocha_sim_cfgs.hjson`, so it runs as part of the aggregate nightly regression; results are published on the [COSMIC dashboard][] |
| Coverage | SIM_COVERAGE_MODEL_ADDED | Done | Block-level coverage is in `rstmgr_env_cov.sv` |
| Tests | FPV_MAIN_ASSERTIONS_PROVEN | N/A | This V1 sign-off uses simulation; TLUL and CSR assertions are enabled in the simulation testbench |
| Regression | FPV_REGRESSION_SETUP | N/A | No Reset manager FPV regression is configured in Mocha |

### V2

Expand All @@ -63,7 +82,10 @@ This sign-off is based on commit [`d918b3e`][d1-commit].
[OpenTitan D3 sign-off]: https://github.com/lowRISC/opentitan/pull/24164
[OpenTitan rstmgr checklist]: ../../hw/top_chip/ip_autogen/rstmgr/doc/checklist.md
[D1 checklist]: stages.md#d1-design-sign-off-checklist
[V1 checklist]: stages.md#v1-verification-sign-off-checklist
[d1-commit]: https://github.com/lowRISC/mocha/commit/d918b3ef1b80febeccbae3c9d7d8b30edf8a1186
[v1-commit]: https://github.com/lowRISC/mocha/commit/d918b3ef1b80febeccbae3c9d7d8b30edf8a1186
[arch resets]: ../ref/arch.md#reset-domains
[theory]: ../../hw/top_chip/ip_autogen/rstmgr/doc/theory_of_operation.md
[pguide]: ../../hw/top_chip/ip_autogen/rstmgr/doc/programmers_guide.md
[registers]: ../../hw/top_chip/ip_autogen/rstmgr/doc/registers.md
Expand All @@ -74,3 +96,9 @@ This sign-off is based on commit [`d918b3e`][d1-commit].
[lint waivers]: https://github.com/lowRISC/mocha/blob/d918b3ef1b80febeccbae3c9d7d8b30edf8a1186/hw/top_chip/lint/top_chip_system.vlt#L55
[patch]: ../../hw/vendor/patches/lowrisc_ip/rstmgr
[assert patch]: ../../hw/vendor/patches/lowrisc_ip/rstmgr/0004_Add_Missing_Output_Assertions.patch
[Reset manager DV document]: ../../hw/top_chip/ip_autogen/rstmgr/dv/README.md
Comment thread
martin-velay marked this conversation as resolved.
[COSMIC dashboard]: https://cosmic-project.lowrisc.org/dashboard/index.html
[csr testplan]: ../../hw/vendor/lowrisc_ip/dv/tools/dvsim/testplans/csr_testplan.hjson
[Reset manager testplan]: ../../hw/top_chip/ip_autogen/rstmgr/data/rstmgr_testplan.hjson
[tb.sv]: ../../hw/top_chip/ip_autogen/rstmgr/dv/tb.sv
[rstmgr_bind.sv]: ../../hw/top_chip/ip_autogen/rstmgr/dv/sva/rstmgr_bind.sv
2 changes: 1 addition & 1 deletion doc/proj/stages.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,7 +23,7 @@ This table shows the current design and verification stage for each block in Moc
| [Mailbox][] | D1 | V0 |
| [PLIC][] | D1 | V0 |
| [Power manager][] | D1 | V0 |
| [Reset manager][] | D1 | V0 |
| [Reset manager][] | D1 | V1 |
| [ROM control][] | D1 | V0 |
| [SPI device][] | D1 | V0 |
| [SPI host][] | D1 | V0 |
Expand Down
34 changes: 32 additions & 2 deletions doc/ref/arch.md
Comment thread
tchilikov-semify marked this conversation as resolved.
Original file line number Diff line number Diff line change
Expand Up @@ -18,6 +18,36 @@ There are three clock domains in Mocha.<!-- rfj4pd_x -->
Both the main and IO clocks can be disabled and are turned off when a system reset is requested.<!-- 68url6_x -->
The always on clock drives the clock, reset and power managers and allows the system to come out of reset.<!-- w5ylk6_x -->

## Reset domains

Mocha has two power domains, `Aon` and `Main`, and the reset manager derives the chip's resets from them.<!-- 9g9uej_x -->
The JTAG TAP reset is the exception: `dm_jtag_trst_n` comes straight from a pin and does not pass through the reset manager.<!-- yza50i_x -->

The reset manager builds three trees.<!-- 3yv1wh_x -->

1. POR: `por_aon` is the root, driven from the top-level `rst_ni` input, and `por` and `por_io` are derived from it for the main and IO clocks.<!-- qpdwd4_x -->
2. Life cycle: `lc_src` parents the `main`, `aon`, `io`, `spi_device`, `spi_host` and `i2c` leaf resets.<!-- 44pvix_x -->
3. System: `sys_src` parents the `debug` leaf reset.<!-- 6waem2_x -->

`sys_src` has a single leaf reset, `debug`, so that the debug module survives a non-debug-module reset.<!-- iq6ugn_x -->
A non-debug-module request always asserts `lc_src`, but only asserts `sys_src` while `lc_hw_debug_en` is false.<!-- f5qo8i_x -->
However, Mocha wires `lc_hw_debug_en` to a constant `On`, so everything on `lc_src` resets and the debug module stays out of reset.<!-- jry7si_x -->

The reset manager supports four hardware reset requests: a main power glitch from the power manager, an escalation from the alert handler, a non-debug-module reset from the debug module, and an external peripheral request.<!-- 6upgjf_x -->
Only the non-debug-module request is connected in Mocha; the other three are tied off at the power manager instantiation in `top_chip_system.sv`.<!-- zufl3r_x -->
Software can also reset the whole system by writing the reset manager's `RESET_REQ` register, which the reset manager forwards to the power manager.<!-- h51zvb_x -->
Unlike a non-debug-module request this asserts both `lc_src` and `sys_src`, so the debug module resets too, and the register self-clears when the reset is acknowledged so the system does not reset repeatedly.<!-- adhb0f_x -->

Software can directly control three of the leaf resets, all on the IO clock: `spi_device`, `spi_host` and `i2c`.<!-- ih9zw0_x -->
Each has its own `SW_RST_CTRL_N` register, driven straight into the leaf, holding that one peripheral in reset while the rest of the chip keeps running, so unlike a `RESET_REQ` write they do not involve the power manager and do not self-clear.<!-- 3u6vgu_x -->
The remaining leaf resets are not software controllable.<!-- 9wq9ze_x -->
The vendored [theory of operation](../../hw/top_chip/ip_autogen/rstmgr/doc/theory_of_operation.md) describes the reset trees and their behaviour correctly, but it is written for the OpenTitan configuration and differs from Mocha, mainly:<!-- skwcio_x -->

1. It says the power-on reset is driven by AST; Mocha has no AST block, so the reset manager takes its power-on reset from `rst_ni`, an input to the Mocha enclave.<!-- lnxfen_x -->
2. It lists the OpenTitan set of software resettable blocks, which includes `usbdev`. Mocha has no USB device.<!-- rqguia_x -->
3. It names `sysrst_ctrl` and `aon_timer` as peripherals capable of requesting a reset. Neither exists in Mocha.<!-- 9x0qbx_x -->
4. It says `ALERT_INFO` and `CPU_INFO` record the alert status and CPU state before a reset. Mocha ties the alert and CPU dump inputs off, so neither register ever captures anything meaningful.<!-- iyamrn_x -->

## Memory map

This is the current memory map for Mocha, where the base and top addresses are inclusive, and reserved is the amount of memory reserved for this function:<!-- mcbp27_x -->
Expand Down Expand Up @@ -62,8 +92,8 @@ In terms of output, the top-level will need output signals:<!-- tvdygx_x -->

## CVA6-CHERI

Mocha will instantiate CVA6-CHERI.
This is specified in [cva6-cheri.md][cva6-cheri-spec].
Mocha will instantiate CVA6-CHERI.<!-- t7q0t4_x -->
This is specified in [cva6-cheri.md][cva6-cheri-spec].<!-- v78vdz_x -->

## SRAM specification

Expand Down