| @@ -1,5 +1,5 @@ |
| 1 | 1 | <div style="font-size: 0.85em; color: #656d76; margin-bottom: 1em; padding: 0.5em; background: #f6f8fa; border-radius: 4px;"> |
| 2 | | -📄 Source: <a href="https://github.com/chipsalliance/caliptra-ss/blob/9022fc2a57bb9af2f3ebc2376b98a807812e2e0f/docs/CaliptraSSIntegrationSpecification.md" target="_blank">chipsalliance/caliptra-ss/docs/CaliptraSSIntegrationSpecification.md</a> @ <code>9022fc2</code> |
| 2 | +📄 Source: <a href="https://github.com/chipsalliance/caliptra-ss/blob/db18d34fea2f87fea85e2e9986ddc0d25cdc084e/docs/CaliptraSSIntegrationSpecification.md" target="_blank">chipsalliance/caliptra-ss/docs/CaliptraSSIntegrationSpecification.md</a> @ <code>db18d34</code> |
| 3 | 3 | </div> |
| 4 | 4 | |
| 5 | 5 | <div align="center"> |
| @@ -7,7 +7,7 @@ |
| 7 | 7 | </div> |
| 8 | 8 | |
| 9 | 9 | <h1 align="center"> Caliptra Subsystem Integration Specification </h1> |
| 10 | | -<h3 align="center"> Version 2.0.1 </h3> |
| 10 | +<h3 align="center"> Version 2p1 </h3> |
| 11 | 11 | |
| 12 | 12 | - [Scope](#scope) |
| 13 | 13 | - [Document Version](#document-version) |
| @@ -22,6 +22,7 @@ |
| 22 | 22 | - [Caliptra Subsystem Top](#caliptra-subsystem-top) |
| 23 | 23 | - [Parameters \& Defines](#parameters--defines) |
| 24 | 24 | - [Interfaces \& Signals](#interfaces--signals) |
| 25 | + - [Strap Timing Requirements](#strap-timing-requirements) |
| 25 | 26 | - [AXI Interface (axi\_if)](#axi-interface-axi_if) |
| 26 | 27 | - [Caliptra Subsystem Top Interface \& Signals](#caliptra-subsystem-top-interface--signals) |
| 27 | 28 | - [Integration Requirements](#integration-requirements) |
| @@ -71,16 +72,20 @@ |
| 71 | 72 | - [Programming interface](#programming-interface-1) |
| 72 | 73 | - [Readout Sequence](#readout-sequence) |
| 73 | 74 | - [Sequences: Reset, Boot](#sequences-reset-boot) |
| 75 | + - [UDS \& Field Entropy FIPS Zeroization Sequence](#uds--field-entropy-fips-zeroization-sequence) |
| 76 | + - [FIPS Zeroization Sequence For ECC](#fips-zeroization-sequence-for-ecc) |
| 77 | + - [Miscellaneous Fuse Integration Guidelines](#miscellaneous-fuse-integration-guidelines) |
| 74 | 78 | - [How to test : Smoke \& more](#how-to-test--smoke--more) |
| 75 | 79 | - [Generating the Fuse Partitions](#generating-the-fuse-partitions) |
| 76 | 80 | - [Fuse Controller Macro](#fuse-controller-macro) |
| 77 | 81 | - [Overview](#overview-4) |
| 78 | | - - [Paramteres \& Defines](#paramteres--defines) |
| 82 | + - [Parameters \& Defines](#parameters--defines) |
| 79 | 83 | - [FC Macro Integration Requirements](#fc-macro-integration-requirements) |
| 80 | 84 | - [Generic Strap Port Usage for FC Register Locations](#generic-strap-port-usage-for-fc-register-locations) |
| 81 | 85 | - [Why These Straps Are Needed](#why-these-straps-are-needed) |
| 82 | 86 | - [Strap Definitions](#strap-definitions) |
| 83 | 87 | - [FC Macro Test Interface](#fc-macro-test-interface) |
| 88 | + - [Life Cycle OTP Programming Behavior and Integrator Responsibilities](#life-cycle-otp-programming-behavior-and-integrator-responsibilities) |
| 84 | 89 | - [Life Cycle Controller](#life-cycle-controller) |
| 85 | 90 | - [Overview](#overview-5) |
| 86 | 91 | - [Parameters \& Defines](#parameters--defines-3) |
| @@ -115,15 +120,15 @@ |
| 115 | 120 | - [MCU Mailbox Limited Trusted AXI users](#mcu-mailbox-limited-trusted-axi-users) |
| 116 | 121 | - [Reset](#reset-1) |
| 117 | 122 | - [MCU Mailbox Doorbell Command DLEN](#mcu-mailbox-doorbell-command-dlen) |
| 118 | | - - [MCI Debug Lock Status](#mci-debug-lock-status) |
| 119 | | - - [MCU to SOC Receiver Flow](#mcu-to-soc-receiver-flow) |
| 120 | | - - [SOC Sender to MCU Flow](#soc-sender-to-mcu-flow) |
| 121 | | - - [SOC Sender to SOC Receiver Communication Flow (MCU as intermediary)](#soc-sender-to-soc-receiver-communication-flow-mcu-as-intermediary) |
| 123 | + - [MCU to SOC Target Flow](#mcu-to-soc-target-flow) |
| 124 | + - [SOC Requester to MCU Flow](#soc-requester-to-mcu-flow) |
| 125 | + - [SOC Requester to SOC Target Communication Flow (MCU as intermediary)](#soc-requester-to-soc-target-communication-flow-mcu-as-intermediary) |
| 122 | 126 | - [MCU JTAG/DMI Access](#mcu-jtagdmi-access) |
| 123 | 127 | - [MCU SRAM JTAG Access](#mcu-sram-jtag-access) |
| 124 | 128 | - [MCU Trace Buffer](#mcu-trace-buffer) |
| 125 | 129 | - [MCU Halt Ack Interface](#mcu-halt-ack-interface) |
| 126 | 130 | - [Sequences : Reset, Boot,](#sequences--reset-boot) |
| 131 | + - [MCI Debug Lock Status](#mci-debug-lock-status) |
| 127 | 132 | - [MCI Boot Sequencer](#mci-boot-sequencer) |
| 128 | 133 | - [Breakpoint Flow](#breakpoint-flow) |
| 129 | 134 | - [MCU No ROM Config](#mcu-no-rom-config) |
| @@ -160,6 +165,8 @@ |
| 160 | 165 | - [Known Lint Issue](#known-lint-issue) |
| 161 | 166 | - [Signal Width Mismatches](#signal-width-mismatches) |
| 162 | 167 | - [Undriven signals](#undriven-signals) |
| 168 | +- [Trademark Compliance](#trademark-compliance) |
| 169 | + - [SoC Integration Requirements](#soc-integration-requirements) |
| 163 | 170 | - [Terminology](#terminology) |
| 164 | 171 | |
| 165 | 172 | |
| @@ -173,7 +180,8 @@ |
| 173 | 180 | | Date | Document Version | Description | |
| 174 | 181 | | ----------------- | -------------------- | ------------------- | |
| 175 | 182 | | Jan 31st, 2025 | v0p8 | Work in progress | |
| 176 | | -| Apr 30th, 2025 | v1p0-rc1 | Initial release candidate of Caliptra Gen 2.0 Subsystem Documents.<br>Specifcations updated with:<br> - Detail on usage of all Subsystem flows such as Streaming Boot, Mailbox operation, and Debug Unlock<br> - Details on design connectivity with top-level ports<br> - Requirements and recommendations for integrators when adding Caliptra Subsystem to SoC designs | |
| 183 | +| Apr 30th, 2025 | v1p0-rc1 | Initial release candidate of Caliptra Gen 2.0 Subsystem Documents.<br>Specifications updated with:<br> - Detail on usage of all Subsystem flows such as Streaming Boot, Mailbox operation, and Debug Unlock<br> - Details on design connectivity with top-level ports<br> - Requirements and recommendations for integrators when adding Caliptra Subsystem to SoC designs | |
| 184 | +| Oct 12th, 2025 | v2p1 | Final release of Caliptra Subsystem 2.1 | |
| 177 | 185 | |
| 178 | 186 | |
| 179 | 187 | </div> |
| @@ -188,7 +196,7 @@ |
| 188 | 196 | | --------------- | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | |
| 189 | 197 | |
| 190 | 198 | | Caliptra | [GitHub - chipsalliance/Caliptra](https://github.com/chipsalliance/Caliptra)| [Caliptra Gen 2.0 Specification](https://github.com/chipsalliance/Caliptra/blob/main/doc/caliptra_20/Caliptra.md) |
| 191 | | -| Caliptra-SS | [GitHub - chipsalliance/caliptra-ss](https://github.com/chipsalliance/caliptra-ss)| [Hardware Specification Document](https://github.com/chipsalliance/caliptra-ss/blob/main/docs/CaliptraSSHardwareSpecification.md) |
| 199 | +| Caliptra-SS | [GitHub - chipsalliance/caliptra-ss](https://github.com/chipsalliance/caliptra-ss)| [Hardware Specification Document](./CaliptraSSHardwareSpecification.md) |
| 192 | 200 | | Caliptra-rtl | [GitHub - chipsalliance/caliptra-rtl](https://github.com/chipsalliance/caliptra-rtl) | [Caliptra RTL documentation](https://github.com/chipsalliance/caliptra-rtl/tree/main/docs) | |
| 193 | 201 | | Cores-VeeR | [GitHub - chipsalliance/Cores-VeeR-EL2](https://github.com/chipsalliance/Cores-VeeR-EL2) | [VeeR EL2 Programmer’s Reference Manual](https://chipsalliance.github.io/Cores-VeeR-EL2/html/main/docs_rendered/html/index.html) | |
| 194 | 202 | | I3C-Core | [GitHub - chipsalliance/i3c-core](https://github.com/chipsalliance/i3c-core) | [I3C core documentation](https://github.com/chipsalliance/i3c-core?tab=readme-ov-file#i3c-core) | |
| @@ -224,13 +232,14 @@ |
| 224 | 232 | |
| 225 | 233 | | File | Description | |
| 226 | 234 | | ------ | ------ | |
| 227 | | -| [css_mcu0_dmi_jtag_to_core_sync.v](https://github.com/chipsalliance/caliptra-ss/blob/main/src/riscv_core/veer_el2/rtl/design/dmi/css_mcu0_dmi_jtag_to_core_sync.v) | Replace with a technology-specific sync cell. This synchronizer implements edge detection logic using a delayed flip flop on the output domain to produce a pulse output. Integrators must take care to ensure logical equivalence when replacing this logic with custom cells. | |
| 228 | | -| [css_mcu0_beh_lib.sv](https://github.com/chipsalliance/caliptra-ss/blob/main/src/riscv_core/veer_el2/rtl/design/lib/css_mcu0_beh_lib.sv) | Replace css_mcu0_rvclkhdr/css_mcu0_rvoclkhdr with a technology-specific clock gater. Modifying this file may not be necessary if integrators override the clock gate module that is used by setting TECH_SPECIFIC_EC_RV_ICG. | |
| 229 | | -| [css_mcu0_beh_lib.sv](https://github.com/chipsalliance/caliptra-ss/blob/main/src/riscv_core/veer_el2/rtl/design/lib/css_mcu0_beh_lib.sv) | Replace css_mcu0_rvsyncss (and css_mcu0_rvsyncss_fpga if the design will be implemented on an FPGA) with a technology-specific sync cell. | |
| 235 | +| [css_mcu0_dmi_jtag_to_core_sync.v](../src/riscv_core/veer_el2/rtl/design/dmi/css_mcu0_dmi_jtag_to_core_sync.v) | Replace with a technology-specific sync cell. This synchronizer implements edge detection logic using a delayed flip flop on the output domain to produce a pulse output. Integrators must take care to ensure logical equivalence when replacing this logic with custom cells. | |
| 236 | +| [css_mcu0_beh_lib.sv](../src/riscv_core/veer_el2/rtl/design/lib/css_mcu0_beh_lib.sv) | Replace css_mcu0_rvclkhdr/css_mcu0_rvoclkhdr with a technology-specific clock gater. Modifying this file may not be necessary if integrators override the clock gate module that is used by setting TECH_SPECIFIC_EC_RV_ICG. | |
| 237 | +| [css_mcu0_beh_lib.sv](../src/riscv_core/veer_el2/rtl/design/lib/css_mcu0_beh_lib.sv) | Replace css_mcu0_rvsyncss (and css_mcu0_rvsyncss_fpga if the design will be implemented on an FPGA) with a technology-specific sync cell. | |
| 230 | 238 | | [src/integration/rtl/caliptra_ss_includes.svh](../src/integration/rtl/caliptra_ss_includes.svh) | Modify the parameter `CPTRA_SS_ROM_SIZE_KB` to define the correct size of the MCU ROM in integrated design. No other parameters in this file are permitted to be modified. | |
| 231 | 239 | |
| 232 | 240 | |
| 233 | 241 | |
| 242 | +[MCU Core Configuration Customization](#mcu-core-configuration-customization) |
| 234 | 243 | [Caliptra Core RTL modifications](https://github.com/chipsalliance/caliptra-rtl/blob/main/docs/CaliptraIntegrationSpecification.md#integrator-rtl-modification-requirements) |
| 235 | 244 | |
| 236 | 245 | It is mandatory that any build processes used (e.g. simulation, lint, synthesis) define the Verilog macro `CALIPTRA_MODE_SUBSYSTEM`, as described in the [Caliptra Core Integration Specification](https://github.com/chipsalliance/caliptra-rtl/blob/main/docs/CaliptraIntegrationSpecification.md). This ensures that Caliptra provides all Subsystem-related features and configuration. Example build scripts provided in the Caliptra Subsystem repository (such as [Makefile](../tools/scripts/Makefile)) demonstrate how this might be performed. |
| @@ -260,16 +269,16 @@ |
| 260 | 269 | **SoC Specific** in below table means the size of the memory is not fixed and can be configured based on the design requirements by integrator. The actual size will depend on the specific implementation and configuration of the Caliptra Subsystem. |
| 261 | 270 | |
| 262 | 271 | | **Device** | **Memory Name** | **Interface** | **Size** | **Access Type** | **Description** | |
| 263 | | -| --------------------- | ----------------------- | -------------------------------------- | ---------- | ----------------- | --------------------------------------------------------------------------------- | |
| 272 | +| ------------------- | ----------------------- | -------------------------------------- | ----------------------------- | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | |
| 264 | 273 | | **MCU0** | Instruction ROM | `mcu_rom_mem_export_if` | SoC Specific | Read-Only | Stores the instructions for MCU0 execution. Write-enable (we) and write-data (wdata) signals must be left unconnected, as MCU ROM has no write support. | |
| 265 | | -| **MCU0** | Memory Export | `cptra_ss_mcu0_el2_mem_export` | SoC Specific | Read/Write | Memory export for MCU0 access | |
| 266 | | -| **MCU0** | Shared Memory (SRAM) | `cptra_ss_mci_mcu_sram_req_if` | SoC Specific | Read/Write | Shared memory between MCI and MCU for data storage | |
| 267 | | -| **MAILBOX** | MBOX0 Memory | `cptra_ss_mci_mbox0_sram_req_if` | SoC Specific | Read/Write | Memory for MBOX0 communication | |
| 268 | | -| **MAILBOX** | MBOX1 Memory | `cptra_ss_mci_mbox1_sram_req_if` | SoC Specific | Read/Write | Memory for MBOX1 communication | |
| 269 | | -| **Caliptra Core** | ICCM, DCCM | `cptra_ss_cptra_core_el2_mem_export` | Refer to Caliptra Core spec | Read/Write | Interface for the Instruction and Data Closely Coupled Memory (ICCM, DCCM) of the core | |
| 270 | | -| **Caliptra Core** | Caliptra ROM | `cptra_ss_cptra_core_imem` | Refer to Caliptra Core spec | Read-Only | Interface for Caliptra ROM | |
| 271 | | -| **Caliptra Core** | Caliptra Mailbox SRAM | `cptra_ss_cptra_core_mbox_sram` | Refer to Caliptra Core spec | Read/Write | Interface for Caliptra mailbox memory | |
| 272 | | -| **Caliptra Core** | Caliptra MLDSA SRAM | `mldsa_memory_export_req` | Refer to Caliptra Core spec | Read/Write | Interface for SRAM instantiated within Adams Bridge block | |
| 274 | +| **MCU0** | Memory Export | `cptra_ss_mcu0_el2_mem_export` | SoC Specific | Read/Write | Memory export for MCU0 access. | |
| 275 | +| **MCU0** | Shared Memory (SRAM) | `cptra_ss_mci_mcu_sram_req_if` | SoC Specific | Read/Write | Shared memory between MCI and MCU for data storage. | |
| 276 | +| **MAILBOX** | MBOX0 Memory | `cptra_ss_mci_mbox0_sram_req_if` | SoC Specific | Read/Write | Memory for MBOX0 communication. | |
| 277 | +| **MAILBOX** | MBOX1 Memory | `cptra_ss_mci_mbox1_sram_req_if` | SoC Specific | Read/Write | Memory for MBOX1 communication. | |
| 278 | +| **Caliptra Core** | ICCM, DCCM | `cptra_ss_cptra_core_el2_mem_export` | Refer to [Caliptra Core Integration Specification](https://github.com/chipsalliance/caliptra-rtl/blob/main/docs/CaliptraIntegrationSpecification.md) | Read/Write | Interface for the Instruction and Data Closely Coupled Memory (ICCM, DCCM) of the core. | |
| 279 | +| **Caliptra Core** | Caliptra ROM | `cptra_ss_cptra_core_imem` | Refer to [Caliptra Core Integration Specification](https://github.com/chipsalliance/caliptra-rtl/blob/main/docs/CaliptraIntegrationSpecification.md) | Read-Only | Interface for Caliptra ROM. | |
| 280 | +| **Caliptra Core** | Caliptra Mailbox SRAM | `cptra_ss_cptra_core_mbox_sram` | Refer to [Caliptra Core Integration Specification](https://github.com/chipsalliance/caliptra-rtl/blob/main/docs/CaliptraIntegrationSpecification.md) | Read/Write | Interface for Caliptra mailbox memory. | |
| 281 | +| **Caliptra Core** | Adams Bridge SRAM | `abr_memory_export_req` | Refer to [Adams Bridge Documentation](https://github.com/chipsalliance/adams-bridge/tree/main/docs) | Read/Write | Interface for SRAM instantiated within Adams Bridge block. | |
| 273 | 282 | |
| 274 | 283 | |
| 275 | 284 | # Caliptra Subsystem Top |
| @@ -280,10 +289,21 @@ |
| 280 | 289 | |
| 281 | 290 | File at this path in the repository includes parameters and defines for Caliptra Subsystem [src/integration/rtl/caliptra_ss_includes.svh](../src/integration/rtl/caliptra_ss_includes.svh) |
| 282 | 291 | |
| 292 | +The following USB parameters are set on [caliptra_ss_top](../src/integration/rtl/caliptra_ss_top.sv). DEV0 is the MCU-facing USB device controller; DEV1 is the SoC-facing USB device controller. |
| 293 | + |
| 294 | +| Parameter | Default | Description | |
| 295 | +| :---------- | :-------- | :------------ | |
| 296 | +| `USB_G_SIM_CHIRP_TIMERS` | `0` | Simulation timing option to reduce runtime of USB high-speed startup. Leave at `0` for synthesis or GLS. | |
| 297 | +| `USB_C_DEV0_RAM_ADDRWIDTH` | `13` | Address width of DEV0 packet SRAM. Provide `2**USB_C_DEV0_RAM_ADDRWIDTH` 64-bit words; the default is 8192 words (64 KiB). | |
| 298 | +| `USB_C_DEV1_RAM_ADDRWIDTH` | `13` | Address width of DEV1 packet SRAM. Provide `2**USB_C_DEV1_RAM_ADDRWIDTH` 64-bit words; the default is 8192 words (64 KiB). | |
| 299 | +| `USB_C_DEV0_NBPHYSEP` | `28` | Number of physical endpoints for the MCU-facing DEV0 controller (excluding EP0); forwarded to the USB IP's `C_DEV0_NBPHYSEP` parameter. Must be a multiple of 2 required by USB IP. Max value: 28 | |
| 300 | +| `USB_C_DEV1_NBPHYSEP` | `28` | Number of physical endpoints for the SoC-facing DEV1 controller (excluding EP0); forwarded to the USB IP's `C_DEV1_NBPHYSEP` parameter. Must be a multiple of 2 required by USB IP. Max value: 28 | |
| 301 | +| `USB_C_HUB_FIFO_SIZE` | `172` | Number of 32-bit words in the internal hub descriptor storage. Keep the default unless changing the USB IP configuration. | |
| 302 | + |
| 283 | 303 | |
| 284 | 304 | ## Interfaces & Signals |
| 285 | 305 | |
| 286 | | -**IMPORTANT NOTE**: All signals assumed to by synchronous to `cptra_ss_clk_i`. |
| 306 | +**IMPORTANT NOTE**: Unless stated otherwise, signals are assumed to be synchronous to `cptra_ss_clk_i`. |
| 287 | 307 | |
| 288 | 308 | **Table: Caliptra SS Straps** |
| 289 | 309 | |
| @@ -298,6 +318,7 @@ |
| 298 | 318 | | External | input | 64 | `cptra_ss_strap_caliptra_base_addr_i` | Caliptra base address strap input | |
| 299 | 319 | | External | input | 64 | `cptra_ss_strap_mci_base_addr_i` | MCI base address strap input | |
| 300 | 320 | | External | input | 64 | `cptra_ss_strap_recovery_ifc_base_addr_i` | Recovery interface base address strap input | |
| 321 | +| External | input | 64 | `cptra_ss_strap_external_staging_area_base_addr_i` | External staging area base address input | |
| 301 | 322 | | External | input | 64 | `cptra_ss_strap_otp_fc_base_addr_i` | OTP FC base address strap input | |
| 302 | 323 | | External | input | 64 | `cptra_ss_strap_uds_seed_base_addr_i` | UDS seed base address strap input | |
| 303 | 324 | | External | input | 32 | `cptra_ss_strap_prod_debug_unlock_auth_pk_hash_reg_bank_offset_i` | Prod debug unlock auth PK hash reg bank offset input | |
| @@ -307,7 +328,27 @@ |
| 307 | 328 | | External | input | 32 | `cptra_ss_strap_generic_2_i` | Generic strap input 2 | |
| 308 | 329 | | External | input | 32 | `cptra_ss_strap_generic_3_i` | Generic strap input 3 | |
| 309 | 330 | | External | input | 1 | `cptra_ss_debug_intent_i` | Physical presence bit required to initiate the debug unlock flow. For more details, refer to the [Production Debug Unlock Flow](CaliptraSSHardwareSpecification.md#production-debug-unlock-architecture) and [How does Caliptra Subsystem enable manufacturing debug mode?](CaliptraSSHardwareSpecification.md#how-does-caliptra-subsystem-enable-manufacturing-debug-mode). For SOCs that choose to use these features, this port should be connected to a GPIO | |
| 310 | | - |
| 331 | +| External | input | 16 | `cptra_ss_strap_key_release_key_size_i` | OCP L.O.C.K. MEK byte size. Expected to be 0x40. | |
| 332 | +| External | input | 64 | `cptra_ss_strap_key_release_base_addr_i` | OCP L.O.C.K. MEK release base address. | |
| 333 | +| External | input | 1 | `cptra_ss_strap_ocp_lock_en_i` | OCP L.O.C.K. enable. Allows OCP L.O.C.K. in progress to be set enabling hardware features specific to OCP L.O.C.K. such as AES Keyvault write path, Keyvault filtering rules, and Key Release via AXI DMA. Must be driven with a constant value 0 or 1. | |
| 334 | +| External | input | 64 | `cptra_ss_strap_external_staging_area_base_addr_i` | Base AXI address for the external staging area used by Caliptra Core FW to stage FW images due to reduced MBOX SRAM size. See [Caliptra External Staging Area](https://github.com/chipsalliance/caliptra-rtl/blob/main/docs/CaliptraIntegrationSpecification.md#external-staging-area) for more details. | |
| 335 | + |
| 336 | + |
| 337 | +### Strap Timing Requirements |
| 338 | + |
| 339 | +**All strap inputs listed in the table above, as well as `cptra_ss_cptra_obf_key_i`, `cptra_ss_cptra_csr_hmac_key_i`, `cptra_ss_lc_sec_volatile_raw_unlock_en_i`, `cptra_ss_lc_Allow_RMA_or_SCRAP_on_PPD_i`, and `cptra_ss_FIPS_ZEROIZATION_PPD_i`, must be driven to their intended values and held stable before `cptra_ss_rst_b_i` is deasserted. These signals must not transition for the duration of the boot session (until the next reset assertion).** |
| 340 | + |
| 341 | +Internally, strap values are consumed at different points during the boot sequence, all of which occur strictly *after* `cptra_ss_rst_b_i` deasserts. The internal sampling cascade is: |
| 342 | + |
| 343 | +| Order | Internal Event | Straps Consumed | |
| 344 | +| :------ | :--------------- | :---------------- | |
| 345 | +| 1 | MCI boot sequencer starts (on `cptra_ss_rst_b_i` deassertion) | `cptra_ss_lc_sec_volatile_raw_unlock_en_i`, `cptra_ss_lc_Allow_RMA_or_SCRAP_on_PPD_i` (used combinationally in LC controller FSM during init) | |
| 346 | +| 2 | MCI boot sequencer deasserts internal SS reset (`cptra_ss_rst_b_o`) during `BOOT_OTP_FC` state | MCI register straps latched on a 1-cycle write-enable pulse: `cptra_ss_strap_mcu_reset_vector_i`, `cptra_ss_strap_mcu_lsu_axi_user_i` (registered copy), `cptra_ss_strap_mcu_ifu_axi_user_i` (registered copy), `cptra_ss_strap_mcu_sram_config_axi_user_i`, `cptra_ss_strap_mci_soc_config_axi_user_i`, `cptra_ss_debug_intent_i`, `cptra_ss_FIPS_ZEROIZATION_PPD_i` | |
| 347 | +| 3 | MCI boot sequencer deasserts Caliptra core reset (`cptra_ss_mci_cptra_rst_b_o`) during `BOOT_CPTRA` state | `cptra_ss_cptra_obf_key_i` (latched into internal register), `cptra_ss_cptra_csr_hmac_key_i` (latched on `cptra_noncore_rst_b` deassertion, only in `DEVICE_MANUFACTURING` lifecycle) | |
| 348 | +| 4 | Caliptra internal boot FSM deasserts `cptra_noncore_rst_b` during `BOOT_FUSE` state | Caliptra soc_ifc register straps latched on a 1-cycle write-enable pulse (locked after `fuse_done`): `cptra_ss_strap_caliptra_base_addr_i`, `cptra_ss_strap_mci_base_addr_i`, `cptra_ss_strap_recovery_ifc_base_addr_i`, `cptra_ss_strap_otp_fc_base_addr_i`, `cptra_ss_strap_uds_seed_base_addr_i`, `cptra_ss_strap_caliptra_dma_axi_user_i`, `cptra_ss_strap_generic_0_i` through `cptra_ss_strap_generic_3_i`, `cptra_ss_strap_prod_debug_unlock_auth_pk_hash_reg_bank_offset_i`, `cptra_ss_strap_num_of_prod_debug_unlock_auth_pk_hashes_i`, `cptra_ss_strap_key_release_key_size_i`, `cptra_ss_strap_key_release_base_addr_i`, `cptra_ss_strap_ocp_lock_en_i`, `cptra_ss_strap_external_staging_area_base_addr_i` | |
| 349 | + |
| 350 | + |
| 351 | +> **Security note — unregistered AXI identity straps**: `cptra_ss_strap_mcu_lsu_axi_user_i` and `cptra_ss_strap_mcu_ifu_axi_user_i` are wired **directly** (combinationally) to the MCU AXI bus `aruser`/`awuser` fields in addition to being captured into MCI registers. The combinational path means these signals are security-critical at all times — not just at the sampling edge. Toggling them during operation would corrupt in-flight AXI transactions and could bypass fuse controller access control checks that rely on AXI user identity. SoC integrators must ensure these are driven from a constant source (e.g., tied to fixed logic values or hard-strapped). |
| 311 | 352 | |
| 312 | 353 | ### AXI Interface (axi_if) |
| 313 | 354 | |
| @@ -320,6 +361,10 @@ |
| 320 | 361 | | `aruser` | UW | output | input | |
| 321 | 362 | | `arid` | IW | output | input | |
| 322 | 363 | | `arlock` | 1 | output | input | |
| 364 | +| `arcache` | 4 | output | input | |
| 365 | +| `arprot` | 3 | output | input | |
| 366 | +| `arqos` | 4 | output | input | |
| 367 | +| `arregion` | 4 | output | input | |
| 323 | 368 | | `arvalid` | 1 | output | input | |
| 324 | 369 | | `arready` | 1 | input | output | |
| 325 | 370 | | `rdata` | DW | input | output | |
| @@ -335,6 +380,10 @@ |
| 335 | 380 | | `awuser` | UW | output | input | |
| 336 | 381 | | `awid` | IW | output | input | |
| 337 | 382 | | `awlock` | 1 | output | input | |
| 383 | +| `awcache` | 4 | output | input | |
| 384 | +| `awprot` | 3 | output | input | |
| 385 | +| `awqos` | 4 | output | input | |
| 386 | +| `awregion` | 4 | output | input | |
| 338 | 387 | | `awvalid` | 1 | output | input | |
| 339 | 388 | | `awready` | 1 | input | output | |
| 340 | 389 | | `wdata` | DW | output | input | |
| @@ -375,37 +424,21 @@ |
| 375 | 424 | | External | axi_if | na | `cptra_ss_mcu_rom_s_axi_if_w_sub` | Caliptra Subsystem MCU ROM AXI write sub-interface. Writes to MCU ROM are not supported, this interface shall be left unconnected from AXI interconnect and tied to 0-value inputs. | |
| 376 | 425 | | External | axi_if | na | `cptra_ss_mcu_rom_s_axi_if_r_sub` | Caliptra Subsystem MCU ROM AXI read sub-interface | |
| 377 | 426 | | External | axi_if | na | `cptra_ss_mcu_lsu_m_axi_if_w_mgr` | Caliptra Subsystem MCU LSU AXI write manager interface | |
| 378 | | -| External | Output | 4 | `cptra_ss_mcu_lsu_m_axi_if_awcache` | Caliptra Subsystem MCU LSU AXI write manager address transaction attributes signal | |
| 379 | | -| External | Output | 3 | `cptra_ss_mcu_lsu_m_axi_if_awprot` | Caliptra Subsystem MCU LSU AXI write manager address protection type signal | |
| 380 | | -| External | Output | 4 | `cptra_ss_mcu_lsu_m_axi_if_awregion` | Caliptra Subsystem MCU LSU AXI write manager address region identifier signal | |
| 381 | | -| External | Output | 4 | `cptra_ss_mcu_lsu_m_axi_if_awqos` | Caliptra Subsystem MCU LSU AXI write manager address quality of service signal | |
| 382 | 427 | | External | axi_if | na | `cptra_ss_mcu_lsu_m_axi_if_r_mgr` | Caliptra Subsystem MCU LSU AXI read manager interface | |
| 383 | | -| External | Output | 4 | `cptra_ss_mcu_lsu_m_axi_if_arcache` | Caliptra Subsystem MCU LSU AXI read manager address transaction attributes signal | |
| 384 | | -| External | Output | 3 | `cptra_ss_mcu_lsu_m_axi_if_arprot` | Caliptra Subsystem MCU LSU AXI read manager address protection type signal | |
| 385 | | -| External | Output | 4 | `cptra_ss_mcu_lsu_m_axi_if_arregion` | Caliptra Subsystem MCU LSU AXI read manager address region identifier signal | |
| 386 | | -| External | Output | 4 | `cptra_ss_mcu_lsu_m_axi_if_arqos` | Caliptra Subsystem MCU LSU AXI read manager address quality of service signal | |
| 387 | 428 | | External | axi_if | na | `cptra_ss_mcu_ifu_m_axi_if_w_mgr` | Caliptra Subsystem MCU IFU AXI write manager interface | |
| 388 | | -| External | Output | 4 | `cptra_ss_mcu_ifu_m_axi_if_awcache` | Caliptra Subsystem MCU IFU AXI write manager address transaction attributes signal | |
| 389 | | -| External | Output | 3 | `cptra_ss_mcu_ifu_m_axi_if_awprot` | Caliptra Subsystem MCU IFU AXI write manager address protection type signal | |
| 390 | | -| External | Output | 4 | `cptra_ss_mcu_ifu_m_axi_if_awregion` | Caliptra Subsystem MCU IFU AXI write manager address region identifier signal | |
| 391 | | -| External | Output | 4 | `cptra_ss_mcu_ifu_m_axi_if_awqos` | Caliptra Subsystem MCU IFU AXI write manager address quality of service signal | |
| 392 | 429 | | External | axi_if | na | `cptra_ss_mcu_ifu_m_axi_if_r_mgr` | Caliptra Subsystem MCU IFU AXI read manager interface | |
| 393 | | -| External | Output | 4 | `cptra_ss_mcu_ifu_m_axi_if_arcache` | Caliptra Subsystem MCU IFU AXI read manager address transaction attributes signal | |
| 394 | | -| External | Output | 3 | `cptra_ss_mcu_ifu_m_axi_if_arprot` | Caliptra Subsystem MCU IFU AXI read manager address protection type signal | |
| 395 | | -| External | Output | 4 | `cptra_ss_mcu_ifu_m_axi_if_arregion` | Caliptra Subsystem MCU IFU AXI read manager address region identifier signal | |
| 396 | | -| External | Output | 4 | `cptra_ss_mcu_ifu_m_axi_if_arqos` | Caliptra Subsystem MCU IFU AXI read manager address quality of service signal | |
| 397 | 430 | | External | axi_if | na | `cptra_ss_mcu_sb_m_axi_if_w_mgr` | Caliptra Subsystem MCU System Bus AXI write manager interface | |
| 398 | | -| External | Output | 4 | `cptra_ss_mcu_sb_m_axi_if_awcache` | Caliptra Subsystem MCU System Bus AXI write manager address transaction attributes signal | |
| 399 | | -| External | Output | 3 | `cptra_ss_mcu_sb_m_axi_if_awprot` | Caliptra Subsystem MCU System Bus AXI write manager address protection type signal | |
| 400 | | -| External | Output | 4 | `cptra_ss_mcu_sb_m_axi_if_awregion` | Caliptra Subsystem MCU System Bus AXI write manager address region identifier signal | |
| 401 | | -| External | Output | 4 | `cptra_ss_mcu_sb_m_axi_if_awqos` | Caliptra Subsystem MCU System Bus AXI write manager address quality of service signal | |
| 402 | 431 | | External | axi_if | na | `cptra_ss_mcu_sb_m_axi_if_r_mgr` | Caliptra Subsystem MCU System Bus AXI read manager interface | |
| 403 | | -| External | Output | 4 | `cptra_ss_mcu_sb_m_axi_if_arcache` | Caliptra Subsystem MCU System Bus AXI read manager address transaction attributes signal | |
| 404 | | -| External | Output | 3 | `cptra_ss_mcu_sb_m_axi_if_arprot` | Caliptra Subsystem MCU System Bus AXI read manager address protection type signal | |
| 405 | | -| External | Output | 4 | `cptra_ss_mcu_sb_m_axi_if_arregion` | Caliptra Subsystem MCU System Bus AXI read manager address region identifier signal | |
| 406 | | -| External | Output | 4 | `cptra_ss_mcu_sb_m_axi_if_arqos` | Caliptra Subsystem MCU System Bus AXI read manager address quality of service signal | |
| 407 | 432 | | External | axi_if | na | `cptra_ss_i3c_s_axi_if_w_sub` | Caliptra Subsystem I3C AXI write sub-interface | |
| 408 | 433 | | External | axi_if | na | `cptra_ss_i3c_s_axi_if_r_sub` | Caliptra Subsystem I3C AXI read sub-interface | |
| 434 | +| External | axi_if | na | `cptra_ss_usb_combo_s_axi_if_w_sub` | Write access to DEV0 registers and hub control/descriptor storage. | |
| 435 | +| External | axi_if | na | `cptra_ss_usb_combo_s_axi_if_r_sub` | Read access to DEV0 registers and hub control/descriptor storage. | |
| 436 | +| External | axi_if | na | `cptra_ss_usb_dev0_mem_s_axi_if_w_sub` | Write access to DEV0 packet SRAM. | |
| 437 | +| External | axi_if | na | `cptra_ss_usb_dev0_mem_s_axi_if_r_sub` | Read access to DEV0 packet SRAM. | |
| 438 | +| External | axi_if | na | `cptra_ss_usb_dev1_csr_s_axi_if_w_sub` | Write access to DEV1 control and status registers. | |
| 439 | +| External | axi_if | na | `cptra_ss_usb_dev1_csr_s_axi_if_r_sub` | Read access to DEV1 control and status registers. | |
| 440 | +| External | axi_if | na | `cptra_ss_usb_dev1_mem_s_axi_if_w_sub` | Write access to DEV1 packet SRAM. | |
| 441 | +| External | axi_if | na | `cptra_ss_usb_dev1_mem_s_axi_if_r_sub` | Read access to DEV1 packet SRAM. | |
| 409 | 442 | | External | input | na | `cptra_ss_lc_axi_wr_req_i` | LC controller AXI write request input | |
| 410 | 443 | | External | output | na | `cptra_ss_lc_axi_wr_rsp_o` | LC controller AXI write response output | |
| 411 | 444 | | External | input | na | `cptra_ss_lc_axi_rd_req_i` | LC controller AXI read request input | |
| @@ -441,25 +474,79 @@ |
| 441 | 474 | | External | output | `CALIPTRA_IMEM_ADDR_WIDTH` | `cptra_ss_cptra_core_imem_addr_o` | Instruction memory address output | |
| 442 | 475 | | External | input | `CALIPTRA_IMEM_DATA_WIDTH` | `cptra_ss_cptra_core_imem_rdata_i` | Instruction memory read data input | |
| 443 | 476 | | External | input | 1 | `cptra_ss_cptra_core_bootfsm_bp_i` | Boot FSM breakpoint input | |
| 444 | | -| External | output | 1 | `cptra_ss_cptra_core_etrng_req_o` | External TRNG request output | |
| 445 | | -| External | input | 4 | `cptra_ss_cptra_core_itrng_data_i` | Internal TRNG data input | |
| 446 | | -| External | input | 1 | `cptra_ss_cptra_core_itrng_valid_i` | Internal TRNG valid input | |
| 477 | +| External | output | 1 | `cptra_ss_cptra_core_etrng0_req_o` | External TRNG request output for physical noise source 0 (primary) | |
| 478 | +| External | output | 1 | `cptra_ss_cptra_core_etrng1_req_o` | External TRNG request output for physical noise source 1 (secondary). Asserted only while `cptra_ss_cptra_core_itrng1_en_i` is set | |
| 479 | +| External | input | 4 | `cptra_ss_cptra_core_itrng0_data_i` | Internal TRNG data input, physical noise source 0 | |
| 480 | +| External | input | 1 | `cptra_ss_cptra_core_itrng0_valid_i` | Internal TRNG valid input, physical noise source 0 | |
| 481 | +| External | input | 4 | `cptra_ss_cptra_core_itrng1_data_i` | Internal TRNG data input, physical noise source 1. May be tied to 0 when `cptra_ss_cptra_core_itrng1_en_i` is 0 | |
| 482 | +| External | input | 1 | `cptra_ss_cptra_core_itrng1_valid_i` | Internal TRNG valid input, physical noise source 1. May be tied to 0 when `cptra_ss_cptra_core_itrng1_en_i` is 0 | |
| 483 | +| External | input | 1 | `cptra_ss_cptra_core_itrng1_en_i` | Enables the secondary noise source (dual-iTRNG). 1: the Caliptra core `entropy_combiner` seeds CSRNG with `SHA3-384(ES0||ES1)`. 0: single-source bypass, source 1 unused. Tie to 0 to retain single-iTRNG behavior | |
| 447 | 484 | | External | interface | na | `cptra_ss_mci_mcu_sram_req_if` | MCI MCU SRAM request interface | |
| 448 | 485 | | External | interface | na | `cptra_ss_mci_mbox0_sram_req_if` | MCI mailbox 0 SRAM request interface | |
| 449 | | -| External | interface | na | `cptra_ss_mci_mbox1_sram_req_if` | MCI mailbox 1 SRAM request interface | |
| 486 | + |
| 487 | +| External | interface | na | `cptra_ss_mci_mbox1_sram_req_if` | MCI mailbox 1 SRAM request interface |har |
| 450 | 488 | | External | output | 1 | `cptra_ss_soc_mcu_mbox0_data_avail` | MCU Mailbox0 data available output | |
| 451 | 489 | | External | output | 1 | `cptra_ss_soc_mcu_mbox1_data_avail` | MCU Mailbox1 data available output | |
| 452 | 490 | | External | interface | na | `cptra_ss_mcu0_el2_mem_export` | MCU0 EL2 memory export interface | |
| 491 | +| External | input | 64 | `cptra_ss_usb_dev0_mem_q_i` | Data read from DEV0 SRAM. | |
| 492 | +| External | output | 64 | `cptra_ss_usb_dev0_mem_d_o` | Data to write to DEV0 SRAM. | |
| 493 | +| External | output | 1 | `cptra_ss_usb_dev0_mem_cs_o` | DEV0 SRAM chip select. | |
| 494 | +| External | output | `USB_C_DEV0_RAM_ADDRWIDTH` | `cptra_ss_usb_dev0_mem_a_o` | DEV0 SRAM word address. | |
| 495 | +| External | output | 1 | `cptra_ss_usb_dev0_mem_web_out_o` | DEV0 SRAM write enable, active low. | |
| 496 | +| External | output | 64 | `cptra_ss_usb_dev0_mem_bsel_o` | DEV0 SRAM per-bit write mask, not a byte mask. | |
| 497 | +| External | input | 64 | `cptra_ss_usb_dev1_mem_q_i` | Data read from DEV1 SRAM. | |
| 498 | +| External | output | 64 | `cptra_ss_usb_dev1_mem_d_o` | Data to write to DEV1 SRAM. | |
| 499 | +| External | output | 1 | `cptra_ss_usb_dev1_mem_cs_o` | DEV1 SRAM chip select. | |
| 500 | +| External | output | `USB_C_DEV1_RAM_ADDRWIDTH` | `cptra_ss_usb_dev1_mem_a_o` | DEV1 SRAM word address. | |
| 501 | +| External | output | 1 | `cptra_ss_usb_dev1_mem_web_out_o` | DEV1 SRAM write enable, active low. | |
| 502 | +| External | output | 64 | `cptra_ss_usb_dev1_mem_bsel_o` | DEV1 SRAM per-bit write mask, not a byte mask. | |
| 503 | +| External | output | 1 | `cptra_ss_usb_dev1_irq_o` | DEV1 interrupt request. Connect to the SoC interrupt controller. | |
| 504 | +| External | output | 1 | `cptra_ss_usb_dev1_fiq_o` | DEV1 fast interrupt request. Connect to the SoC interrupt controller. | |
| 505 | +| External | input | 1 | `cptra_ss_usb_utmi_clk_i` | Clock from the PHY for the UTMI interface, separate from `cptra_ss_clk_i`. | |
| 506 | +| External | input | 1 | `cptra_ss_usb_utmi_clk_lock_i` | PHY clock-status input indicating that the UTMI clock is stable; not a UTMI-clocked data signal. **Clock:** `cptra_ss_usb_utmi_clk_i`. | |
| 507 | +| External | input | 8 | `cptra_ss_usb_utmi_rxdata_i` | Received data from the PHY. **Clock:** `cptra_ss_usb_utmi_clk_i`. | |
| 508 | +| External | input | 1 | `cptra_ss_usb_utmi_rxvalid_i` | The PHY is presenting valid received data. **Clock:** `cptra_ss_usb_utmi_clk_i`. | |
| 509 | +| External | input | 1 | `cptra_ss_usb_utmi_rxactive_i` | The PHY is receiving a packet. **Clock:** `cptra_ss_usb_utmi_clk_i`. | |
| 510 | +| External | input | 1 | `cptra_ss_usb_utmi_rxerror_i` | The PHY detected a receive error. **Clock:** `cptra_ss_usb_utmi_clk_i`. | |
| 511 | +| External | output | 8 | `cptra_ss_usb_utmi_txdata_o` | Data for the PHY to transmit. **Clock:** `cptra_ss_usb_utmi_clk_i`. | |
| 512 | +| External | output | 1 | `cptra_ss_usb_utmi_txvalid_o` | The controller is presenting valid transmit data. **Clock:** `cptra_ss_usb_utmi_clk_i`. | |
| 513 | +| External | input | 1 | `cptra_ss_usb_utmi_txready_i` | The PHY can accept transmit data. **Clock:** `cptra_ss_usb_utmi_clk_i`. | |
| 514 | +| External | output | 1 | `cptra_ss_usb_utmi_reset_o` | Reset control for the PHY, generated on the subsystem clock rather than the UTMI clock. **Clock:** `cptra_ss_clk_i`. | |
| 515 | +| External | output | 1 | `cptra_ss_usb_utmi_suspendm_o` | Suspend/wakeup control for the PHY; can change while the PHY clock is stopped. **Clock:** `cptra_ss_usb_utmi_clk_i`. | |
| 516 | +| External | output | 1 | `cptra_ss_usb_utmi_xcvrselect_o` | Selects the PHY transceiver speed. **Clock:** `cptra_ss_usb_utmi_clk_i`. | |
| 517 | +| External | output | 1 | `cptra_ss_usb_utmi_termselect_o` | Selects the PHY bus termination. **Clock:** `cptra_ss_usb_utmi_clk_i`. | |
| 518 | +| External | output | 2 | `cptra_ss_usb_utmi_opmode_o` | Selects the PHY operating mode. **Clock:** `cptra_ss_usb_utmi_clk_i`. | |
| 519 | +| External | input | 2 | `cptra_ss_usb_utmi_linestate_i` | USB data-line state reported by the PHY, sampled during active operation; also used for wake detection while the UTMI clock is stopped. **Clock:** `cptra_ss_usb_utmi_clk_i`. | |
| 520 | +| External | output | 4 | `cptra_ss_usb_utmi_vcontrol_o` | PHY-specific control value. Connect to the PHY vendor-control input. **Clock:** `cptra_ss_usb_utmi_clk_i`. | |
| 521 | +| External | output | 1 | `cptra_ss_usb_utmi_vcontrolloadm_o` | Tells the PHY when to load the vendor-control value. **Clock:** `cptra_ss_usb_utmi_clk_i`. | |
| 522 | +| External | input | 8 | `cptra_ss_usb_utmi_vstatus_i` | PHY-specific status from the PHY vendor-status output. **Clock:** `cptra_ss_usb_utmi_clk_i`. | |
| 523 | +| External | input | 1 | `cptra_ss_usb_ulpi_clk_i` | Clock from the PHY for the ULPI interface. | |
| 524 | +| External | input | 8 | `cptra_ss_usb_ulpi_rxdata_i` | Data sampled from the ULPI data pins during active operation; also carries asynchronous line-state/wakeup indications in low-power mode. **Clock:** `cptra_ss_usb_ulpi_clk_i`. | |
| 525 | +| External | output | 8 | `cptra_ss_usb_ulpi_txdata_o` | Data to drive onto the ULPI data pins. **Clock:** `cptra_ss_usb_ulpi_clk_i`. | |
| 526 | +| External | output | 1 | `cptra_ss_usb_ulpi_txenable_o` | Output enable for the ULPI data-pin drivers. **Clock:** `cptra_ss_usb_ulpi_clk_i`. | |
| 527 | +| External | input | 1 | `cptra_ss_usb_ulpi_dir_i` | PHY direction signal indicating who drives the shared data bus during active operation; also used in low-power wake detection. **Clock:** `cptra_ss_usb_ulpi_clk_i`. | |
| 528 | +| External | output | 1 | `cptra_ss_usb_ulpi_stp_o` | Stop signal from the controller to the PHY during active operation; also used to request wakeup while the ULPI clock is stopped. **Clock:** `cptra_ss_usb_ulpi_clk_i`. | |
| 529 | +| External | input | 1 | `cptra_ss_usb_ulpi_nxt_i` | PHY handshake signal for transferring the next data byte. **Clock:** `cptra_ss_usb_ulpi_clk_i`. | |
| 530 | +| External | input | 1 | `cptra_ss_usb_ulpi_ddr_sel_i` | Static selection of double-data-rate operation. Set to match the PHY mode. **Clock:** `cptra_ss_usb_ulpi_clk_i`. | |
| 531 | +| External | input | 1 | `cptra_ss_usb_USB_VBus_i` | Indicates that USB VBus power is present. Connect to the VBus detector. | |
| 532 | +| External | output | 1 | `cptra_ss_usb_vbuscomp_on_o` | Enables the external VBus comparator. | |
| 533 | +| External | output | 1 | `cptra_ss_usb_chrgvbus_o` | Requests charging VBus through external PHY/power circuitry. | |
| 534 | +| External | output | 1 | `cptra_ss_usb_dischrgvbus_o` | Requests discharging VBus through external PHY/power circuitry. | |
| 535 | +| External | input | 1 | `cptra_ss_usb_sessend_i` | Indicates that VBus has fallen below the session-end threshold. | |
| 453 | 536 | | External | input | 64 | `cptra_ss_mci_generic_input_wires_i` | Generic input wires for MCI | |
| 454 | 537 | | External | input | 1 | `cptra_ss_mcu_no_rom_config_i` | No ROM configuration input | |
| 455 | 538 | | External | input | 1 | `cptra_ss_mci_boot_seq_brkpoint_i` | MCI boot sequence breakpoint input | |
| 456 | 539 | | External | input | 1 | `cptra_ss_lc_Allow_RMA_or_SCRAP_on_PPD_i` | Allow RMA or SCRAP on PPD input | |
| 457 | 540 | | External | input | 1 | `cptra_ss_FIPS_ZEROIZATION_PPD_i` | Zeroization request with PPD input. If FIPS zeroization flow is required, it shall be set before Caliptra SS is out of reset. | |
| 541 | +| External | input | 1 | `cptra_ss_lc_sec_volatile_raw_unlock_en_i` | Enables Volatile TEST_UNLOCKED0 state transition infra (see [Volatile-Unlock](./CaliptraSSHardwareSpecification.md#exception-non-volatile-debugging-infrastructure-and-initial-raw-state-operations)) | |
| 458 | 542 | | External | output | 1 | `cptra_ss_dbg_manuf_enable_o` | Indication that the debug is unlocked for manufacturing state and this is set by Caliptra Core | |
| 459 | 543 | | External | output | 64 | `cptra_ss_cptra_core_soc_prod_dbg_unlock_level_o` | Indication that the debug is unlocked for production state. Each bit represents a debug level. Currently, 8-bit is supported with Caliptra ROM | |
| 460 | 544 | | External | output | na | `caliptra_ss_life_cycle_steady_state_o` | Life-cycle state broadcasted by fuse macro for any additional SOC specific use cases | |
| 461 | 545 | | External | output | 1 | `caliptra_ss_otp_state_valid_o` | One-bit valid indicator for the broadcast life-cycle state (`caliptra_ss_life_cycle_steady_state_o`). | |
| 462 | 546 | | External | output | 1 | `caliptra_ss_volatile_raw_unlock_success_o` | Asserted when the life-cycle controller grants the volatile-unlock state and remains asserted until the next power-cycle. This transition bypasses the fuse macro, so `caliptra_ss_life_cycle_steady_state_o` and `caliptra_ss_otp_state_valid_o` do not reflect it. | |
| 547 | +| External | output | 1 | `cptra_ss_otp_dft_en_o` | Fuse macro wrapper DFT enable. High only when the OTP life cycle state is valid, the Life Cycle Controller DFT enable is `On`, and the steady-state life cycle is not `RMA`. Gates debug of the non-secret fuse macro wrapper logic only; it provides no path to scan the secret partitions. See [FC Macro Test Interface](#fc-macro-test-interface). | |
| 548 | +| External | output | na | `cptra_ss_lc_escalate_en_o` | Life-cycle controller signal indicating that escalation is enabled at LCC and FC | |
| 549 | +| External | output | na | `cptra_ss_lc_check_byp_en_o` | Life-cycle controller signal indicating that external clock is accepted | |
| 463 | 550 | | External | output | 64 | `cptra_ss_mci_generic_output_wires_o` | Generic output wires for MCI | |
| 464 | 551 | | External | input | 1 | `cptra_ss_mcu_jtag_tck_i` | MCU JTAG clock input | |
| 465 | 552 | | External | input | 1 | `cptra_ss_mcu_jtag_tms_i` | MCU JTAG TMS input | |
| @@ -480,7 +567,8 @@ |
| 480 | 567 | | External | output | 1 | `cptra_ss_i3c_recovery_image_activated_o` | Indicates the recovery image is activated. If there is no external I3C it should be looped back to `cptra_ss_i3c_recovery_image_activated_i`. If there is an external I3C it can be combined with or replaced with SOC logic and connected to `cptra_ss_i3c_recovery_image_activated_i` | |
| 481 | 568 | | External | input | 1 | `cptra_ss_i3c_recovery_image_activated_i` | I3C indication for Caliptra Core that the recovery image is activated. If no external I3C should be connected to `cptra_ss_i3c_recovery_image_activated_o`. If there is an external I3C it can be connected to a combination of SOC logic + `cptra_ss_i3c_recovery_image_activated_o` | |
| 482 | 569 | | External | input | 64 | `cptra_ss_cptra_core_generic_input_wires_i` | Generic input wires for Caliptra core | |
| 483 | | -| External | input | 1 | `cptra_ss_cptra_core_scan_mode_i` | Caliptra core scan mode input | |
| 570 | +| External | input | 1 | `cptra_ss_cptra_core_scan_mode_i` | Caliptra core and USB scan mode input | |
| 571 | +| External | input | 1 | `cptra_ss_usb_async_disable_i` | USB asynchronous logic disable input. Drive low for functional operation. | |
| 484 | 572 | | External | output | 1 | `cptra_error_fatal` | Fatal error output | |
| 485 | 573 | | External | output | 1 | `cptra_error_non_fatal` | Non-fatal error output | |
| 486 | 574 | | External | output | 1 | `cptra_ss_mcu_halt_status_o` | MCU halt status | |
| @@ -497,13 +585,14 @@ |
| 497 | 585 | The `cptra_ss_clk_i` signal is the primary clock input for the Caliptra Subsystem. |
| 498 | 586 | |
| 499 | 587 | - **Signal Name** `cptra_ss_clk_i` |
| 500 | | - - **Required Frequency** 333* MHz to 400 MHz |
| 588 | + - **Required Frequency** 333* MHz minimum |
| 501 | 589 | - I3C core imposes requirement for minimum operating clock frequency set to 333 MHz or higher to meet 12ns tSCO timing. |
| 590 | + - 333 MHz was calculated assuming SCL PAD -> D and SDA Q -> PAD timing is 0. SOCs with large timing delays might need to run at a faster clock frequency to meet tSCO timing of 12ns. |
| 502 | 591 | - SoCs that run Caliptra lower than 333 MHz will limit the max I3C SCL frequency. See [I3C Phy Spec](https://chipsalliance.github.io/i3c-core/phy.html#clock-synchronization-5-1-7) for more details. |
| 503 | | - - This was changed from 170 MHz floor due to CDC issue found in I3C core: |
| 592 | + - Previous I3C Core releases permitted use of a 170 MHz clock as part of a faulty configuration that involved disabling input synchronizers. This configuration produces CDC violations and is no longer permitted. If integrators follow the requirement for 333MHz clock and do not disable synchronizers, CDC in the phy is clean. The following issues include discussion about the CDC violations from the invalid configuration: |
| 504 | 593 | - [I3C Repo CDC Issue](https://github.com/chipsalliance/i3c-core/issues/72) |
| 505 | 594 | - [Caliptra-SS Repo I3C CDC Issue](https://github.com/chipsalliance/caliptra-ss/issues/777) |
| 506 | | - - **Clock Source** Must be derived from the SoC’s clock generation module or a stable external oscillator. |
| 595 | + - **Clock Source** Must be derived from the SoC’s clock generation module or a stable on-die oscillator. |
| 507 | 596 | - **Integration Notes** |
| 508 | 597 | 1. Verify that the SoC or system-level clock source provides a stable clock. |
| 509 | 598 | 2. The clock signal must be properly buffered if necessary to meet the subsystem's setup and hold timing requirements. |
| @@ -532,7 +621,7 @@ |
| 532 | 621 | |
| 533 | 622 | ### Reset |
| 534 | 623 | |
| 535 | | -The `cptra_ss_rst_b_i` signal is the primary reset input for the Caliptra Subsystem. It must be asserted low to reset the subsystem and de-asserted high to release it from reset. Ensure that the reset is held low for a sufficient duration (minimum of 2 clock cycles) to allow all internal logic to initialize properly. |
| 624 | +The `cptra_ss_rst_b_i` signal is the primary reset input for the Caliptra Subsystem. It must be asserted low to reset the subsystem and de-asserted high to release it from reset. Ensure that the reset is held low for a sufficient duration (minimum of 32 clock cycles) to allow the reset assertion to propagate through all internal synchronization and pipeline stages across the subsystem hierarchy. |
| 536 | 625 | |
| 537 | 626 | - **Signal Name** `cptra_ss_rst_b_i` |
| 538 | 627 | - **Active Level** Active-low (`0` resets the subsystem, `1` releases reset) |
| @@ -542,7 +631,7 @@ |
| 542 | 631 | - If the reset source is asynchronous, a synchronizer circuit must be used before connecting to the subsystem. |
| 543 | 632 | - During SoC initialization, assert this reset signal until all subsystem clocks and required power domains are stable. |
| 544 | 633 | - It is **illegal** to only toggle `cptra_ss_rst_b_i` until both Caliptra and MCU have received at least one FW update. Failure to follow this requirement could cause them to execute out of an uninitialized SRAM. |
| 545 | | - - SOC should assert `cptra_ss_reset_b_i` after `cptra_ss_mcu_halt_status_o` is asserted to guarantee MCU is idle. This will guarantee no outstanding AXI transactions from MCU and help avoid RDC issues. |
| 634 | + - SOC should assert `cptra_ss_rst_b_i` after `cptra_ss_mcu_halt_status_o` is asserted to guarantee MCU is idle. This will guarantee no outstanding AXI transactions from MCU and help avoid RDC issues. |
| 546 | 635 | |
| 547 | 636 | The `cptra_ss_rst_b_o` is a delayed version of `cptra_ss_rst_b_i` to ensure `cptra_ss_rdc_clk_cg_o` is gated before reset is asserted. This reset is needed for the purpose of RDC between the warm reset domain and the cold reset/memory domain. |
| 548 | 637 | |
| @@ -576,15 +665,21 @@ |
| 576 | 665 | |
| 577 | 666 | | Manager AXI If Name | Description | |
| 578 | 667 | | ------------------------------- | ------------------------------------------------------------------- | |
| 579 | | -| `cptra_ss_mcu_lsu_m_axi_if` | Manager interface for MCU Load/Store Unit (LSU). All additional AXI signals present in the top-level port list that are not part of the axi_if interface must also be connected to the AXI interconnect (AxCACHE, AxPROT, AxREGION, AxQOS). | |
| 580 | | -| `cptra_ss_mcu_ifu_m_axi_if` | Manager interface for MCU Instruction Fetch Unit (IFU). All additional AXI signals present in the top-level port list that are not part of the axi_if interface must also be connected to the AXI interconnect (AxCACHE, AxPROT, AxREGION, AxQOS). | |
| 581 | | -| `cptra_ss_mcu_sb_m_axi_if` | Manager interface for MCU System Bus (SB). Used for debug only. All additional AXI signals present in the top-level port list that are not part of the axi_if interface must also be connected to the AXI interconnect (AxCACHE, AxPROT, AxREGION, AxQOS). | |
| 582 | | -| `cptra_ss_cptra_core_m_axi_if` | Manager interface for the Caliptra Core AXI transactions. Additional signals are unused and may be tied to 0 at the interconnect (AxCACHE, AxPROT, AxREGION, AxQOS). | |
| 583 | | - |
| 668 | +| `cptra_ss_mcu_lsu_m_axi_if` | Manager interface for MCU Load/Store Unit (LSU). | |
| 669 | +| `cptra_ss_mcu_ifu_m_axi_if` | Manager interface for MCU Instruction Fetch Unit (IFU). | |
| 670 | +| `cptra_ss_mcu_sb_m_axi_if` | Manager interface for MCU System Bus (SB). Used for debug only. | |
| 671 | +| `cptra_ss_cptra_core_m_axi_if` | Manager interface for the Caliptra Core AXI transactions. | |
| 672 | + |
| 673 | + |
| 674 | +- The following signals are unused for all AXI subordinate interfaces within Caliptra Subsystem. The AXI specification defines these signals as optional for a compliant AXI subordinate. They may be used by integrators to fine tune AXI interconnect behavior or performance. MCU AXI manager interfaces drive these signals, as documented in the VeeR EL2 specification. |
| 675 | + - AxCACHE |
| 676 | + - AxPROT |
| 677 | + - AxREGION |
| 678 | + - AxQOS |
| 584 | 679 | |
| 585 | 680 | - AXI USER width is 32-bits for all AXI interfaces in the Caliptra Subsystem. Only the Address User signals are used (ARUSER and AWUSER) for secure access filtering. Other USER signals are either tied to 0 or not used (WUSER, RUSER, BUSER). ARUSER and AWUSER must be passed unmodified through the AXI interconnect to all AXI subordinates in the Subsystem. Each logic block inside the Subsystem is responsible for performing its own AXI User filtering based on access privileges. AXI interconnect is only responsible for passing the unmodified signals along with the transaction requests, not for performing any access filtering. |
| 586 | 681 | |
| 587 | | -- AXI ID width at each MCU manager interface must not be modified from the configured values. ID width for each of the MCU AXI Manager interfaces is defined by the <IF_NAME>_BUS_TAG parameter from this file: [css_mcu0_el2_param.vh](https://github.com/chipsalliance/caliptra-ss/blob/main/src/riscv_core/veer_el2/rtl/defines/css_mcu0_el2_param.vh). Port connections may be seen in [mcu_top.sv](https://github.com/chipsalliance/caliptra-ss/blob/main/src/mcu/rtl/mcu_top.sv). ID Width of the Caliptra DMA AXI Manager interface is defined in [soc_ifc_pkg.sv](../third_party/caliptra-rtl/src/soc_ifc/rtl/soc_ifc_pkg.sv). |
| 682 | +- AXI ID width at each MCU manager interface must not be modified from the configured values. ID width for each of the MCU AXI Manager interfaces is defined by the <IF_NAME>_BUS_TAG parameter from this file: [css_mcu0_el2_param.vh](../src/riscv_core/veer_el2/rtl/defines/css_mcu0_el2_param.vh). Port connections may be seen in [mcu_top.sv](../src/mcu/rtl/mcu_top.sv). ID Width of the Caliptra DMA AXI Manager interface is defined in [soc_ifc_pkg.sv](https://github.com/chipsalliance/caliptra-rtl/blob/main/src/soc_ifc/rtl/soc_ifc_pkg.sv). |
| 588 | 683 | * IFU_BUS_TAG: 3. Interconnect should support ID values 0-7. |
| 589 | 684 | * LSU_BUS_TAG: 3. Interconnect should support ID values 0-7. |
| 590 | 685 | * SB_BUS_TAG: 1. Interconnect should support ID values 0,1. |
| @@ -612,6 +707,8 @@ |
| 612 | 707 | | 64'h6000_0000 | 64'h6FFF_FFFF | MCU PIC | MCU Programmable Interrupt Controller. No external subordinates may be assigned address space in the same 256MiB region as the PIC. For more details, refer to the VeeR EL2 Programmer's Reference Manual. | |
| 613 | 708 | |
| 614 | 709 | |
| 710 | + - Integrators are permitted to define a new configuration for the MCU (as described in [MCU Core Configuration Customization](#MCU-Core-Configuration-Customization)), which may include reassigning these restricted regions to new addresses. In this case, the new address regions must adhere to this same requirement on avoiding conflicts. |
| 711 | + |
| 615 | 712 | - Subordinate Address Map (reference only) / List of sub connected to Interconnect |
| 616 | 713 | |
| 617 | 714 | - The following address map is a **suggested address** map for subordinates for the subsystem design. It details the memory layout and the connections between different components within the Caliptra subsystem. |
| @@ -648,9 +745,9 @@ |
| 648 | 745 | |
| 649 | 746 | ### Caliptra Core Reset Control |
| 650 | 747 | |
| 651 | | -Typically Caliptra reset is directly controlled by MCI. This means `cptra_ss_mci_cptra_rst_b_o` is directly looped back to `cptra_ss_mci_cptra_rst_b_i`. |
| 652 | | - |
| 653 | | -If an SOC wants to keep Caliptra in reset they can tie off `cptra_ss_mci_cptra_rst_b_i` and not user `cptra_ss_mci_cptra_rst_b_o`. |
| 748 | +Typically Caliptra reset is directly controlled by MCI. This means `cptra_ss_mci_cptra_rst_b_o` is directly looped back to `cptra_ss_mci_cptra_rst_b_i`. |
| 749 | + |
| 750 | +If an SOC wants to keep Caliptra in reset they can tie off `cptra_ss_mci_cptra_rst_b_i` and not use `cptra_ss_mci_cptra_rst_b_o`. |
| 654 | 751 | |
| 655 | 752 | If an SOC wants to modify Caliptra reset they can do so by adding additional logic to the above signals. |
| 656 | 753 | |
| @@ -673,7 +770,8 @@ |
| 673 | 770 | ### Overview |
| 674 | 771 | |
| 675 | 772 | SRAMs are instantiated at the SoC level. Caliptra Subsystem provides the interface to export SRAMs from internal components. Components that export SRAMs include: |
| 676 | | - - Caliptra Core (see Caliptra Core integration specification) |
| 773 | + - Caliptra Core (see [Caliptra Core Integration Specification](https://github.com/chipsalliance/caliptra-rtl/blob/main/docs/CaliptraIntegrationSpecification.md)) |
| 774 | + - Adams Bridge (see [Adams Bridge Documentation](https://github.com/chipsalliance/adams-bridge/tree/main/docs)) |
| 677 | 775 | - MCU (RISC-V core) |
| 678 | 776 | - MCI (Mailbox SRAM and MCU SRAM) |
| 679 | 777 | |
| @@ -748,7 +846,7 @@ |
| 748 | 846 | #### Caliptra Subsystem error handling flow |
| 749 | 847 | |
| 750 | 848 | 1. Any implementation of error and recovery flows must adhere to the error handling requirements specified in [Caliptra.md](https://github.com/chipsalliance/Caliptra/blob/main/doc/Caliptra.md#error-reporting-and-handling) |
| 751 | | -2. See [MCI error handling](https://github.com/chipsalliance/caliptra-ss/blob/main/docs/CaliptraSSHardwareSpecification.md#mci-error-handling) for more details on MCI error infrastructure and error handling in Caliptra Subsystem. |
| 849 | +2. See [MCI error handling](./CaliptraSSHardwareSpecification.md#mci-error-handling) for more details on MCI error infrastructure and error handling in Caliptra Subsystem. |
| 752 | 850 | 3. SoC level reporting and handling of fatal & non-fatal errors is product-specific architecture, outside the scope of Caliptra Subsystem definition. For example, a CPU and a PCIe device may handle fatal and non-fatal errors differently. |
| 753 | 851 | |
| 754 | 852 | |
| @@ -848,7 +946,7 @@ |
| 848 | 946 | |
| 849 | 947 | ## MCU SRAM MRAC Considerations |
| 850 | 948 | |
| 851 | | -The MCU's [Memory Region Access Control (MRAC)](https://chipsalliance.github.io/Cores-VeeR-EL2/html/main/docs_rendered/html/memory-map.html#region-access-control-register-mrac) regions are hard coded to 256MB boundaries. Each 256MB region is configured with uniform attributes - everything within a region is labeled as either "side effect" or "cacheable". This affects how MCU SRAM and MCU MBOX SRAM (both located within MCI) should be integrated into the SoC memory map, as different components within MCI may require different access attributes. |
| 949 | +The MCU's [Memory Region Access Control (MRAC)](https://chipsalliance.github.io/Cores-VeeR-EL2/html/main/docs_rendered/html/memory-map.html#region-access-control-register-mrac) regions are hard coded to 256MB boundaries. Each 256MB region is configured with uniform attributes - everything within a region is labeled as either "side effect" or "cachable". This affects how MCU SRAM and MCU MBOX SRAM (both located within MCI) should be integrated into the SoC memory map, as different components within MCI may require different access attributes. |
| 852 | 950 | |
| 853 | 951 | ### Split Memory Mapping |
| 854 | 952 | |
| @@ -862,7 +960,7 @@ |
| 862 | 960 | |
| 863 | 961 | When MCU SRAM and MCU MBOX SRAM remain within the main MCI address space (not split off), integrators should consider the following access limitations: |
| 864 | 962 | |
| 865 | | -**DWORD Access Requirement**: MCI peripherals (MCI CSRs, MCU trace buffer CSRs, etc) **require** "side effect" attribute enabled. When "side effect" is enabled **dword-aligned accesses are required**. Unaligned accesses, like accessing a `uint8_t`, are not permitted and will result in a read fault error in the MCU. |
| 963 | +**DWORD Access Requirement**: MCI peripherals (MCI CSRs, MCU trace buffer CSRs, etc) **require** "side effect" attribute enabled. When "side effect" is enabled **dword-aligned accesses are required**. Unaligned accesses, like accessing a `uint8_t`, are not permitted and will result in a read fault error in the MCU. |
| 866 | 964 | |
| 867 | 965 | If you want to avoid these DWORD alignment limitations and allow more flexible access patterns, you can choose to implement the [Split Memory Mapping](#split-memory-mapping) (Option 2) in your AXI interconnect for MCU SRAM and/or MCU MBOX SRAM. This allows the SRAMs to be placed in regions without the side effect attribute. |
| 868 | 966 | |
| @@ -870,9 +968,9 @@ |
| 870 | 968 | |
| 871 | 969 | When MCU SRAM remains within the main MCI address space (not split off), integrators should consider the following caching limitations: |
| 872 | 970 | |
| 873 | | -**iCache Enablement Requirement**: To enable MCU iCache, everything within the 256MB boundary containing MCU SRAM must be cacheable. Since not all regions of MCI are cacheable, **MCU iCache cannot be enabled** when using a contiguous MCI address map. |
| 874 | | - |
| 875 | | -If you want to enable MCU iCache functionality, you must implement the [Split Memory Mapping](#split-memory-mapping) (Option 2) in your AXI interconnect. This allows MCU SRAM to be placed in a dedicated cacheable region separate from other MCI components. |
| 971 | +**iCache Enablement Requirement**: To enable MCU iCache, everything within the 256MB boundary containing MCU SRAM must be cachable. Since not all regions of MCI are cachable, **MCU iCache cannot be enabled** when using a contiguous MCI address map. |
| 972 | + |
| 973 | +If you want to enable MCU iCache functionality, you must implement the [Split Memory Mapping](#split-memory-mapping) (Option 2) in your AXI interconnect. This allows MCU SRAM to be placed in a dedicated cachable region separate from other MCI components. |
| 876 | 974 | |
| 877 | 975 | ## MCU Programming interface |
| 878 | 976 | |
| @@ -880,7 +978,7 @@ |
| 880 | 978 | |
| 881 | 979 | This linker script defines the memory layout for the **MCU** firmware. It specifies the placement of various sections, ensuring proper memory mapping and execution flow. |
| 882 | 980 | |
| 883 | | -**Example** Linker File can be found at : [ integration/test_suite/libs/riscv_hw_if/link.ld ](https://github.com/chipsalliance/caliptra-ss/blob/main/src/integration/test_suites/libs/riscv_hw_if/link.ld) |
| 981 | +**Example** Linker File can be found at : [ integration/test_suite/libs/riscv_hw_if/link.ld ](../src/integration/test_suites/libs/riscv_hw_if/link.ld) |
| 884 | 982 | |
| 885 | 983 | By following this linker script configuration, the **validation** firmware can be correctly mapped and executed within the **Caliptra Subsystem**. Memory mapping for the validation firmware follows these principles: |
| 886 | 984 | - Instructions are stored in ROM for initial boot (.text) |
| @@ -892,7 +990,7 @@ |
| 892 | 990 | |
| 893 | 991 | | External interrupt vector | Description | |
| 894 | 992 | | -------------------------------- | ----------------------------------------------------------------------------- | |
| 895 | | -| 1 | MCI interrupts see [MCI interrupt spec](https://github.com/chipsalliance/caliptra-ss/blob/main/docs/CaliptraSSHardwareSpecification.md#mci-interrupts) and [MCI interrupt registers](https://chipsalliance.github.io/caliptra-ss/main/regs/?p=soc.mci_top.mci_reg.intr_block_rf) | |
| 993 | +| 1 | MCI interrupts see [MCI interrupt spec](./CaliptraSSHardwareSpecification.md#mci-interrupts) and [MCI interrupt registers](https://chipsalliance.github.io/caliptra-ss/main/regs/?p=soc.mci_top.mci_reg.intr_block_rf) | |
| 896 | 994 | | 2 | I3C Interrupts | |
| 897 | 995 | | 255:3 | Exposed to SOC via `cptra_ss_mcu_ext_int` | |
| 898 | 996 | |
| @@ -920,7 +1018,7 @@ |
| 920 | 1018 | | ------------ | ------------ | ------- | ------------------------------- | ----------------------------------- | -------------------------------------------------------- | |
| 921 | 1019 | | External | Input | 1 | `clk_i` | `cptra_ss_clk_i` | Fuse Controller clock input. | |
| 922 | 1020 | | External | Input | 1 | `rst_ni` | `cptra_ss_rst_b_i` | Reset signal input, active low. | |
| 923 | | -| Internal | Input | 1 | `FIPS_ZEROIZATION_CMD_i` || Fuse Zeroization signal controlled by MCI | |
| 1021 | +| Internal | Input | 1 | `FIPS_ZEROIZATION_CMD_i` || Fuse Zeroization request sampled on MCI reset deassertion. | |
| 924 | 1022 | | External | interface | 1 | `core_axi_wr_req` | `cptra_ss_otp_core_axi_wr_req_i` | AXI write request. | |
| 925 | 1023 | | External | interface | 1 | `core_axi_wr_rsp` | `cptra_ss_otp_core_axi_wr_rsp_o` | AXI write response. | |
| 926 | 1024 | | External | interface | 1 | `core_axi_rd_req` | `cptra_ss_otp_core_axi_rd_req_i` | AXI read request. | |
| @@ -945,12 +1043,12 @@ |
| 945 | 1043 | ## Fuse Macro Memory Map and Fuse Controller CSR Address Map |
| 946 | 1044 | |
| 947 | 1045 | The Caliptra Subsystem fuse controller supports a flexible and extensible memory map for storing one-time programmable (OTP) data. This structure is documented in the following files: |
| 948 | | -See [Fuse Controller Register Map](https://github.com/chipsalliance/caliptra-ss/blob/9022fc2a57bb9af2f3ebc2376b98a807812e2e0f/src/fuse_ctrl/doc/otp_ctrl_registers.md) for registers. |
| 949 | | -See [Fuse Macor Memory Map](https://github.com/chipsalliance/caliptra-ss/blob/9022fc2a57bb9af2f3ebc2376b98a807812e2e0f/src/fuse_ctrl/doc/otp_ctrl_mmap.md) for fuse partition map. |
| 1046 | + - [Fuse Controller Register Map](https://github.com/chipsalliance/caliptra-ss/blob/db18d34fea2f87fea85e2e9986ddc0d25cdc084e/src/fuse_ctrl/doc/otp_ctrl_registers.md) for registers. |
| 1047 | + - [Fuse Macro Memory Map](https://github.com/chipsalliance/caliptra-ss/blob/db18d34fea2f87fea85e2e9986ddc0d25cdc084e/src/fuse_ctrl/doc/otp_ctrl_mmap.md) for fuse partition map. |
| 950 | 1048 | |
| 951 | 1049 | The current fuse memory map consists of **three main architectural segments**: **Caliptra-Core** (prefix: `CALIPTRA_CORE`), **Caliptra-Subsystem** (prefix: `CALIPTRA_SS`), **SoC/Vendor-Specific**. |
| 952 | 1050 | |
| 953 | | -This structure enables separation of responsibilities and flexibility in SoC integration. While the **Caliptra-Core fuse items** are mandatory and must adhere to the [Caliptra Fuse Map Specification](https://github.com/chipsalliance/Caliptra/blob/main/doc/Caliptra.md#fuse-map), **Caliptra-Subsystem** fuses are required only when the subsystem is instantiated with Caliptra Subsystem. These Caliptra Subsystem fuses can also be configured based on SoC requirements. The **SoC/Vendor-specific** items can be customized based on integrator needs and product requirements. Therefore, the fields under SoC-specific categories can be resized or eliminated if unused. |
| 1051 | +This structure enables separation of responsibilities and flexibility in SoC integration. While the **Caliptra-Core fuse items** are mandatory and must adhere to the [Caliptra Fuse Map Specification](https://github.com/chipsalliance/Caliptra/blob/main/doc/Caliptra.md#fuse-map), **Caliptra-Subsystem** fuses are required only when Caliptra is instantiated with Caliptra Subsystem. These Caliptra Subsystem fuses can also be configured based on SoC requirements. The **SoC/Vendor-specific** items can be customized based on integrator needs and product requirements. Therefore, the fields under SoC-specific categories can be resized or eliminated if unused. |
| 954 | 1052 | |
| 955 | 1053 | |
| 956 | 1054 | ### **SOC_SPECIFIC_IDEVID_CERTIFICATE Usage** |
| @@ -982,16 +1080,17 @@ |
| 982 | 1080 | These fuse partitions are "Buffered" partitions, meaning they are sensed at power-on and buffered in flip-flops until the next reset. |
| 983 | 1081 | During SoC integration it is vital to exclude the buffering flops that hold sensitive secret data from the scan chain to avoid leaks. |
| 984 | 1082 | These buffering flops may be excluded from the scan chain by excluding the following hierarchies: |
| 985 | | - `**::u_otp_ctrl::u_part_buf::u_otp_ctrl_ecc_reg::gen_partitions[X]::gen_buffered::u_part_buf::u_otp_ctrl_ecc_reg::**`, for all values of `X` in 1–5, |
| 986 | | - since indices 1–5 map to the sensitive partitions mentioned above (defined in the `PartInfo` localparam in `otp_ctrl_part_pkg.sv`, autogenerated from the OTP memory map HJSON). |
| 1083 | + `**::u_otp_ctrl::u_part_buf::u_otp_ctrl_ecc_reg::gen_partitions[X]::gen_buffered::u_part_buf::u_otp_ctrl_ecc_reg::**`, for all values of `X` in 1–5 and for `X` = 7, |
| 1084 | + since indices 1–5 map to the sensitive partitions mentioned above and index 7 maps to `SECRET_LC_TRANSITION` (defined in the `PartInfo` localparam in `otp_ctrl_part_pkg.sv`, autogenerated from the OTP memory map HJSON). |
| 987 | 1085 | Additionally, these secrets are broadcasted with this input port: `otp_broadcast_o`. Therefore, this port, its propagated signals, and its driver signals must also not be scannable. |
| 988 | | - - Since Fuse Controller scrambles secret partition with PRESENT chipher, this chiper keys, autogenerated from the OTP memory map HJSON, must be excluded from the scan path. Although these values are parameters defined in `otp_ctrl_part_pkg.sv`, the registers driven by these parameters must be excluded from the scan path. |
| 989 | | - - Note, the LC token partitions are not considered secret as only the cSHAKE128 hashes of each token are stored, not the raw tokens themselves. |
| 1086 | + - Since Fuse Controller scrambles secret partition with PRESENT cipher, this cipher keys, autogenerated from the OTP memory map HJSON, must be excluded from the scan path. Although these values are parameters defined in `otp_ctrl_part_pkg.sv`, the registers driven by these parameters must be excluded from the scan path. |
| 1087 | + - Note, the LC token partitions store only the cSHAKE128 hashes of each token, not the raw tokens themselves. The RMA token is nevertheless excluded above, because the `RMA` state enables debug and DFT and its hash must therefore not be observable. See [LC Integration Requirements](#lc-integration-requirements) for details. |
| 1088 | + - The Fuse Controller additionally implements three hardening mechanisms that protect the secret partition hardware digests: the physical debug-intent strap (`cptra_ss_debug_intent_i`), which is sampled before Fuse Controller initialization; the `SECRET_DIGEST_READ_LOCK` Fuse Controller CSR; and the `SS_DEBUG_INTENT_MCU` MCI register. The latter two are set by the MCU after Fuse Controller initialization. Only the strap additionally prevents the secret partitions' digests from being loaded into the partition buffers; the other two cannot. All three, however, ensure that there is no software path to read the digest fields through either the named CSR or the DAI. For more details, see [Debug Intent Secret Zeroization](CaliptraSSHardwareSpecification.md#debug-intent-secret-zeroization). This is a defense-in-depth measure only: it does not remove the scan-path exclusion requirements above. The integrator must still exclude the secret buffering flops, the scrambler-key registers, and the `otp_broadcast_o` signals from the scan chain. |
| 990 | 1089 | |
| 991 | 1090 | --- |
| 992 | 1091 | ## Direct Access Interface |
| 993 | 1092 | |
| 994 | | -Fuse macros has to be programmed via the Direct Access Interface, which is comprised of the following CSRs: |
| 1093 | +Fuse macros has to be programmed via the Direct Access Interface, which comprises the following CSRs: |
| 995 | 1094 | |
| 996 | 1095 | CSR Name | Description |
| 997 | 1096 | -------------------------------------|------------------------------------ |
| @@ -1003,9 +1102,12 @@ |
| 1003 | 1102 | [`DIRECT_ACCESS_CMD`](../src/fuse_ctrl/doc/otp_ctrl_registers.md#direct_access_cmd) | Command register to trigger a read or a write access. |
| 1004 | 1103 | [`DIRECT_ACCESS_REGWEN`](../src/fuse_ctrl/doc/otp_ctrl_registers.md#direct_access_regwen) | Write protection register for DAI. |
| 1005 | 1104 | |
| 1105 | +When debug intent is asserted — or the `SECRET_DIGEST_READ_LOCK` CSR is set — a DAI read of a secret partition's hardware digest returns zero, and the corresponding named digest CSR returns only a provisioned indicator (all-ones if the sensed digest is provisioned/non-zero, otherwise zero) instead of the real digest. This applies to every secret partition that carries a hardware digest, including `SECRET_LC_TRANSITION_PARTITION`. See [Debug Intent Secret Zeroization](CaliptraSSHardwareSpecification.md#debug-intent-secret-zeroization). |
| 1106 | + |
| 1006 | 1107 | ## Initialization |
| 1007 | 1108 | |
| 1008 | 1109 | The OTP controller initializes automatically upon power-up and is fully operational by the time the processor boots. |
| 1110 | +When debug intent is asserted via the physical strap (i.e., before this initialization), the zeroized secret partitions are not sensed and their buffer registers remain zero, while `SECRET_LC_TRANSITION_PARTITION` is sensed normally so the Life Cycle Controller can still transition; the controller still completes initialization. Debug intent asserted later through the `SS_DEBUG_INTENT_MCU` register does not change sensing (the partitions are already sensed) but still masks the digest reads. See [Debug Intent Secret Zeroization](CaliptraSSHardwareSpecification.md#debug-intent-secret-zeroization). |
| 1009 | 1111 | The only initialization steps that SW should perform are: |
| 1010 | 1112 | |
| 1011 | 1113 | 1. Check that the OTP controller has successfully initialized by reading [`STATUS`](../src/fuse_ctrl/doc/otp_ctrl_registers.md#status). I.e., make sure that none of the ERROR bits are set, and that the DAI is idle ([`STATUS.DAI_IDLE`](../src/fuse_ctrl/doc/otp_ctrl_registers.md#status)). |
| @@ -1082,11 +1184,38 @@ |
| 1082 | 1184 | - Perform a full integrity check by triggering `FUSE_CTRL_CHECK_TRIGGER` and ensure the system is error-free before proceeding. |
| 1083 | 1185 | - Validate readiness by checking the `FUSE_CTRL_STATUS` register. |
| 1084 | 1186 | |
| 1085 | | - |
| 1187 | +## UDS & Field Entropy FIPS Zeroization Sequence |
| 1188 | +This sequence follows the "theory of operation" stated in this ['fuse-zeroization-programmer's-guide'](https://github.com/chipsalliance/caliptra-ss/blob/db18d34fea2f87fea85e2e9986ddc0d25cdc084e/src/fuse_ctrl/doc/fuse_ctrl_zeroization_programmers_guide.md) |
| 1189 | + |
| 1190 | +Follow these steps in order to correctly zeroize the fuses and verify the operation for any partition that requires FIPS zeroization to be set (determined by zeroizable flag when a partition is generated). |
| 1191 | +1. Assert Physical Presence: Set the FIPS_zeroization_PPD pin high before taking the Caliptra subsystem out of reset. This confirms physical presence and authorizes the zeroization. When this signal is asserted, it triggers preemptive zeroization of secret FUSEs. The **MCU ROM** samples `cptra_ss_FIPS_ZEROIZATION_PPD_i` by reading the corresponding register storing its value in MCI. If `cptra_ss_FIPS_ZEROIZATION_PPD_i == HIGH`, the MCU ROM writes `32'hFFFF_FFFF` to the `ss_soc_MCU_ROM_zeroization_mask_reg` register of **MCI**. If this mask register is not set by MCU, the zeroization request is aborted by the fuse controller. |
| 1192 | +2. Issue Zeroization Commands: Trigger zeroization by sending a zeroization command to Caliptra core. Caliptra core will send a sequence of DAI (Direct Access Commands) commands to the fuse controller to perform the zeroization. The recommended order is: |
| 1193 | + - Clear the Partition Zeroization Flag: First, send a DAI command to clear this 64-bit flag within the target partition. Executing this step first is critical, as it masks potential ECC or integrity errors if the process is interrupted by a power failure. |
| 1194 | + - Zeroize Data Words: Send DAI zeroization commands for all data words within the partition. |
| 1195 | + - Clear the Partition Digest: Finally, send a DAI command to clear the partition's digest. |
| 1196 | +6. Power Cycle the SOC (including Caliptra SS): Apply a cold reset to the Caliptra subsystem. FIPS_zeroization_PPD pin should now be cleared (set low). |
| 1197 | +8. Verify the Operation: From the main MCU, read the partition's digest value from the associated fuse_ctrl digest registers. |
| 1198 | + - Success: If the register returns the expected zeroized digest value, the operation is complete. |
| 1199 | + - Failure: If the digest does not match the zeroized value, repeat the entire sequence starting from Step 1. |
| 1200 | + |
| 1201 | +## FIPS Zeroization Sequence For ECC |
| 1202 | +Zeroization is implemented within the fuse controller RTL module. It is therefore the integrator’s responsibility to ensure that the ECC bits in the corresponding fuse partition are also zeroized when a zeroization command is issued to the fuse macro. To achieve this, the integrator must provide a dedicated implementation in the fuse macro wrapper to handle zeroization of the ECC bits. |
| 1203 | + |
| 1204 | +## Miscellaneous Fuse Integration Guidelines |
| 1205 | +- If there is a provisioning step where SW (non-secret) and secret partitions need to be programmed within the same reset/power cycle of a SOC, then SW partition needs to be programmed first |
| 1206 | +- Whenever a secret partition is programmed, it requires a FC reset, implying it requires a SOC reset |
| 1207 | +- ECC bits inside fuse macros MUST be zeroized per FIPS guidelines. Since these bits are implemented by SOC as a part of OTP gasket, SOC should also implement FIPS zeroization of the ECC for UDS, FE, Ratchet Seeds (OCP lock), any vendor secrets (if required by FIPS). |
| 1208 | +- FIPS zeroization of the ECC bits of a given partition must be done after the FIPS zeroization of the partition data, zeroization marker and digest. |
| 1209 | +- UDS & FE MUST ONLY be FIPS zeroized by Caliptra Core (by Subsystem default design construction doesnt allow anyone else to do this operation). |
| 1210 | + - DAI Command Error Checking: The Caliptra core is responsible for checking the result of each DAI zeroization command to ensure it completed successfully. Any errors must be handled appropriately. |
| 1211 | + - Partitions 0-5 should not be changed by SOC. Don’t add or remove any fields, re-adjust sizes of these partitions as Caliptra ROM may expect them to be of a fixed size. |
| 1212 | +- Fuse Macro Wrapper Requirements: The fuse_ctrl macro wrapper must implement a retry mechanism for the zeroization process. To prevent damage to the fuses, the wrapper must also avoid double writes to bits that have already been programmed. Please follow the specific integration guidelines provided by your fuse macro vendor. |
| 1213 | +- OCP Lock ratchet seeds can be FIPS zeroized by MCU |
| 1214 | +- If FIPS zeroization is required for Vendor Secret Partitions, then SOC shall generate the partition with zeroization flag, validate that the zeroization sequence documented above works as expected and uses MCU to do the FIPS zeroization. Any additional physical security protection of this partition is SOC's responsibility since the use cases are SOC defined. |
| 1086 | 1215 | |
| 1087 | 1216 | ## How to test : Smoke & more |
| 1088 | 1217 | The smoke test focuses on ensuring basic functionality and connectivity of the FC & LCC. |
| 1089 | | -**TODO** More details will be provided once FC is ready to test. |
| 1218 | + |
| 1090 | 1219 | |
| 1091 | 1220 | ## Generating the Fuse Partitions |
| 1092 | 1221 | |
| @@ -1108,7 +1237,7 @@ |
| 1108 | 1237 | word width exposed as part of the generalized interface is the effective word |
| 1109 | 1238 | width. |
| 1110 | 1239 | |
| 1111 | | -## Paramteres & Defines |
| 1240 | +## Parameters & Defines |
| 1112 | 1241 | |
| 1113 | 1242 | | Parameter | Default | Description | |
| 1114 | 1243 | | ----------------------- | ---------------------------- | ----------------------------------------------------- | |
| @@ -1156,7 +1285,7 @@ |
| 1156 | 1285 | ----------------------------------------------|--------|-----------------------|--------------- |
| 1157 | 1286 | `cptra_ss_fuse_macro_inputs_o.valid_i` | Input | 1 | Valid signal for the command handshake. |
| 1158 | 1287 | `cptra_ss_fuse_macro_inputs_o.size_i` | Input | [`SizeWidth`-1:0] | Number of native OTP words to transfer, minus one: `2'b00 = 1 native word` ... `2'b11 = 4 native words`. |
| 1159 | | -`cptra_ss_fuse_macro_inputs_o.cmd_i` | Input | [`CmdWidth`-1:0] | OTP command: `7'b1000101 = read`, `7'b0110111 = write`, `7'b1111001 = read raw`, `7'b1100010 = write raw`, `7'b0101100 = initialize` |
| 1288 | +`cptra_ss_fuse_macro_inputs_o.cmd_i` | Input | [`CmdWidth`-1:0] | OTP command: `7'b1111010 = read`, `7'b1001001 = write`, `7'b1010100 = read raw`, `7'b1100111 = write raw`, `7'b0100000 = initialize`, `7'b0111101 = zeroize` |
| 1160 | 1289 | `cptra_ss_fuse_macro_inputs_o.addr_i` | Input | [`$clog2(Depth)`-1:0] | OTP word address. |
| 1161 | 1290 | `cptra_ss_fuse_macro_inputs_o.wdata_i` | Input | [`IfWidth`-1:0] | Write data for write commands. |
| 1162 | 1291 | `cptra_ss_fuse_macro_outputs_i.fatal_alert_o` | Output | 1 | Fatal alert output from the FC macro. This is connected to a separate alert channel in the instantiating IP. The instantiating IP latches the alert indication and continuously outputs alert events until reset. |
| @@ -1170,6 +1299,10 @@ |
| 1170 | 1299 | wrapper to store / read the data in raw format without generating nor checking |
| 1171 | 1300 | integrity information. That means that the wrapper must return the raw, |
| 1172 | 1301 | uncorrected data and no integrity errors. |
| 1302 | + |
| 1303 | +The `zeroize` command instructs the Fuse Macro wrapper to "erase" the addressed |
| 1304 | +value. As fuses cannot be unset, the typical erase behavior is to set all fuses |
| 1305 | +of the addressed value to `1`, ideally including the ECC bits. |
| 1173 | 1306 | |
| 1174 | 1307 | The Fuse Controller Macro wrapper implements the error codes (0x0 - 0x4). |
| 1175 | 1308 | |
| @@ -1251,6 +1384,7 @@ |
| 1251 | 1384 | A 32-bit input strap that provides the address of the **CMD register**. |
| 1252 | 1385 | Since the fuse controller registers are laid out consecutively, specifying the CMD register is sufficient for the ROM to infer the locations of adjacent registers like `ADDR`, `WDATA0`, and `RDATA0`. |
| 1253 | 1386 | |
| 1387 | + |
| 1254 | 1388 | ## FC Macro Test Interface |
| 1255 | 1389 | |
| 1256 | 1390 | The Fuse Controller Macro requires a test interface to be able to access the |
| @@ -1263,6 +1397,56 @@ |
| 1263 | 1397 | specific, pre-defined test locations shall be readable and programmable. Access |
| 1264 | 1398 | to debug access interface must also be disabled once the device is in |
| 1265 | 1399 | mission mode (i.e. PROD life cycle state). |
| 1400 | + |
| 1401 | +### `cptra_ss_otp_dft_en_o` — fuse macro wrapper DFT enable |
| 1402 | + |
| 1403 | +Caliptra Subsystem exposes a dedicated single-bit output, |
| 1404 | +`cptra_ss_otp_dft_en_o`, that the integrator shall use to gate the fuse macro |
| 1405 | +wrapper's DFT / characterization interface. It is registered on |
| 1406 | +`cptra_ss_rdc_clk_cg_o` and reset by `cptra_ss_rst_b_o`, and is asserted only |
| 1407 | +when all of the following hold: |
| 1408 | + |
| 1409 | +1. The life cycle state read out of OTP is valid. Note that |
| 1410 | + `caliptra_ss_otp_state_valid_o` is combinational while the decoded state is |
| 1411 | + registered, so the state it qualifies is only settled in the *following* |
| 1412 | + cycle. The valid is therefore delayed by one cycle internally before it is |
| 1413 | + combined with the state, so the output can never open on a stale state. |
| 1414 | +2. The Life Cycle Controller DFT enable (`lc_dft_en_i`) is `On`. |
| 1415 | +3. The steady-state life cycle (`caliptra_ss_life_cycle_steady_state_o`) is not |
| 1416 | + `RMA`. |
| 1417 | + |
| 1418 | +Otherwise the signal is low and fuse macro debug shall be disabled. |
| 1419 | + |
| 1420 | +Note that this signal is derived directly from the Life Cycle Controller DFT |
| 1421 | +enable. Unlike `cptra_ss_soc_dft_en_o`, it is **not** additionally asserted by |
| 1422 | +the MCI debug-unlock mask registers, so a debug-unlock grant alone does not open |
| 1423 | +the fuse macro wrapper. |
| 1424 | + |
| 1425 | +**Why this signal exists.** Bring-up and failure analysis of the fuse macro |
| 1426 | +wrapper require visibility into the wrapper logic itself — running BIST/repair |
| 1427 | +flows and writing characterization values over the wrapper's test interface. |
| 1428 | +Reusing `cptra_ss_soc_dft_en_o` for this purpose would be too permissive, |
| 1429 | +because that signal is also asserted in `RMA`. `cptra_ss_otp_dft_en_o` therefore |
| 1430 | +carries the same DFT grant with the additional RMA qualification, giving the |
| 1431 | +integrator a single pin to gate fuse macro debug. |
| 1432 | + |
| 1433 | +**Scope and restrictions.** This signal enables debug of the **fuse macro |
| 1434 | +wrapper logic only**. It does not, and shall not be used to, provide any path |
| 1435 | +to scan or otherwise observe the contents of the secret OTP partitions. It |
| 1436 | +shall be connected only to the **non-secret** OTP wrapper DFT logic; the scan |
| 1437 | +exclusions in [FC Integration Requirements](#fc-integration-requirements) |
| 1438 | +continue to apply in full and are not relaxed by this signal. |
| 1439 | + |
| 1440 | +**Access restriction.** Debug performed through this interface shall be |
| 1441 | +reachable only over the JTAG interface or by the MCU. The integrator shall |
| 1442 | +ensure that no other SoC component can drive or observe the fuse macro test |
| 1443 | +interface gated by this signal. |
| 1444 | + |
| 1445 | +## Life Cycle OTP Programming Behavior and Integrator Responsibilities |
| 1446 | +During a life‑cycle transition, the Caliptra Life Cycle Controller performs two OTP write operations to the transition‑counter and life‑cycle‑state fields. This behavior is architecturally defined and required for secure, fault‑resistant state progression. Although only one field changes in each phase, both fields reside within the same OTP word, so the macro receives two programming operations that may include writing some bits to the same value they already hold. This programming pattern is expected and safe for OTP implementations that correctly support word‑level writes, including rewriting a bit with the same value (1 -> 1). |
| 1447 | + |
| 1448 | +Integrators must ensure that their OTP macro or wrapper supports rewriting fields without generating errors, and that the macro’s burn semantics align with Caliptra’s assumption that “burn” corresponds to writing a logical 1. If an OTP vendor interprets 0 as a burn operation or cannot tolerate 1 -> 1 writes, the integrator must adapt their wrapper—for example, by inverting the encoding or using per‑bit write‑enable—to ensure compatibility. |
| 1449 | + |
| 1266 | 1450 | |
| 1267 | 1451 | # Life Cycle Controller |
| 1268 | 1452 | |
| @@ -1283,7 +1467,6 @@ |
| 1283 | 1467 | `RndCnstLcKeymgrDivDev` | (see RTL) | Diversification value used for the DEV life cycle state. |
| 1284 | 1468 | `RndCnstLcKeymgrDivProduction` | (see RTL) | Diversification value used for the PROD/PROD_END life cycle states. |
| 1285 | 1469 | `RndCnstLcKeymgrDivRma` | (see RTL) | Diversification value used for the RMA life cycle state. |
| 1286 | | -`SecVolatileRawUnlockEn` | 1'b1 | Enables Volatile TEST_UNLOCKED0 state transition infra |
| 1287 | 1470 | |
| 1288 | 1471 | ## Interface |
| 1289 | 1472 | |
| @@ -1292,6 +1475,7 @@ |
| 1292 | 1475 | ------------|:-----------|:-------|:----------------------|:------------------------------------|:------- | |
| 1293 | 1476 | External |input | 1 | `clk_i` | `cptra_ss_clk_i` | clock | |
| 1294 | 1477 | External |input | 1 | `rst_ni` | `cptra_ss_rst_b_i` | LC controller reset input, active low| |
| 1478 | +External |input | 1 | `lc_sec_volatile_raw_unlock_en_i` | `cptra_ss_lc_sec_volatile_raw_unlock_en_i` | Enables Volatile TEST_UNLOCKED0 state transition infra| |
| 1295 | 1479 | External |input | 1 | `raw_unlock_token_hashed_i` | `cptra_ss_raw_unlock_token_hashed_i` | Hashed token for RAW unlock | |
| 1296 | 1480 | External |input | 1 | `Allow_RMA_or_SCRAP_on_PPD` | `cptra_ss_lc_Allow_RMA_or_SCRAP_on_PPD_i` | This is GPIO strap pin. This pin should be high until LC completes its state transition to RMA or SCRAP.| |
| 1297 | 1481 | External |interface | 1 | `axi_wr_req` | `cptra_ss_lc_axi_wr_req_i` | LC controller AXI write request input | |
| @@ -1303,7 +1487,7 @@ |
| 1303 | 1487 | External |input | 1 | `scan_rst_ni` | `cptra_ss_lc_ctrl_scan_rst_ni_i` | LC controller scan reset input, active low| |
| 1304 | 1488 | Internal |output | 3 | `alerts` | | Alert outputs generated by LCC if there is an error due to one of following: register bus, lc state and fuse programming | |
| 1305 | 1489 | External |input | 1 | `esc_scrap_state0` | `cptra_ss_lc_esclate_scrap_state0_i`| An escalation input that leads LC controller to enter into SCRAP mode | |
| 1306 | | -External |input | 1 | `esc_scrap_state1` | `cptra_ss_lc_esclate_scrap_state1_i`| An escalation input that eads LC controller to enter into SCRAP mode | |
| 1490 | +External |input | 1 | `esc_scrap_state1` | `cptra_ss_lc_esclate_scrap_state1_i`| An escalation input that leads LC controller to enter into SCRAP mode | |
| 1307 | 1491 | Internal |input | 1 | `pwr_lc_i` | | A power initilization input coming from MCI | |
| 1308 | 1492 | Internal |struct | 1 | `pwr_lc_o` | | Two outputs show: (i) LC controller can accept a request, (ii) LC is initialized. | |
| 1309 | 1493 | Internal |struct | 1 | `lc_otp_vendor_test_o`| | Access to fuse controller for vendor test partitions | |
| @@ -1313,8 +1497,8 @@ |
| 1313 | 1497 | Internal |struct | 1 | `otp_lc_data_i` | | Broadcasted values from the fuse controller | |
| 1314 | 1498 | Internal |output | 1 | `lc_dft_en_o` | | DFT enable to MCI | |
| 1315 | 1499 | Internal |output | 1 | `lc_hw_debug_en_o` | | CLTAP enable to MCI | |
| 1316 | | -Internal |output | 1 | `lc_escalate_en_o` | | Broadcast signal to promote esclation in SoC | |
| 1317 | | -Internal |output | 1 | `lc_check_byp_en_o` | | External clock status delivery signal to fuse controller | |
| 1500 | +Internal |output | 1 | `lc_escalate_en_o` | `cptra_ss_lc_escalate_en_o` | Broadcast signal to promote escalation in SoC | |
| 1501 | +Internal |output | 1 | `lc_check_byp_en_o` | `cptra_ss_lc_check_byp_en_o` | External clock status delivery signal to fuse controller | |
| 1318 | 1502 | External |output | 1 | `lc_clk_byp_req_o` | `cptra_ss_lc_clk_byp_req_o` | A request port to swtich from LCC clock to external clock | |
| 1319 | 1503 | External |input | 1 | `lc_clk_byp_ack_i` | `cptra_ss_lc_clk_byp_ack_i` | Acknowledgment signal to indicate external clock request is accepted | |
| 1320 | 1504 | Internal |input | 1 | `otp_device_id_i` | | Unused port | |
| @@ -1343,13 +1527,28 @@ |
| 1343 | 1527 | |
| 1344 | 1528 | To protect from clock stretching attacks Caliptra mandates using a clock source that is constructed within the SOC (eg. PLL, Calibrated Ring Oscillator, etc). For such a clock source, a SOC may require fuses to be programmed. TP programming demands a reliable and deterministic clock signal to ensure correct fuse write operations; which SOC may not have during the early phases of manufacturing flow due to above constraints. In order to overcome this issue, this `external clock` can be used typically in the manufacturing phase of a SOC; and for such SOCs this external clock is supplied from a platform (e.g an ATE). Since the Caliptra subsystem includes only one clock input (`cptra_ss_clk_i`), the SoC integrator is responsible for ensuring that this input can be switched to a stable source. |
| 1345 | 1529 | |
| 1346 | | - - The life-cycle controller exposes an `LC_STATE` register that carries the life-cycle controller state, which the SoC can read to determine the current life-cycle state. In addition, the Caliptra Subsystem top level provides the `caliptra_ss_life_cycle_steady_state_o` and `caliptra_ss_otp_state_valid_o` signals, which are broadcast from the fuse controller. Whenever `caliptra_ss_otp_state_valid_o` is asserted, `caliptra_ss_life_cycle_steady_state_o` reflects the latest life-cycle state stored in the fuse macro. Because the fuse controller is initialized earlier than the life-cycle controller, these broadcast state signals are derived from the fuse controller. Note that `caliptra_ss_otp_state_valid_o` is driven low by the fuse controller if a fatal error occurs in the fuse controller or if an escalation signal is asserted by the life-cycle controller. In contrast, `LC_STATE` provides the life-cycle controller’s own view of the state, independent of the fuse controller’s errors such as entering SCRAP state. |
| 1347 | | - |
| 1530 | + The Life-cycle Controller requires a token to execute conditional state transitions. All tokens reside within a single partition, which the integrator can lock only once. Therefore, if any required tokens are not programmed before the partition is locked, they will remain at their default value of 0 and cannot be updated afterward. |
| 1531 | + |
| 1532 | + - The life-cycle controller exposes an `LC_STATE` register that carries the life-cycle controller state, which the SoC can read to determine the current life-cycle state. In addition, the Caliptra Subsystem top level provides the `caliptra_ss_life_cycle_steady_state_o` and `caliptra_ss_otp_state_valid_o` signals, which are broadcast from the fuse controller. Whenever `caliptra_ss_otp_state_valid_o` is asserted, `caliptra_ss_life_cycle_steady_state_o` reflects the latest life-cycle state stored in the fuse macro in the following cycle. Because the fuse controller is initialized earlier than the life-cycle controller, these broadcast state signals are derived from the fuse controller. Note that `caliptra_ss_otp_state_valid_o` is driven low by the fuse controller if a fatal error occurs in the fuse controller or if an escalation signal is asserted by the life-cycle controller. In contrast, `LC_STATE` provides the life-cycle controller’s own view of the state, independent of the fuse controller’s errors such as entering SCRAP state. |
| 1533 | + |
| 1348 | 1534 | Volatile-unlock state transitions are not reflected by the fuse controller, and therefore `caliptra_ss_life_cycle_steady_state_o` and `caliptra_ss_otp_state_valid_o` do not capture state transitions granted exclusively by the life-cycle controller. To cover this case, the Caliptra Subsystem also broadcasts `caliptra_ss_volatile_raw_unlock_success_o`, which is asserted by the life-cycle controller to indicate that the volatile-unlock state has been granted. |
| 1349 | 1535 | |
| 1350 | 1536 | 3. **Scan Path Exclusions**: |
| 1351 | | - - Ensure that the RAW\_UNLOCK token is excluded from the scan chain. This token is different from other LC transition tokens as it is stored in the plaintext in gates, not in hashed form. |
| 1352 | | - To exclude it from scan, the following hierarchies must be excluded: `*::lc_ctrl_fsm::hashed_tokens_{higher, lower}[RawUnlockTokenIdx]` and `*::lc_ctrl_fsm::hashed_token_mux`. |
| 1537 | + - **RAW\_UNLOCK token**: does **not** need to be excluded from the scan chain. |
| 1538 | + - It is not provisioned through the fuse macro; it is driven in through the `cptra_ss_raw_unlock_token_hashed_i` top-level input and is therefore held in gates. |
| 1539 | + - This token is accepted only in the `RAW` state, to switch from `RAW` to `TEST_UNLOCKED0`. Since the life-cycle controller is forward-only and no state can transition back to `RAW`, the token becomes unusable once the device leaves `RAW`. Caliptra Subsystem secrets are provisioned only in `MANUF` (`DEV`) or later states, because the fuse controller does not allow secret provisioning while debug/DFT is enabled, which is the case in the `TEST_UNLOCKED_x` states reachable with this token. |
| 1540 | + - This applies to Caliptra Subsystem assets and threat model only. An SoC concerned about reverse engineering of its own IP through DFT/debug access on blank parts may still exclude the token, using the hierarchies `*::lc_ctrl_fsm::hashed_tokens_{upper, lower}[RawUnlockTokenIdx]` and `*::lc_ctrl_fsm::hashed_token_mux`. |
| 1541 | + - **Fuse-provisioned LC transition tokens**: the fuse macro stores only their cSHAKE128 digests and never the raw tokens. |
| 1542 | + - Since the first Caliptra Subsystem secret (UDS) is provisioned in `MANUF` (`DEV`), the tokens of interest are those used to transition from `MANUF` onwards. Of these, only the RMA token is a concern: the `MANUF -> PROD` and `-> PROD_END` transitions unlock states that do not enable debug, and transitions to `SCRAP` are unconditional. |
| 1543 | + - The RMA token **must** be excluded from the scan chain, because the `RMA` state enables debug and DFT. Even though only its cSHAKE128 digest is stored in the fuse macro, the digest must not be observable, due to the collision risk. The digests are held in the buffered register of the `SECRET_LC_TRANSITION` partition, which covers all LC transition tokens, so the following hierarchies must be excluded: |
| 1544 | + - `*::u_otp_ctrl::gen_partitions[SecretLcTransitionPartitionIdx].gen_buffered.u_part_buf.u_otp_ctrl_ecc_reg.data_q` |
| 1545 | + - `*::u_otp_ctrl::gen_partitions[SecretLcTransitionPartitionIdx].gen_buffered.u_part_buf.u_otp_ctrl_ecc_reg.ecc_q` |
| 1546 | + |
| 1547 | + The `SECRET_LC_TRANSITION` partition is also scrambled, so its contents pass through the shared scrambler datapath in the clear while the partition is descrambled during initialization. The scrambler working registers must therefore be excluded as well: |
| 1548 | + - `*::u_otp_ctrl::u_otp_ctrl_scrmbl::data_state_q` |
| 1549 | + - `*::u_otp_ctrl::u_otp_ctrl_scrmbl::data_shadow_q` |
| 1550 | + - `*::u_otp_ctrl::u_otp_ctrl_scrmbl::digest_state_q` |
| 1551 | + - `*::u_otp_ctrl::u_otp_ctrl_scrmbl::key_state_q` |
| 1353 | 1552 | |
| 1354 | 1553 | 4. **RAW Unlock Token**: |
| 1355 | 1554 | - The `cptra_ss_raw_unlock_token_hashed_i` top-level input defines the *hashed* value of the |
| @@ -1377,25 +1576,37 @@ |
| 1377 | 1576 | - Write the 128-bit transition token (if required) into the `LC_CTRL_TRANSITION_TOKEN_*_OFFSET` registers. |
| 1378 | 1577 | - Trigger the state transition by writing `0x1` to `LC_CTRL_TRANSITION_CMD_OFFSET`. |
| 1379 | 1578 | - Poll the `LC_CTRL_STATUS_OFFSET` register to monitor for successful state transition or detect errors such as token errors, OTP errors, or RMA strap violations. |
| 1380 | | - - Each TEST_UNLOCKED state has its own TOKEN (see See [Fuse Memory Map](https://github.com/chipsalliance/caliptra-ss/blob/9022fc2a57bb9af2f3ebc2376b98a807812e2e0f/src/fuse_ctrl/doc/otp_ctrl_mmap.md)). |
| 1381 | | - - During a state transition, an asserted reset or zeorization command can cause permanent life-cycle state corruption. |
| 1579 | + - Each TEST_UNLOCKED state has its own TOKEN (see See [Fuse Memory Map](https://github.com/chipsalliance/caliptra-ss/blob/db18d34fea2f87fea85e2e9986ddc0d25cdc084e/src/fuse_ctrl/doc/otp_ctrl_mmap.md)). |
| 1580 | + - During a state transition, an asserted reset or zeroization command can cause permanent life-cycle state corruption. |
| 1382 | 1581 | |
| 1383 | 1582 | 3. **Token Validation**: |
| 1384 | 1583 | - For conditional state transitions, provide the transition token before the transition request. |
| 1385 | | - - Toke Format is illustrated with a python implementation: |
| 1584 | + - Token format and fuse provisioning are illustrated with a python implementation: |
| 1386 | 1585 | ```python |
| 1387 | | -# value = 0x318372c87790628a05f493b472f04808 |
| 1388 | | -# data = value.to_bytes(16, byteorder='little') |
| 1389 | | -# custom = 'LC_CTRL'.encode('UTF-8') |
| 1390 | | -# shake = cSHAKE128.new(data=data, custom=custom) |
| 1391 | | -# shake output is 0x4c9ca068a68474d526e7d8a0233d5aad |
| 1586 | +from Crypto.Hash import cSHAKE128 |
| 1587 | + |
| 1588 | +# Raw (unhashed) token as a 128-bit integer |
| 1589 | +value = 0x318372c87790628a05f493b472f04808 |
| 1590 | +data = value.to_bytes(16, byteorder='little') |
| 1591 | +# data (byte-array) = [0x08, 0x48, 0xf0, 0x72, 0xb4, 0x93, 0xf4, 0x05, |
| 1592 | +# 0x8a, 0x62, 0x90, 0x77, 0xc8, 0x72, 0x83, 0x31] |
| 1593 | + |
| 1594 | +custom = 'LC_CTRL'.encode('UTF-8') |
| 1595 | +shake = cSHAKE128.new(data=data, custom=custom) |
| 1596 | +hashed_token = shake.read(16) |
| 1597 | +# hashed_token (byte-array) = [0xad, 0x5a, 0x3d, 0x23, 0xa0, 0xd8, 0xe7, 0x26, |
| 1598 | +# 0xd5, 0x74, 0x84, 0xa6, 0x68, 0xa0, 0x9c, 0x4c] |
| 1599 | +# hashed_token as big-endian hex = 0x4c9ca068a68474d526e7d8a0233d5aad |
| 1600 | +# |
| 1601 | +# HKMS must provision this hashed_token byte-array into the corresponding |
| 1602 | +# fuse location in SECRET_LC_TRANSITION_PARTITION via the DAI. |
| 1392 | 1603 | |
| 1393 | 1604 | # To unlock a state having the shake condition above, the LCC needs |
| 1394 | | -# to get the following input set: |
| 1395 | | -TOKEN_write(LC_CTRL_TRANSITION_TOKEN_3_OFFSET, 0x318372c8) |
| 1605 | +# to get the following raw token input set: |
| 1606 | +TOKEN_write(LC_CTRL_TRANSITION_TOKEN_0_OFFSET, 0x72f04808) |
| 1396 | 1607 | TOKEN_write(LC_CTRL_TRANSITION_TOKEN_1_OFFSET, 0x7790628a) |
| 1397 | 1608 | TOKEN_write(LC_CTRL_TRANSITION_TOKEN_2_OFFSET, 0x05f493b4) |
| 1398 | | -TOKEN_write(LC_CTRL_TRANSITION_TOKEN_0_OFFSET, 0x72f04808) |
| 1609 | +TOKEN_write(LC_CTRL_TRANSITION_TOKEN_3_OFFSET, 0x318372c8) |
| 1399 | 1610 | |
| 1400 | 1611 | ``` |
| 1401 | 1612 | |
| @@ -1409,11 +1620,16 @@ |
| 1409 | 1620 | - Perform a reset sequence after each state transition routine |
| 1410 | 1621 | |
| 1411 | 1622 | 2. **Boot Sequence**: |
| 1412 | | - - Enable MCI that intilaize the LC controller. |
| 1623 | + - Enable MCI that initialize the LC controller. |
| 1413 | 1624 | - Verify successful initialization by reading `LC_CTRL_STATUS_OFFSET`. |
| 1414 | 1625 | |
| 1415 | 1626 | 4. **Error Scenarios**: |
| 1416 | 1627 | - Test scenarios where invalid tokens, Fuse errors, or missing RMA straps are injected to validate error handling and system recovery mechanisms. |
| 1628 | + |
| 1629 | +5. **MCI Masking Registers for LCC Decoding Signals**: |
| 1630 | + - The MCI provides a set of masking registers that allow the SoC integrator to explicitly masks Caliptra Core–debug level, SOC_DFT_EN and SOC_HW_DEBUG_EN. Caliptra Core expresses its debug grant through the `ss_soc_dbg_unlock_level_i` vector, where each bit represents a distinct debug unlock level. These requests are not acted upon directly; instead, they are first AND-masked with SoC-programmed MCI registers to ensure that only integrator-approved debug levels can be enabled. |
| 1631 | + - For production debug unlock, the integrator must program `MCI_REG_SOC_PROD_DEBUG_STATE_0` and `MCI_REG_SOC_PROD_DEBUG_STATE_1` MCI registers. Together, these registers form a 64-bit mask that gates `ss_soc_dbg_unlock_level_i`. A debug level is considered enabled only if the corresponding bit is set both in Caliptra Core’s unlock request vector and in the SoC-programmed mask. For example, if Caliptra Core asserts the fifth debug level by setting `ss_soc_dbg_unlock_level_i[4]`, the integrator must also set bit of `MCI_REG_SOC_PROD_DEBUG_STATE[1:0][4]` for that level to take effect. |
| 1632 | + - The same masking mechanism applies to SOC_DFT_EN enable and SOC_HW_DEBUG_EN. For these, MCI offers `MCI_REG_SOC_DFT_EN_0`, `MCI_REG_SOC_DFT_EN_1` and `MCI_REG_SOC_HW_DEBUG_EN_0`, `MCI_REG_SOC_HW_DEBUG_EN_1` mask registers. These are also masked with `ss_soc_dbg_unlock_level_i`. If this masking (AND operation) results in a value that has `1` in it. The corresponding enable signal is set to high. |
| 1417 | 1633 | |
| 1418 | 1634 | ## How to Test: Smoke & More |
| 1419 | 1635 | |
| @@ -1557,7 +1773,7 @@ |
| 1557 | 1773 | | :---- | :---- | :---- | :---- | :---- | :---- | |
| 1558 | 1774 | | External | Input | 1 | `clk` || MCI Clock. Connected to subsystem top level clk input. | |
| 1559 | 1775 | | External | Output | 1 | `mcu_clk_cg` || MCU clock gated when MCU in reset for RDC. Exposed as `cptra_ss_mcu_clk_cg_o` externally. | |
| 1560 | | -| External | Output | 1 | `cptra_ss_rdc_clk_cg` || MCI SS clock gated when caliptra reset asserted for RDC. Should be used whenever their is a Warm reset -> cold reset crossing in design. Must be paired with `cptra_ss_rst_b_o` reset for proper gating. Exposed to SOC as `cptra_ss_rdc_clk_cg_o` | |
| 1776 | +| External | Output | 1 | `cptra_ss_rdc_clk_cg` || MCI SS clock gated when caliptra reset asserted for RDC. Should be used whenever there is a warm reset -> cold reset crossing in design. Must be paired with `cptra_ss_rst_b_o` reset for proper gating. Exposed to SOC as `cptra_ss_rdc_clk_cg_o` | |
| 1561 | 1777 | |
| 1562 | 1778 | |
| 1563 | 1779 | **Table: MCI Resets** |
| @@ -1589,7 +1805,7 @@ |
| 1589 | 1805 | | External | Input | `AXI_USER_WIDTH` | `strap_mcu_sram_config_axi_user` | AXI USER populating MCU FW Image in MCU SRAM. Exposed to SOC via `cptra_ss_strap_mcu_sram_config_axi_user_i` | |
| 1590 | 1806 | | External | Input | `AXI_USER_WIDTH` | `strap_mci_soc_config_axi_user` | AXI USER with MCU privilages in MCI reg. Use for Romless config. 0x0: Disable 0xFFFFFFFF: Debug (all AXI users get this privilage). Exposed to SOC via `cptra_ss_strap_mci_soc_config_axi_user_i` | |
| 1591 | 1807 | | External | Input | 32 | `strap_mcu_reset_vector` | Default reset vector for MCI. Can be overridden via MCI register write. Exposed to SOC via `cptra_ss_strap_mcu_reset_vector_i` | |
| 1592 | | -| External | Input | 32 | `ss_debug_intent` | Debug intent | |
| 1808 | +| External | Input | 32 | `ss_debug_intent` | Debug intent strap. Captured into the read-only (over DMI) `SS_DEBUG_INTENT` register and OR'd with the MCU-writable `SS_DEBUG_INTENT_MCU` register to form the effective debug intent. | |
| 1593 | 1809 | |
| 1594 | 1810 | |
| 1595 | 1811 | |
| @@ -1692,8 +1908,8 @@ |
| 1692 | 1908 | | Internal | Input | Struct | `from_otp_to_lcc_program_i` | These ports comes from fuse partitions and show LCC's non-volatile state | |
| 1693 | 1909 | | Internal | Input | 1 | `ss_dbg_manuf_enable_i` | Caliptra Core enables manuf debug with this | |
| 1694 | 1910 | | Internal | Input | 64 | `ss_soc_dbg_unlock_level_i` | Caliptra Core enables prod debug with this. Since there are multiple debug levels, the debug level is one-hot encoded to this port | |
| 1695 | | -| External | Output | 1 | `SOC_DFT_EN` | Masked LCC decoding signal, see LCC section | |
| 1696 | | -| External | Output | 1 | `SOC_HW_DEBUG_EN` | Masked LCC decoding signal, see LCC section | |
| 1911 | +| External | Output | 1 | `SOC_DFT_EN` | Masked LCC decoding signal, see LCC section. **Not guaranteed to be stable during scan mode.** Use to gate entry into scan mode only; see [DFT Reset Control](#mci-integration-requirements) for details. | |
| 1912 | +| External | Output | 1 | `SOC_HW_DEBUG_EN` | Masked LCC decoding signal, see LCC section. **Not guaranteed to be stable during scan mode.** See [DFT Reset Control](#mci-integration-requirements) for details. | |
| 1697 | 1913 | | Internal | Output | Struct | `security_state_o` | Caliptra Core's security state | |
| 1698 | 1914 | | External | Input | 1 | `FIPS_ZEROIZATION_PPD_i` | Physical pin to trigger zeroization | |
| 1699 | 1915 | | Internal | Output | 1 | `FIPS_ZEROIZATION_CMD_o` | Masked zeroization command signal | |
| @@ -1782,11 +1998,17 @@ |
| 1782 | 1998 | |
| 1783 | 1999 | MCI input resets do not have any built-in DFT reset control for scan. It is the integrator’s responsibility to add any DFT controls outside of MCI before the reset is connected to MCI. |
| 1784 | 2000 | |
| 1785 | | - Simlar to Caliptra core - When `scan_mode` is set the MCI generated resets will be directly controlled by `mci_rst_b`. This gives DFT complete control of these resets within Caliptra SS. |
| 2001 | + Similar to Caliptra core - When `scan_mode` is set the MCI generated resets will be directly controlled by `mci_rst_b`. This gives DFT complete control of these resets within Caliptra SS. |
| 2002 | + |
| 2003 | + **Important: Scan mode is a destructive operation.** Once `scan_mode` is asserted and Caliptra assets are flushed, no guarantees can be made about the state of any signals coming out of the Caliptra Subsystem, including `SOC_DFT_EN` and `SOC_HW_DEBUG_EN`. These output signals are **not** guaranteed to remain stable during scan mode because scan data shifted into scannable flops can cause internal state (such as the LCC state translator outputs) to change unpredictably. |
| 2004 | + |
| 2005 | + The integrator should use `SOC_DFT_EN` to gate entry into scan mode (e.g., to enable scan chain access), but must **not** rely on `SOC_DFT_EN` or any other Caliptra Subsystem output remaining stable once scan mode is active. The SoC's DFT architecture is responsible for ensuring that its DFT control signals are driven in a stable manner during scan. For example, if `SOC_DFT_EN` is used to gate IJTAG or other DFT access, the SoC should latch or otherwise stabilize the signal before entering scan mode. |
| 2006 | + |
| 2007 | + Additionally, the MCI reset mux logic that selects between normal and scan-mode reset paths uses standard RTL assign statements (similar logic exists in VeeR core too). Depending on the synthesis tool and target technology, these may not synthesize into glitch-free mux cells, potentially causing glitches on reset lines during `scan_mode` transitions, as reported in [GitHub issue 1037](https://github.com/chipsalliance/caliptra-ss/issues/1037). Integrators should analyze their gate-level netlist to confirm logic safety against glitches when entering scan_mode. Integrators are responsible for tooling adjustments to produce glitch-free mux behavior on these reset paths. |
| 1786 | 2008 | |
| 1787 | 2009 | - **Integrator RTL modification requirements** |
| 1788 | 2010 | |
| 1789 | | - MCI reused synchronizer modules from Caliptra Core like caliptra\_2ff\_syn.sv. Integrators are required to replace these modules with technology-specific sync cells. |
| 2011 | + MCI reuses synchronizer modules from Caliptra Core, including caliptra_2ff_sync.sv and caliptra_prim_flop_2sync.sv. Integrators are required to replace these modules with technology-specific sync cells. |
| 1790 | 2012 | |
| 1791 | 2013 | MCI does not itself contain modules that need to be directly modified by the integrator. |
| 1792 | 2014 | |
| @@ -1798,23 +2020,22 @@ |
| 1798 | 2020 | |
| 1799 | 2021 | Activity on any bit of the `mci_generic_input_wires` triggers a notification interrupt to the microcontroller indicating a bit toggle. |
| 1800 | 2022 | |
| 1801 | | - The following tables describe the allocation of functionality on `mci_generic_input_wires` and `mci_generic_output_wires`. Bits not assigned to a function can be used by the SOC for their own needs. These generic wires could be reserved by CHIPS Alliance in future Caliptra drops. Any unused inputs shall be tied off to 0 and outputs left unconnected. |
| 2023 | + The following tables describe the allocation of functionality on `mci_generic_input_wires` and `mci_generic_output_wires`. Bits not assigned to a function can be used by the SOC for their own needs. These generic wires could be reserved by CHIPS Alliance in future Caliptra drops. Any unused inputs shall be tied off to 0 and outputs left unconnected. |
| 1802 | 2024 | |
| 1803 | 2025 | **Table: MCI Generic Input Allocation** |
| 1804 | | - |
| 1805 | | -| Bits | Name | Description | |
| 1806 | | -| :---- | :---- | :---- | |
| 1807 | | -| 63:1 | RESERVED | No allocated function | |
| 1808 | | -| 0 | FIPS_ZEROIZATION_PPD_i | [FIPS zeroization](CaliptraSSHardwareSpecification.md#zeroization-flow-for-secret-fuses) request sampled by MCU ROM. If FIPS zeroization is required, this signal shall be set before Caliptra SS is out of reset. If set, MCU ROM will set MASK register triggering FIPS zeroization flow. If this signal is toggled at runtime it shall be ignored. | |
| 1809 | | - |
| 1810 | | - |
| 1811 | | - **Table: MCI Generic Output Allocation** |
| 1812 | 2026 | |
| 1813 | 2027 | | Bits | Name | Description | |
| 1814 | 2028 | | :---- | :---- | :---- | |
| 1815 | 2029 | | 63:0 | RESERVED | No allocated function | |
| 1816 | 2030 | |
| 1817 | | - |
| 2031 | + |
| 2032 | + **Table: MCI Generic Output Allocation** |
| 2033 | + |
| 2034 | +| Bits | Name | Description | |
| 2035 | +| :---- | :---- | :---- | |
| 2036 | +| 63:0 | RESERVED | No allocated function | |
| 2037 | + |
| 2038 | + |
| 1818 | 2039 | ### Error Aggregation Connectivity Requirements |
| 1819 | 2040 | |
| 1820 | 2041 | MCI aggregates all fatal and non-fatal errors for Caliptra SS via two ports `agg_error_fatal` and `agg_error_non_fatal`. These errors are: |
| @@ -1826,7 +2047,7 @@ |
| 1826 | 2047 | |
| 1827 | 2048 | MCU has the ability to independently mask these aggregated interrupts to its own interrupt and to the `all_error_fatal` and `all_error_non_fatal` output ports. |
| 1828 | 2049 | |
| 1829 | | -Aggregate error connections can be see in [Caliptra SS HW Spec: MCI Error Handling](https://github.com/chipsalliance/caliptra-ss/blob/main/docs/CaliptraSSHardwareSpecification.md#mci-error-handling). |
| 2050 | +Aggregate error connections can be see in [Caliptra SS HW Spec: MCI Error Handling](./CaliptraSSHardwareSpecification.md#mci-error-handling). |
| 1830 | 2051 | |
| 1831 | 2052 | ### Subsystem Internal Fuse Controller Initialization Connectivity Requirements |
| 1832 | 2053 | |
| @@ -1909,7 +2130,7 @@ |
| 1909 | 2130 | | ----- | :---: | ----- | ----- | |
| 1910 | 2131 | | ss\_dbg\_manuf\_enable\_i | \<- | ss\_dbg\_manuf\_enable | See [Caliptra Integration spec](https://github.com/chipsalliance/caliptra-rtl/blob/main/docs/CaliptraIntegrationSpecification.md#soc-interface-definition) | |
| 1911 | 2132 | | ss\_soc\_dbg\_unlock\_level\_i | \<- | ss\_soc\_dbg\_unlock\_level | See [Caliptra Integration spec](https://github.com/chipsalliance/caliptra-rtl/blob/main/docs/CaliptraIntegrationSpecification.md#soc-interface-definition) | |
| 1912 | | -| security\_state\_o | \-\> | security\_state | See [LCC state tranlation table](CaliptraSSHardwareSpecification.md#lcc-interpretation-for-caliptra-core-security-states) | |
| 2133 | +| security\_state\_o | \-\> | security\_state | See [LCC state translation table](CaliptraSSHardwareSpecification.md#lcc-interpretation-for-caliptra-core-security-states) | |
| 1913 | 2134 | |
| 1914 | 2135 | |
| 1915 | 2136 | **Table: LCC Gasket - MCI to Caliptra SS Port Connections** |
| @@ -1984,9 +2205,14 @@ |
| 1984 | 2205 | |
| 1985 | 2206 | The mailboxes are generic with some specific protocols and legal operations/accesses to ensure their secured and restricted aspect. The command, statuses, and data that are intepreted by the MCU microcontroller (uC), Caliptra uC or other SoC agent are not defined or enforced in this specification. |
| 1986 | 2207 | |
| 1987 | | -Since the MCU uC has root access to the mailboxes (even when the mailbox is locked), it can function as an intermediary and facilitate communication between 2 agents (such as Caliptra uC and other SoC agents). |
| 1988 | | - |
| 1989 | | -The [Caliptra SS HW MCU Mailbox Spec](https://github.com/chipsalliance/caliptra-ss/blob/main/docs/CaliptraSSHardwareSpecification.md#mcu-mailbox) has more details about the specific registers and interrupts used in the mailbox flows. |
| 2208 | +The MCU uC can function as an intermediary between agents such as Caliptra uC |
| 2209 | +and other SoC agents. MCU MBOX SRAM has one exclusive owner at a time, and MCU |
| 2210 | +accesses the SRAM only while it is that owner. See |
| 2211 | +[MCU Mailbox MCU Access](./CaliptraSSHardwareSpecification.md#mcu-mailbox-mcu-access) |
| 2212 | +for the MCU CSR access rules used by the flows below. Software can observe the |
| 2213 | +current owner through `MBOX_HW_STATUS.SRAM_OWNER`. |
| 2214 | + |
| 2215 | +The [Caliptra SS HW MCU Mailbox Spec](./CaliptraSSHardwareSpecification.md#mcu-mailbox) has more details about the specific registers and interrupts used in the mailbox flows. |
| 1990 | 2216 | |
| 1991 | 2217 | #### MCU Mailbox Limited Trusted AXI users |
| 1992 | 2218 | |
| @@ -1995,7 +2221,7 @@ |
| 1995 | 2221 | - `MBOX*_VALID_AXI_USER` |
| 1996 | 2222 | - `MBOX*_AXI_USER_LOCK` |
| 1997 | 2223 | |
| 1998 | | -See [Caliptra SS MCU Trusted AXI Users](https://github.com/chipsalliance/caliptra-ss/blob/main/docs/CaliptraSSIntegrationSpecification.md#mcu-mailbox-limited-trusted-axi-users) for more details. |
| 2224 | +See [Caliptra SS MCU Trusted AXI Users](./CaliptraSSHardwareSpecification.md#mcu-mailbox-limited-trusted-axi-users) for more details. |
| 1999 | 2225 | |
| 2000 | 2226 | #### Reset |
| 2001 | 2227 | |
| @@ -2005,81 +2231,127 @@ |
| 2005 | 2231 | |
| 2006 | 2232 | An MBOX doorbell command has no data. When MBOX_DLEN = 0 and MBOX_EXECUTION is cleared, the clearing logic erases the entire MBOX SRAM. To avoid long delays caused by this clearing, firmware should set MBOX_DLEN = 1 when issuing doorbell commands. |
| 2007 | 2233 | |
| 2008 | | -#### MCI Debug Lock Status |
| 2009 | | - |
| 2010 | | -MCI exposed the debug state of the chip to MCU via an interrupt `notif_debug_locked_sts` and a status register `SECURITY_STATE.debug_locked`. There is no defined use case for this feature at subsystem level, unlike in Caliptra where security assets are cleared when entering debug locked state. Therefore, it is recommended this interrupt remains disabled using `notif_debug_locked_en`. |
| 2011 | | - |
| 2012 | | -If there is a need to use debug state the recommened flow to avoid missing a debug locked transition is: |
| 2013 | | - |
| 2014 | | -1. Out of reset MCU W1C `notif_debug_locked_sts` |
| 2015 | | -2. MCU reads `SECURITY_STATE.debug_locked` and acts on the value seen |
| 2016 | | -3. MCU enables the interrupt using `notif_debug_locked_en` |
| 2017 | | - |
| 2018 | | -#### MCU to SOC Receiver Flow |
| 2019 | | - |
| 2020 | | -1. MCU attempts to lock mailbox by reading ```MBOX_LOCK``` register |
| 2021 | | - - If read returns 0, LOCK is granted and will be set to 1 |
| 2022 | | - - If read returns 1, MBOX is locked for another agent |
| 2023 | | -2. MCU writes data to ```MBOX_SRAM``` |
| 2024 | | -3. MCU writes data length in bytes to ```MBOX_DLEN``` |
| 2025 | | -4. MCU writes command to ```MBOX_CMD``` register |
| 2026 | | -5. MCU sets ```MBOX_TARGET_USER``` to SOC Receiver AXI and sets MBOX_TARGET_USER_VALID to 1 |
| 2027 | | -5. MCU writes 1 to ```MBOX_EXECUTE``` register (which asserts cptra_ss_soc_mcu_mbox*_data_avail output) |
| 2028 | | -6. MCU can directly inform receiver depending on receiver capabilities OR receiver could use cptra_ss_soc_mcu_mbox*_data_avail wire to directly generate an interrupt |
| 2029 | | -7. Receiver processes command and data in mailbox |
| 2030 | | -8. Receiver updates ```MBOX_SRAM``` and ```MBOX_DLEN``` (if there is data to return). |
| 2031 | | -9. Reciever updates status in ```MBOX_TARGET_STATUS.STATUS``` and sets ```MBOX_TARGET_STATUS.DONE``` |
| 2032 | | - - This generates interrupt MBOX*_TARGET_DONE to MCU |
| 2033 | | -10. MCU (in response to MBOX*_TARGET_DONE interrupt) will write 0 to ```MBOX_EXECUTE``` to release the MBOX |
| 2034 | | -11. MCI clears MBOX CSRs and zeros out data from 0 to the max DLEN set during the whole lock session in ```MBOX_SRAM``` |
| 2035 | | - - Mailbox lock cannot be re-acquired until zeroization is complete |
| 2036 | | - |
| 2037 | | -#### SOC Sender to MCU Flow |
| 2038 | | - |
| 2039 | | -1. Sender attempts to lock mailbox by reading ```MBOX_LOCK``` register |
| 2040 | | - - If read returns 0, LOCK is granted and will be set to 1 |
| 2041 | | - - If read returns 1, MBOX is locked for another agent |
| 2042 | | -2. Sender writes data to ```MBOX_SRAM``` |
| 2043 | | -3. Sender writes data length in bytes to ```MBOX_DLEN``` |
| 2044 | | -4. Sender writes command to ```MBOX_CMD``` register |
| 2045 | | -5. Sender writes 1 to ```MBOX_EXECUTE``` register |
| 2046 | | - - This generates MBOX*_CMD_AVAIL interrupt to MCU |
| 2047 | | -6. MCU processes command and data in mailbox |
| 2048 | | -7. MCU updates ```MBOX_SRAM``` and ```MBOX_DLEN``` (if there is data to return). |
| 2049 | | -8. MCU update ```MBOX_CMD_STATUS``` with desired status code |
| 2050 | | -9. Sender writes 0 to ```MBOX_EXECUTE``` to release the MBOX |
| 2051 | | -10. MCI clears MBOX CSRs and zeros out data from 0 to the max DLEN set during the whole lock session in ```MBOX_SRAM``` |
| 2052 | | - - Mailbox lock cannot be re-acquired until zeroization is complete |
| 2053 | | - |
| 2054 | | -#### SOC Sender to SOC Receiver Communication Flow (MCU as intermediary) |
| 2055 | | - |
| 2056 | | -1. Sender attempts to lock mailbox by reading ```MBOX_LOCK``` register |
| 2057 | | - - If read returns 0, LOCK is granted and will be set to 1 |
| 2058 | | - - If read returns 1, MBOX is locked for another agent |
| 2059 | | -2. Sender writes data to ```MBOX_SRAM``` |
| 2060 | | -3. Sender writes data length in bytes to MBOX_DLEN |
| 2061 | | -4. Sender writes command to ```MBOX_CMD``` register |
| 2062 | | -5. Sender writes 1 to ```MBOX_EXECUTE``` register |
| 2063 | | - - This generates MBOX*_CMD_AVAIL interrupt to MCU |
| 2064 | | -6. Sender reads/polls ```MBOX_CMD_STATUS``` for desired completion/ready status |
| 2065 | | -7. MCU (in response to MBOX*_CMD_AVAIL interrupt) processes command and data |
| 2066 | | -8. MCU sets ```MBOX_TARGET_USER``` to SOC Receiver AXI and sets MBOX_TARGET_USER_VALID to 1 |
| 2067 | | -9. MCU notifies SOC Receiver they can access MBOX (method depends on SOC Receiver capabilities) |
| 2068 | | -10. Receiver reads MBOX and processes command and/or data |
| 2069 | | -11. Receiver potentially updates data in ```MBOX_SRAM``` and ```MBOX_DLEN``` |
| 2070 | | -12. Reciever updates status in ```MBOX_TARGET_STATUS.STATUS``` and sets ```MBOX_TARGET_STATUS.DONE``` |
| 2071 | | - - This generates interrupt MBOX*_TARGET_DONE to MCU |
| 2072 | | -13. MCU (in response to MBOX*_TARGET_DONE interrupt) will update ```MBOX_CMD_STATUS``` with final status |
| 2073 | | -14. Sender sees final desired ```MBOX_CMD_STATUS``` |
| 2074 | | -15. Sender writes 0 to ```MBOX_EXECUTE``` to release the MBOX |
| 2075 | | -16. MCI clears MBOX CSRs and zeros out data from 0 to the max DLEN set during the whole lock session in ```MBOX_SRAM``` |
| 2076 | | - - Mailbox lock cannot be re-acquired until zeroization is complete |
| 2234 | +#### MCU to SOC Target Flow |
| 2235 | + |
| 2236 | +MCU uses |
| 2237 | +[`TARGET_USER`](./CaliptraSSHardwareSpecification.md#mcu-mailbox-target-user) |
| 2238 | +to identify the SOC Target. |
| 2239 | + |
| 2240 | +```mermaid |
| 2241 | +sequenceDiagram |
| 2242 | + accTitle: MCU requester to SOC receiver mailbox flow |
| 2243 | + accDescr: MCU stages a request, grants exclusive SRAM ownership to a selected SOC receiver, receives target status, and releases the mailbox for zeroization. |
| 2244 | + autonumber |
| 2245 | + participant MCU |
| 2246 | + participant MBOX as MCU MBOX |
| 2247 | + participant SOC as SOC Target |
| 2248 | + |
| 2249 | + MCU->>MBOX: Read LOCK |
| 2250 | + MBOX-->>MCU: 0, lock granted and owner=ROOT (MCU) |
| 2251 | + MCU->>MBOX: Write SRAM, DLEN, and CMD |
| 2252 | + MCU->>MBOX: Write TARGET_USER=SOC |
| 2253 | + MCU->>MBOX: Write TARGET_USER_VALID=1 |
| 2254 | + MCU->>MBOX: Write EXECUTE=1 |
| 2255 | + Note over MBOX,SOC: owner=SOC |
| 2256 | + alt Target uses the subsystem sideband wire |
| 2257 | + MBOX-)SOC: cptra_ss_soc_mcu_mbox*_data_avail asserts |
| 2258 | + else MCU notifies the Target directly |
| 2259 | + MCU->>SOC: Sideband notification, for example a mailbox command |
| 2260 | + end |
| 2261 | + SOC->>MBOX: Process or update SRAM and DLEN |
| 2262 | + SOC->>MBOX: Write terminal TARGET_STATUS |
| 2263 | + Note over MCU,MBOX: owner=ROOT (MCU). HW clears TARGET_USER and TARGET_USER_VALID |
| 2264 | + MBOX-)MCU: notif_mbox*_target_done interrupt |
| 2265 | + MCU->>MBOX: Read TARGET_STATUS |
| 2266 | + MCU->>MBOX: Write EXECUTE=0 |
| 2267 | + Note over MBOX: SRAM zeroizes through maximum DLEN, then LOCK clears |
| 2268 | +``` |
| 2269 | + |
| 2270 | +#### SOC Requester to MCU Flow |
| 2271 | + |
| 2272 | +```mermaid |
| 2273 | +sequenceDiagram |
| 2274 | + accTitle: SOC sender to MCU mailbox flow |
| 2275 | + accDescr: A SOC sender stages a command, transfers exclusive SRAM ownership to the root agent, typically MCU, polls command status, reads the response, and releases the mailbox. |
| 2276 | + autonumber |
| 2277 | + participant SOC as SOC Requester |
| 2278 | + participant MBOX as MCU MBOX |
| 2279 | + participant MCU |
| 2280 | + |
| 2281 | + SOC->>MBOX: Read LOCK |
| 2282 | + MBOX-->>SOC: 0, lock granted and owner=SOC |
| 2283 | + SOC->>MBOX: Write SRAM, DLEN, and CMD |
| 2284 | + SOC->>MBOX: Write EXECUTE=1 |
| 2285 | + Note over SOC,MBOX: owner=ROOT (MCU) |
| 2286 | + MBOX-)MCU: notif_mbox*_cmd_avail interrupt |
| 2287 | + par Requester polls while MCU processes |
| 2288 | + loop While CMD_STATUS is BUSY |
| 2289 | + SOC->>MBOX: Read CMD_STATUS |
| 2290 | + MBOX-->>SOC: BUSY |
| 2291 | + end |
| 2292 | + and MCU handles request |
| 2293 | + MCU->>MBOX: Process request and prepare response |
| 2294 | + MCU->>MBOX: Write non-BUSY CMD_STATUS |
| 2295 | + end |
| 2296 | + Note over SOC,MBOX: owner=SOC |
| 2297 | + SOC->>MBOX: Read response SRAM and DLEN |
| 2298 | + SOC->>MBOX: Write EXECUTE=0 |
| 2299 | + Note over MBOX: SRAM zeroizes through maximum DLEN, then LOCK clears |
| 2300 | +``` |
| 2301 | + |
| 2302 | +#### SOC Requester to SOC Target Communication Flow (MCU as intermediary) |
| 2303 | + |
| 2304 | +The Target may be a SOC agent or the Caliptra AXI user used for external |
| 2305 | +staging DMA. |
| 2306 | + |
| 2307 | +```mermaid |
| 2308 | +sequenceDiagram |
| 2309 | + accTitle: SOC sender routed through MCU to a target |
| 2310 | + accDescr: Exclusive SRAM ownership moves from a SOC sender to the root agent, typically MCU, to a selected target, back to the root agent, and finally to the original sender. |
| 2311 | + autonumber |
| 2312 | + participant REQ as SOC Requester |
| 2313 | + participant MBOX as MCU MBOX |
| 2314 | + participant MCU |
| 2315 | + participant TGT as SOC or Caliptra Target |
| 2316 | + |
| 2317 | + REQ->>MBOX: Read LOCK and stage SRAM, DLEN, CMD |
| 2318 | + Note over REQ,MBOX: owner=SOC Requester |
| 2319 | + REQ->>MBOX: Write EXECUTE=1 |
| 2320 | + Note over MCU,MBOX: owner=ROOT (MCU) |
| 2321 | + MBOX-)MCU: notif_mbox*_cmd_avail interrupt |
| 2322 | + MCU->>MBOX: Validate command, range, and target identity |
| 2323 | + MCU->>MBOX: Write TARGET_USER=TGT |
| 2324 | + MCU->>MBOX: Write TARGET_USER_VALID=1 |
| 2325 | + Note over MBOX,TGT: owner=Target |
| 2326 | + MCU->>TGT: Sideband notification, for example a Caliptra mailbox command |
| 2327 | + Note over MBOX,TGT: No MCU MBOX interrupt or data-avail wire asserts here |
| 2328 | + TGT->>MBOX: Process or update SRAM and DLEN |
| 2329 | + TGT->>MBOX: Write terminal TARGET_STATUS |
| 2330 | + Note over MCU,MBOX: owner=ROOT (MCU). HW clears TARGET_USER and TARGET_USER_VALID |
| 2331 | + MBOX-)MCU: notif_mbox*_target_done interrupt |
| 2332 | + MCU->>MBOX: Read TARGET_STATUS and finalize response |
| 2333 | + MCU->>MBOX: Write non-BUSY CMD_STATUS |
| 2334 | + Note over REQ,MBOX: owner=SOC Requester |
| 2335 | + REQ->>MBOX: Read CMD_STATUS and response |
| 2336 | + REQ->>MBOX: Write EXECUTE=0 |
| 2337 | + Note over MBOX: SRAM zeroizes through maximum DLEN, then LOCK clears |
| 2338 | +``` |
| 2339 | + |
| 2340 | +`TARGET_STATUS` and `CMD_STATUS` are |
| 2341 | +[separate handshakes](./CaliptraSSHardwareSpecification.md#mcu-mailbox-status-registers). |
| 2342 | +The Requester regains ownership only after MCU writes non-BUSY `CMD_STATUS`. |
| 2343 | + |
| 2344 | +Because the SOC Requester holds the lock in this flow, the |
| 2345 | +`cptra_ss_soc_mcu_mbox*_data_avail` wire stays deasserted when MCU programs |
| 2346 | +the target configuration. The Target learns that it owns the SRAM only through |
| 2347 | +the sideband notification, so MCU shall write `TARGET_USER`, set |
| 2348 | +`TARGET_USER_VALID`, and then send the notification. |
| 2077 | 2349 | |
| 2078 | 2350 | ### MCU JTAG/DMI Access |
| 2079 | 2351 | |
| 2080 | 2352 |  |
| 2081 | 2353 | |
| 2082 | | -MCI provides access JTAG security for MCU. Detailed debug architecture can be found in [MCI debug spec](https://github.com/chipsalliance/caliptra-ss/blob/main/docs/CaliptraSSHardwareSpecification.md#mci-debug). Some notes about MCI debug arcitecture: |
| 2354 | +MCI provides access JTAG security for MCU. Detailed debug architecture can be found in [MCI debug spec](./CaliptraSSHardwareSpecification.md#mci-debug). Some notes about MCI debug arcitecture: |
| 2083 | 2355 | |
| 2084 | 2356 | 1. MCI registers are accessed via the MCU DMI uncore address space. |
| 2085 | 2357 | 2. Limited MCU JTAG access is provided to MCI DMI registers by setting `cptra_ss_debug_intent_i` |
| @@ -2095,7 +2367,7 @@ |
| 2095 | 2367 | |
| 2096 | 2368 |  |
| 2097 | 2369 | |
| 2098 | | -MCI hosts the MCU trace buffer. The full trace buffer spec is [here](https://github.com/chipsalliance/caliptra-ss/blob/main/docs/CaliptraSSHardwareSpecification.md#mcu-trace-buffer). High level notes about trace buffer: |
| 2370 | +MCI hosts the MCU trace buffer. The full trace buffer spec is [here](./CaliptraSSHardwareSpecification.md#mcu-trace-buffer). High level notes about trace buffer: |
| 2099 | 2371 | |
| 2100 | 2372 | 1. It can only be accessed when debug unlocked |
| 2101 | 2373 | 2. It can be accessed via AXI or DMI |
| @@ -2132,6 +2404,16 @@ |
| 2132 | 2404 | |
| 2133 | 2405 | ## Sequences : Reset, Boot, |
| 2134 | 2406 | |
| 2407 | +### MCI Debug Lock Status |
| 2408 | + |
| 2409 | +MCI exposed the debug state of the chip to MCU via an interrupt `notif_debug_locked_sts` and a status register `SECURITY_STATE.debug_locked`. There is no defined use case for this feature at subsystem level, unlike in Caliptra where security assets are cleared when entering debug locked state. Therefore, it is recommended this interrupt remains disabled using `notif_debug_locked_en`. |
| 2410 | + |
| 2411 | +If there is a need to use debug state the recommended flow to avoid missing a debug locked transition is: |
| 2412 | + |
| 2413 | +1. Out of reset MCU W1C `notif_debug_locked_sts` |
| 2414 | +2. MCU reads `SECURITY_STATE.debug_locked` and acts on the value seen |
| 2415 | +3. MCU enables the interrupt using `notif_debug_locked_en` |
| 2416 | + |
| 2135 | 2417 | ### MCI Boot Sequencer |
| 2136 | 2418 | |
| 2137 | 2419 |  |
| @@ -2171,7 +2453,7 @@ |
| 2171 | 2453 | |
| 2172 | 2454 | 1. MCI brought out of reset |
| 2173 | 2455 | 2. MCI boot FSM progresses to `WAIT_FOR_CPTRA_BOOT_GO` |
| 2174 | | -3. Trusted SOC agent does configuration MCU ROM typically executes. See [CSS HW spec](https://github.com/chipsalliance/caliptra-ss/blob/main/docs/CaliptraSSHardwareSpecification.md#subsystem-boot-finite-state-machine-css-bootfsm) |
| 2456 | +3. Trusted SOC agent does configuration MCU ROM typically executes. See [CSS HW spec](./CaliptraSSHardwareSpecification.md#subsystem-boot-finite-state-machine-css-bootfsm) |
| 2175 | 2457 | 4. Trusted SOC agent sets `CPTRA_BOOT_GO.go` bringing Caliptra out of reset |
| 2176 | 2458 | 5. Trusted SOC agent executes [MCU FW Boot Update](#mcu-fw-boot-update) with Caliptra |
| 2177 | 2459 | - When SOC agent sees `notif_cptra_mcu_reset_req_sts` set by Caliptra, SOC will see `cptra_ss_mcu_halt_req_o` asserted by MCI Boot FSM. SOC must assert `cptra_ss_mcu_halt_status_i` and `cptra_ss_mcu_halt_ack_i` back to MCI. When SOC sees `cptra_ss_mcu_halt_req_o` deassert SOC shall give full control of these signals back to MCU. |
| @@ -2210,7 +2492,7 @@ |
| 2210 | 2492 | |
| 2211 | 2493 | |
| 2212 | 2494 | ### MCU FW Update Flows |
| 2213 | | -The hitless flow is described in full in [Caliptra Top Spec](https://github.com/chipsalliance/Caliptra/blob/main/doc/Caliptra.md#subsystem-support-for-hitless-updates). The [Caliptra SS HW Spec](https://github.com/chipsalliance/caliptra-ss/blob/main/docs/CaliptraSSHardwareSpecification.md#mcu-hitless-update-handshake) spec gives details about the registers used in theese flow. This section is meant to elaborate on how to use the given HW to meet the architectual spec. |
| 2495 | +The hitless flow is described in full in [Caliptra Top Spec](https://github.com/chipsalliance/Caliptra/blob/main/doc/Caliptra.md#subsystem-support-for-hitless-updates). The [Caliptra SS HW Spec](./CaliptraSSHardwareSpecification.md#mcu-hitless-update-handshake) spec gives details about the registers used in these flow. This section is meant to elaborate on how to use the given HW to meet the architectural spec. |
| 2214 | 2496 | |
| 2215 | 2497 | Registers relevant to these flows: |
| 2216 | 2498 | - Caliptra |
| @@ -2320,7 +2602,7 @@ |
| 2320 | 2602 | 4. W1C agg\_error\_non\_fatal0 |
| 2321 | 2603 | 4. Once MCU and SOC have finished their flows all interrupts will be cleared |
| 2322 | 2604 | |
| 2323 | | -See [MCI error handling](https://github.com/chipsalliance/caliptra-ss/blob/main/docs/CaliptraSSHardwareSpecification.md#mci-error-handling) for more details on MCI error infrastructure. |
| 2605 | +See [MCI error handling](./CaliptraSSHardwareSpecification.md#mci-error-handling) for more details on MCI error infrastructure. |
| 2324 | 2606 | |
| 2325 | 2607 | ## Other requirements |
| 2326 | 2608 | |
| @@ -2332,10 +2614,16 @@ |
| 2332 | 2614 | 1. **Main target** : Main target is responsible for any flows other than recovery or streaming boot. |
| 2333 | 2615 | 2. **Recovery target** : Recovery target is dedicated to streaming boot / recovery interface. |
| 2334 | 2616 | |
| 2335 | | -- This I3C code integrates with an AXI interconnect, allowing AXI read and write transactions to access I3C registers. For details on the core’s internal registers and functionality, see: |
| 2617 | +The I3C core integrates with an AXI interconnect, allowing AXI read and write transactions to access I3C registers. For details on the core’s internal registers and functionality, see: |
| 2336 | 2618 | - [I3C Core Documentation](https://chipsalliance.github.io/i3c-core/) |
| 2337 | 2619 | - [Caliptra Subsystem Hardware Specification Document](CaliptraSSHardwareSpecification.md) |
| 2338 | 2620 | - [I3C Core Registers](https://github.com/chipsalliance/i3c-core/tree/main/src/rdl) |
| 2621 | + |
| 2622 | +The I3C core can be configured as an [AXI Recovery interface](CaliptraSSHardwareSpecification.md#axi-streaming-boot-recovery-interface). In this mode, the I3C endpoint is disabled as all internal FIFOs are repurposed for the recovery stream. |
| 2623 | + |
| 2624 | +**IMPORTANT**: |
| 2625 | +- **Static Configuration**: The I3C core must be statically configured during the MCU boot flow as either an I3C Target or an AXI Recovery Interface. This selection is mutually exclusive and cannot be changed dynamically. |
| 2626 | +- **Dual-Functionality**: If the SoC requires both AXI Recovery and standard I3C Target functionality, a second I3C core must be instantiated outside of Caliptra SS. |
| 2339 | 2627 | |
| 2340 | 2628 | ## Integration Considerations |
| 2341 | 2629 | |
| @@ -2497,7 +2785,7 @@ |
| 2497 | 2785 | - Test transfers the recovery image |
| 2498 | 2786 | - Boots the device using the recovery image |
| 2499 | 2787 | |
| 2500 | | - - **MCTP Test seqeunce** |
| 2788 | + - **MCTP Test sequence** |
| 2501 | 2789 | - MCTP Test send random 68 bytes of data and PEC to RX queue |
| 2502 | 2790 | - MCU reads and compares the data with expected data |
| 2503 | 2791 | |
| @@ -2585,7 +2873,7 @@ |
| 2585 | 2873 | |
| 2586 | 2874 |  |
| 2587 | 2875 | |
| 2588 | | -The reset block diagram below illustrates the RTL implemenation of various resets. |
| 2876 | +The reset block diagram below illustrates the RTL implementation of various resets. |
| 2589 | 2877 | |
| 2590 | 2878 |  |
| 2591 | 2879 | |
| @@ -2607,7 +2895,7 @@ |
| 2607 | 2895 | | CPTRA_SS_PRIM_RST | Primary reset input corresponding to SOC Warm Reset | cptra_ss_rst_b_i | caliptra_top_dut.soc_ifc_top1.soc_ifc_reg_hwif_out.CPTRA_FUSE_WR_DONE.done.value -> HIGH <br> i3c.i3c.xrecovery_handler.xrecovery_executor.image_activated_o -> LOW <br> i3c.i3c.xrecovery_handler.xrecovery_executor.payload_available_q -> LOW | CPTRA_SS_PRIM_RST -> CPTRA_CORE_UC_RST <br> CPTRA_SS_PRIM_RST -> CPTRA_CORE_NON_CORE_RST <br> CPTRA_SS_PRIM_RST -> CPTRA_SS_RST <br> CPTRA_SS_PRIM_RST -> CPTRA_SS_MCU_RST | |
| 2608 | 2896 | | CPTRA_SS_RST | Caliptra SS MCI Boot Sequencer generated reset used by various other SS level logic blocks and Caliptra Core | cptra_ss_mci_cptra_rst_b_i <br> mci_top_i.i_boot_seqr.cptra_ss_rst_b_o | mci_top_i.i_boot_seqr.rdc_clk_dis -> HIGH <br> mci_top_i.i_boot_seqr.early_warm_reset_warn -> HIGH <br> mci_top_i.i_boot_seqr.boot_fsm[3:0] = BOOT_IDLE <br> i3c.i3c.xrecovery_handler.xrecovery_executor.image_activated_o -> LOW <br> i3c.i3c.xrecovery_handler.xrecovery_executor.payload_available_q -> LOW <br> caliptra_top_dut.soc_ifc_top1.soc_ifc_reg_hwif_out.CPTRA_FUSE_WR_DONE.done.value -> HIGH | CPTRA_SS_RST -> CPTRA_SS_PRIM_RST <br> CPTRA_SS_RST -> CPTRA_CORE_NON_CORE_RST <br> CPTRA_SS_RST -> CPTRA_CORE_UC_RST <br> CPTRA_SS_RST -> CPTRA_SS_MCU_RST <br> CPTRA_SS_RST -> CPTRA_DMI_NON_CORE_RST | |
| 2609 | 2897 | | CPTRA_CORE_NON_CORE_RST | Caliptra Core Boot FSM generated reset used by various other Caliptra Core logics | caliptra_top_dut.soc_ifc_top1.i_soc_ifc_boot_fsm.cptra_noncore_rst_b | caliptra_top_dut.soc_ifc_top1.i_soc_ifc_boot_fsm.rdc_clk_dis -> HIGH <br> caliptra_top_dut.soc_ifc_top1.i_soc_ifc_boot_fsm.arc_IDLE -> HIGH <br> mci_top_i.i_boot_seqr.rdc_clk_dis -> HIGH | CPTRA_CORE_NON_CORE_RST -> CPTRA_SS_RST <br> CPTRA_CORE_NON_CORE_RST -> CPTRA_SS_PRIM_RST <br> CPTRA_CORE_NON_CORE_RST -> CPTRA_CORE_UC_RST <br> CPTRA_CORE_NON_CORE_RST -> CPTRA_SS_MCU_RST | |
| 2610 | | -| CPTRA_CORE_UC_RST | Caliptra Core Boot FSM generated microcontroller reset for Caliptra Core RISCV | caliptra_top_dut.soc_ifc_top1.i_soc_ifc_boot_fsm.cptra_uc_rst_b | caliptra_top_dut.soc_ifc_top1.i_soc_ifc_boot_fsm.fw_update_rst_window -> HIGH <br> caliptra_top_dut.aes_inst.aes_inst.u_aes_core.u_aes_control.gen_fsm[0].gen_fsm_p.u_aes_control_fsm_i.u_aes_control_fsm.aes_ctrl_cs[5:0] -> 6'b001001 || |
| 2898 | +| CPTRA_CORE_UC_RST | Caliptra Core Boot FSM generated microcontroller reset for Caliptra Core RISCV | caliptra_top_dut.soc_ifc_top1.i_soc_ifc_boot_fsm.cptra_uc_rst_b | caliptra_top_dut.soc_ifc_top1.i_soc_ifc_boot_fsm.fw_update_rst_window -> HIGH <br> caliptra_top_dut.aes_inst.aes_inst.u_aes_core.u_aes_control.gen_fsm[0].gen_fsm_p.u_aes_control_fsm_i.u_aes_control_fsm.aes_ctrl_cs[5:0] -> 6'b001001 <br> caliptra_top_dut.sha3.hsel_i -> LOW <br> caliptra_top_dut.aes_inst.aes_cif_req_dv -> LOW || |
| 2611 | 2899 | | CPTRA_SS_MCU_RST | Caliptra SS MCI Boot Sequencer generated microcontroller reset for Caliptra SS RISCV | mci_top_i.i_boot_seqr.mcu_rst_b | mci_top_i.i_boot_seqr.fw_update_rst_window -> HIGH <br> mci_top_i.i_mci_mcu_trace_buffer.mcu_trace_rv_i_valid_ip -> LOW || |
| 2612 | 2900 | |
| 2613 | 2901 | |
| @@ -2619,7 +2907,7 @@ |
| 2619 | 2907 | |
| 2620 | 2908 |  |
| 2621 | 2909 | |
| 2622 | | -The red and blue line indicates that the input Caliptra SS warm reset (cptra_ss_rst_b_i) needs to be asserted for atleast 32 clock cycles for the reset assertion to propagate through various levels of hierarhcy. |
| 2910 | +The red and blue line indicates that the input Caliptra SS warm reset (cptra_ss_rst_b_i) needs to be asserted for at least 32 clock cycles for the reset assertion to propagate through various levels of hierarchy. |
| 2623 | 2911 | |
| 2624 | 2912 | ## RDC Waivers |
| 2625 | 2913 | |
| @@ -2676,11 +2964,11 @@ |
| 2676 | 2964 | #### Signal Width Mismatches |
| 2677 | 2965 | | Location | Description | Justification | |
| 2678 | 2966 | | ---------- | ------------- | --------------- | |
| 2679 | | -| [mcu_mbox_csr.sv:271](https://github.com/chipsalliance/caliptra-ss/blob/main/src/mci/rtl/mcu_mbox_csr.sv#L271) | Signal width mismatch | MSB on RHS will be optimized out during synthesis | |
| 2967 | +| [mcu_mbox_csr.sv:271](../src/mci/rtl/mcu_mbox_csr.sv#L271) | Signal width mismatch | MSB on RHS will be optimized out during synthesis | |
| 2680 | 2968 | |
| 2681 | 2969 | |
| 2682 | 2970 | #### Undriven signals |
| 2683 | | -These are undriven signals and deemed to be OK. If exposed to SOC leave unconnected when integrating. |
| 2971 | +These are undriven signals and deemed to be OK. If exposed to SoC leave unconnected when integrating. |
| 2684 | 2972 | |
| 2685 | 2973 | | Location | Signal | Justification | |
| 2686 | 2974 | | ---------- | -------- | --------------- | |
| @@ -2688,6 +2976,98 @@ |
| 2688 | 2976 | | [`el2_veer.sv`](https://github.com/chipsalliance/caliptra-rtl/blob/main/src/riscv_core/veer_el2/rtl/el2_veer.sv) | `ifu_axi_bready_ahb` | Caliptra Core internal RV processor uses AHB, not AXI interface, so AXI is unconnected | |
| 2689 | 2977 | | [`el2_veer.sv`](https://github.com/chipsalliance/caliptra-rtl/blob/main/src/riscv_core/veer_el2/rtl/el2_veer.sv) | `lsu_axi_bready_ahb` | Caliptra Core internal RV processor uses AHB, not AXI interface, so AXI is unconnected | |
| 2690 | 2978 | |
| 2979 | + |
| 2980 | + |
| 2981 | +# Trademark Compliance |
| 2982 | + |
| 2983 | +## SoC Integration Requirements |
| 2984 | + |
| 2985 | +This section defines a table of integration requirements that are mandatory for an integrator's design to receive the Caliptra Subsystem Trademark. Integrators must read and comply with the guidance defined through this specification and in the [Caliptra Subsystem Hardware Specification](./CaliptraSSHardwareSpecification.md) to successfully integrate Caliptra Subsystem in their design. The purpose of this table is to remove ambiguity around integration requirements and to provide a deterministic reference for confirming compliance. |
| 2986 | + |
| 2987 | +| Category | Originating Block | Requirement | Rationale | |
| 2988 | +| :-- | :-- | :-- | :-- | |
| 2989 | +| CSS_Clk_1 | I3C | Clock frequency of primary input clock `cptra_ss_clk_i` must be a minimum of 333 MHz. SoCs with non-zero SCL PAD→D or SDA Q→PAD timing delays may require a higher minimum frequency to meet the 12 ns tSCO constraint, described further in [I3C Core Physical Layer](https://chipsalliance.github.io/i3c-core/phy.html#common-phy-layer). | Functionality | |
| 2990 | +| CSS_Clk_2 | Caliptra Subsystem | MCU SRAM and Mailbox memories must be connected to the Caliptra Subsystem RDC output clock, `cptra_ss_rdc_clk_cg_o`. | Timing | |
| 2991 | +| CSS_Clk_3 | Caliptra Subsystem | The core clock (`cptra_ss_clk_i`) frequency must be at least twice the TCK clock frequency of each JTAG TAP endpoint so that JTAG data passes correctly through the DMI synchronizers. | Timing | |
| 2992 | +| CSS_Rst_1 | Caliptra Subsystem | Caliptra Subsystem reset input `cptra_ss_rst_b_i` must assert for a minimum duration of 32 clock cycles. | Functionality | |
| 2993 | +| CSS_Rst_2 | Caliptra Subsystem | Caliptra Subsystem reset input `cptra_ss_rst_b_i` must be deasserted synchronous to `cptra_ss_clk_i`. | Timing | |
| 2994 | +| CSS_Rst_3 | Caliptra Subsystem | `cptra_ss_rst_b_o` must be used for memory logic connected to MCU SRAM or MCU MBOX to avoid RDC corruption. | Timing | |
| 2995 | +| CSS_Rst_4 | MCI | Integrators must not issue a warm reset (toggle `cptra_ss_rst_b_i`) until both Caliptra and MCU have each received and successfully loaded at least one firmware image. Resetting before firmware initialization risks execution from uninitialized SRAM. | Functionality | |
| 2996 | +| CSS_Rst_5 | MCI | SoC should not assert `cptra_ss_rst_b_i` until after `cptra_ss_mcu_halt_status_o` is asserted to guarantee MCU is idle and no outstanding AXI transactions. | Functionality | |
| 2997 | +| CSS_Pwr_1 | Caliptra Subsystem | `cptra_ss_pwrgood_i` must be generated by the power management unit or system power controller to properly reflect SoC power condition. | Functionality | |
| 2998 | +| CSS_Pwr_2 | Caliptra Subsystem | `cptra_ss_pwrgood_i` deassertion must be synchronous to `cptra_ss_clk_i` to prevent metastability issues. | Timing | |
| 2999 | +| CSS_Pwr_3 | Caliptra Subsystem | SRAMs must NOT go through BIST or repair flows across a warm reset; SRAM repair must occur during cold reset before deasserting `cptra_ss_rst_b_i`. | Functionality | |
| 3000 | +| CSS_Axi_1 | Caliptra Subsystem | AXI DATA WIDTHS of all components (both manager and subordinate interfaces) connected to the AXI interconnect must be unmodified from the default configuration, as alternative data width values are unverified. | Functionality | |
| 3001 | +| CSS_Axi_2 | MCI | AXI ADDR_WIDTH must be wide enough to fully address the MCI address space. | Functionality | |
| 3002 | +| CSS_Axi_3 | MCI | MCI base address must align to the MCI total addressable space calculated from MCU_SRAM_OFFSET + MCU_SRAM_SIZE. | Functionality | |
| 3003 | +| CSS_Axi_4 | Caliptra Subsystem | ARUSER and AWUSER (32-bit) must be passed unmodified through the AXI interconnect to all AXI subordinates for secure access filtering. | Threat Model | |
| 3004 | +| CSS_Axi_5 | Caliptra Subsystem | AXI ID width at each MCU manager interface must not be modified from configured values (IFU_BUS_TAG: 3, LSU_BUS_TAG: 3, SB_BUS_TAG: 1). | Functionality | |
| 3005 | +| CSS_Axi_6 | Caliptra Subsystem | The SoC AXI interconnect routing policy must prevent untrusted AXI managers from being routed to Caliptra Subsystem subordinate interfaces. While each block performs its own AXI USER-based access filtering, the interconnect routing policy is required as a first line of defense. | Threat Model | |
| 3006 | +| CSS_Axi_7 | MCI | `cptra_ss_strap_mcu_lsu_axi_user_i` and `cptra_ss_strap_mcu_ifu_axi_user_i` must be driven from constant, non-software-programmable sources throughout the boot session. These straps directly define the MCU's outgoing ARUSER and AWUSER identity and must not be routed through mutable logic. See [Strap Timing Requirements](#strap-timing-requirements) and [Connecting AXI Interconnect](#connecting-axi-interconnect). | Threat Model | |
| 3007 | +| CSS_Axi_8 | MCI | When using [MCU No ROM Config](#mcu-no-rom-config), `cptra_ss_strap_mci_soc_config_axi_user_i` must identify the designated trusted SoC configuration agent, which must be distinct from the MCU. When using [No Caliptra Core Config](#no-caliptra-core-config), `cptra_ss_strap_mcu_sram_config_axi_user_i` must identify the designated trusted SoC firmware-provisioning agent, which must be distinct from the MCU. The SoC must prevent all other agents from generating AXI transactions that match either configured identity. `cptra_ss_strap_mci_soc_config_axi_user_i` must be 0 when no SoC configuration agent is authorized; its `32'hFFFF_FFFF` debug wildcard must not be used in production. | Threat Model | |
| 3008 | +| CSS_Axi_9 | MCI | For each instantiated MCI mailbox, integrators must define the subset of trusted AXI users permitted to access it. Before any SoC agent uses the mailbox, integrators must either configure the trusted-user list at integration time with `SET_MCU_MBOX{0,1}_AXI_USER_INTEG` and `MCU_MBOX{0,1}_VALID_AXI_USER`, or program and lock `MBOX*_VALID_AXI_USER` with `MBOX*_AXI_USER_LOCK`. All identities outside the defined trusted-user subset must remain unauthorized. See [MCU Mailbox Limited Trusted AXI users](#mcu-mailbox-limited-trusted-axi-users). | Threat Model | |
| 3009 | +| CSS_Axi_10 | Caliptra Subsystem | The SoC must drive a defined 32-bit ARUSER or AWUSER identity on every AXI request that can reach an AXI_USER-filtering Caliptra Subsystem block: MCI (including MCU SRAM and MCI mailboxes), Fuse Controller, or I3C. The AXI_USER identity must identify the originating AXI agent and must not be replaced with other transaction metadata. This requirement is additive to, and does not replace, the Caliptra Core AXI_USER requirements. See [Connecting AXI Interconnect](#connecting-axi-interconnect). | Threat Model | |
| 3010 | +| CSS_Axi_11 | Caliptra Subsystem | AXI_USER identities configured as authorized users for MCI, Fuse Controller, or I3C must uniquely identify a single AXI agent or trust domain. The SoC must prevent an agent from generating an ARUSER or AWUSER value assigned to another agent, and must ensure that every possible AXI_USER value generated by an unauthorized agent cannot match a configured authorized identity. This requirement is additive to, and does not replace, the Caliptra Core AXI_USER requirements. | Threat Model | |
| 3011 | +| CSS_Mem_1 | Caliptra Subsystem | SRAMs must be instantiated outside of the Caliptra Subsystem boundary and connected via memory export interfaces. | Functionality | |
| 3012 | +| CSS_Mem_2 | Caliptra Subsystem | All entries in SRAM must be initialized to 0 value prior to deasserting `cptra_ss_rst_b_i` during cold reset. | Functionality | |
| 3013 | +| CSS_Mem_3 | MCI | MCU SRAM size must be a minimum of 4KB and maximum of 2MB, configured via `MCU_SRAM_SIZE_KB` parameter. | Functionality | |
| 3014 | +| CSS_Mem_4 | MCU | MCU ROM write-enable (we) and write-data (wdata) signals must be left unconnected as MCU ROM has no write support. | Functionality | |
| 3015 | +| CSS_Mem_5 | MCI | MCU MBOX SRAM sizes are set via `MCU_MBOX0_SIZE_KB` and `MCU_MBOX1_SIZE_KB` parameters and must be configured with a maximum size of 2MB each. | Functionality | |
| 3016 | +| CSS_Mem_6 | Caliptra Subsystem | An SoC-provided external staging area used in place of the MCU MBOX SRAM must implement an equivalent one-way ownership handoff. Once the image is loaded, the SoC must lock the staging area for exclusive Caliptra Core access. The lock must prevent all other agents from reading or writing the staging area and may be released only by Caliptra Core. When Caliptra Core does NOT have the access lock, all Caliptra Core reads shall return 0s or AXI errors. See [Caliptra External Staging Area](https://github.com/chipsalliance/caliptra-rtl/blob/main/docs/CaliptraIntegrationSpecification.md#external-staging-area). | Threat Model | |
| 3017 | +| CSS_FC_1 | Fuse Controller | Secret fuse fields (UDS and Field-Entropy) and their corresponding flip-flops must be excluded from the scan chain (both scan-in and scan-out paths). See [FC Integration Requirements](#fc-integration-requirements) for the set of signals to exclude. This requirement parallels the Caliptra Core scan exclusion requirement for device keys. | Threat Model | |
| 3018 | +| CSS_FC_2 | Fuse Controller | Buffering flops for SECRET_MANUF_PARTITION, SECRET_PROD_PARTITION_0-3, and SECRET_LC_TRANSITION must be excluded from the scan chain. See [FC Integration Requirements](#fc-integration-requirements) for the set of signals to exclude. | Threat Model | |
| 3019 | +| CSS_FC_3 | Fuse Controller | OTP broadcast port `otp_broadcast_o`, its propagated signals, and driver signals must not be included in the scan chain. See [FC Integration Requirements](#fc-integration-requirements) for the set of signals to exclude. | Threat Model | |
| 3020 | +| CSS_FC_4 | Fuse Controller | PRESENT cipher keys in `otp_ctrl_part_pkg.sv` and registers driven by these parameters must be excluded from the scan chain. | Threat Model | |
| 3021 | +| CSS_FC_5 | Fuse Controller | Caliptra Core must be the only entity that can perform FIPS zeroization of UDS and Field Entropy. Note: per ISO 19790:2025 (as adopted by FIPS), zeroization of identity keys is not mandated; this requirement applies only when zeroization is supported by the SoC. | Functionality | |
| 3022 | +| CSS_FC_6 | Fuse Controller | As part of OTP gasket implementation for all fuse partitions containing secrets that must be zeroized, integrators MUST implement zeroization of the corresponding Error Correction Code (ECC) bits inside fuse macros per FIPS guidelines. Refer to [FIPS Zeroization Sequence For ECC](#fips-zeroization-sequence-for-ecc) for more details. | Functionality | |
| 3023 | +| CSS_FC_7 | Fuse Controller | `cptra_ss_strap_generic_0_i` must encode the idle bit location and STATUS register offset for fuse controller. | Functionality | |
| 3024 | +| CSS_FC_8 | Fuse Controller | `cptra_ss_strap_generic_1_i` must provide the address of the CMD register for fuse controller. | Functionality | |
| 3025 | +| CSS_FC_9 | Fuse Controller | The OTP macro or wrapper must be compliant with requirements for burn semantics and word-level rewrites as described in [Life Cycle OTP Programming Behavior and Integrator Responsibilities](#life-cycle-otp-programming-behavior-and-integrator-responsibilities). | Functionality | |
| 3026 | +| CSS_FC_10 | Fuse Controller | Fuse map addresses for `SECRET_MANUF_PARTITION` and `SECRET_PROD_PARTITION_0`-`SECRET_PROD_PARTITION_3` must not be modified. The Fuse Controller filter relies on these addresses being fixed for access control to the secret partitions containing UDS seed and field entropy. | Threat Model | |
| 3027 | +| CSS_FC_11 | Fuse Controller | The total number of fuse partitions configured by the integrator must fit within the available error bits in the Fuse Controller `STATUS` register. Each additional partition consumes one error bit; integrators extending the fuse map must verify the partition count does not exceed available `STATUS` bits. | Functionality | |
| 3028 | +| CSS_FC_12 | Fuse Controller | The integrator must implement the fuse macro wrapper such that it aligns with the Fuse Controller protocol and supports operations including zeroization (data, zeroization marker, digest, and ECC bits) and macro error reporting. The wrapper provided in the caliptra-ss testbench is a model only and must be replaced for production integration. | Functionality | |
| 3029 | +| CSS_FC_13 | Fuse Controller | The Fuse Controller performs digest-based integrity checking only for hardware (HW) partitions. The integrator must provide integrity checking of software (SW) partitions, either in the fuse macro wrapper or in MCU firmware. | Threat Model | |
| 3030 | +| CSS_FC_14 | Fuse Controller | Any change to the number of fuse partitions or partition definitions must be produced by the Caliptra fuse-generation Python script (not via hand edits to generated RTL). | Trademark Compliance | |
| 3031 | +| CSS_FC_15 | Fuse Controller | Integrators must define, document, and implement a manufacturing plan that aligns fuse provisioning sequencing with the lifecycle states in which each partition can legally be provisioned. | Functionality | |
| 3032 | +| CSS_FC_16 | Fuse Controller | Access to the Fuse Controller must be restricted to Caliptra Core and the MCU, to prevent access to non-secret fuses (such as PK revocation) that impact device policy. Integrators must add interconnect policies or isolation logic to prevent other SoC agents from accessing the Fuse Controller registers and storage. This requirement is additive to the existing AXI User filtering logic defined in [Programming Interface](#programming-interface-1). NOTE: The DAI for Fuse Controller requires AXI write access, even for fuse read operations, so simply disabling AXI write access to non-secret Fuse Controller partitions is insufficient for meeting this requirement. All access by entities other than Caliptra or MCU must be disabled. | Threat Model | |
| 3033 | +| CSS_FC_17 | Fuse Controller | OTP scrambling constants in `otp_ctrl_part_pkg.sv` (`RndCnstKey`, `RndCnstDigestConst`, `RndCnstDigestIV` - the PRESENT cipher keys and digest constants/IVs) must be regenerated by each integrator using the fuse-generation script with a unique secret seed (`--seed`). Shipping the open-source default constants would cause all devices to share the same OTP scrambling key, enabling decryption of secret partitions (UDS, field entropy, LC tokens) if the defaults were known. | Threat Model | |
| 3034 | +| CSS_FC_18 | Fuse Controller | Integrators must connect SoC-level tamper-detection sources to `cptra_ss_lc_esclate_scrap_state0_i`/`cptra_ss_lc_esclate_scrap_state1_i` to satisfy FIPS 140-3 tamper-response requirements. `caliptra_ss_otp_state_valid_o` is driven low whenever a Fuse Controller fatal error occurs or `lc_escalate_en` is asserted, so integrators must not rely on OTP-derived life-cycle state while it is deasserted. | Threat Model | |
| 3035 | +| CSS_FC_19 | Fuse Controller | The `cptra_ss_FIPS_ZEROIZATION_PPD_i` physical pin can trigger irreversible state transitions. Integrators should include glitch mitigation on this pin (e.g., analog filtering, synchronization, and multi-cycle qualification) so a transient glitch cannot cause unintended FIPS zeroization. | Functionality | |
| 3036 | +| CSS_FC_20 | Fuse Controller | The Fuse Controller instantiates a single scrambler (`u_otp_ctrl_scrmbl`) that is time-multiplexed across all partitions, so its working registers cannot be excluded per partition. Exclude only these three registers from the scan chain: `data_state_q` (64b), `data_shadow_q` (64b) and `digest_state_q` (64b), 192 flops in total. The PRESENT round-function logic, the scrambler FSM and the arbiter do not need to be excluded, and the scrambler key registers are already covered by the PRESENT cipher key requirement in this table. Partition contents pass through these registers in the clear while being descrambled. The debug intent strap prevents UDS and Field Entropy from being sensed, but `SECRET_LC_TRANSITION` is intentionally still sensed so that the Life Cycle Controller retains its transition tokens, so the RMA token digest reaches these registers in every debug scenario. | Threat Model | |
| 3037 | +| CSS_FC_21 | Fuse Controller | The `cptra_ss_otp_dft_en_o` output is provided to enable debug capabilities in the fuse macro wrapper logic. It is asserted only in the `TEST_UNLOCKED*` life cycle states, and is not re-asserted in later states where secrets may have been provisioned. Integrators must use this signal, rather than `cptra_ss_soc_dft_en_o`, to gate the fuse macro wrapper DFT interface. | Threat Model | |
| 3038 | +| CSS_LCC_1 | Life Cycle Controller | LC transition token scan exclusions must follow [LC Integration Requirements](#lc-integration-requirements). | Threat Model | |
| 3039 | +| CSS_LCC_2 | Life Cycle Controller | `Allow_RMA_or_SCRAP_on_PPD` GPIO strap must be tied to 0 if not being used to prevent breaking LC controller's internal FSM. | Functionality | |
| 3040 | +| CSS_LCC_3 | Life Cycle Controller | The `Allow_RMA_or_SCRAP_on_PPD` and escalation input pins (`esc_scrap_state0`, `esc_scrap_state1`) can trigger irreversible lifecycle transitions (e.g., SCRAP). Integrators should include glitch mitigation on these inputs (e.g., filtering, synchronization, multi-cycle qualification) so a transient glitch cannot cause unintended state transitions. | Functionality | |
| 3041 | +| CSS_LCC_4 | Life Cycle Controller | SoC must respond to external clock switch request with acknowledgement within 2 clock cycles of internal clock. | Functionality | |
| 3042 | +| CSS_LCC_5 | Life Cycle Controller | All required tokens for state transitions must be programmed before the token partition is locked, as they cannot be updated afterward. | Functionality | |
| 3043 | +| CSS_LCC_6 | Life Cycle Controller | If a volatile-unlock state transition method is used, the integrator's DFT/test infrastructure must account for the unlock state being lost on power cycle (volatile unlock is reflected only via `caliptra_ss_volatile_raw_unlock_success_o`, not in fuse-controller broadcast state). | Functionality | |
| 3044 | +| CSS_LCC_7 | Life Cycle Controller | The Life Cycle Controller debug-decoding signals must be used as gating logic in the SoC's DFT/DFD process so that debug authorization is enforced in the integrator's DFT/DFD flows. | Functionality | |
| 3045 | +| CSS_LCC_8 | Life Cycle Controller | Once the Life Cycle Controller reaches `TEST_UNLOCKED0`, integrators must provision all required LCC TOKEN fuse partitions (e.g., transition tokens, RMA token) prior to locking the token partition. | Functionality | |
| 3046 | +| CSS_LCC_9 | Life Cycle Controller | LCC transition TOKENs and `MANUF_DEBUG_UNLOCK` TOKENs must be generated from a cryptographically secure entropy source compliant with standards like [NIST SP 800-90A](https://csrc.nist.gov/pubs/sp/800/90/a/r1/final), [SP 800-90B](https://csrc.nist.gov/pubs/sp/800/90/b/final), [SP 800-90C](https://csrc.nist.gov/pubs/sp/800/90/c/4pd). | Threat Model | |
| 3047 | +| CSS_LCC_10 | Life Cycle Controller | Integrators must decode `cptra_ss_lc_escalate_en_o` using its full `lc_ctrl_pkg::lc_tx_t` encoding (`On=4'b0101`, `Off=4'b1010`), treating any non-`Off` value as an active escalation, and must not implement a software or hardware path to clear it once asserted (it returns to `Off` only via system reset). If consumed outside the LC clock domain, it must be resynchronized with a multibit-preserving synchronizer rather than a per-bit 2FF sync. | Threat Model | |
| 3048 | +| CSS_LCC_11 | Life Cycle Controller | Integrators must define, document, and implement SoC-level behavior in response to `cptra_ss_lc_escalate_en_o` assertion, propagating the same lockdown it triggers internally today (permanent lockout of Fuse Controller partitions and the Life Cycle Controller's KMAC interface) to other dependent SoC blocks (e.g., gating debug/DFT enables and key material, routing to system-level recovery). | Threat Model | |
| 3049 | +| CSS_MCI_1 | MCI | `cptra_ss_mcu_halt_status_o` and `cptra_ss_mcu_halt_ack_o` must be looped back to their respective input ports unless the SoC supports MCU No ROM Config. An integrator that does not use the loopback must satisfy all applicable requirements in [MCU Halt Ack Interface](#mcu-halt-ack-interface), [MCU No ROM Config](#mcu-no-rom-config), and [MCU FW Boot Update](#mcu-fw-boot-update). The integrator must follow applicable recommendations in those sections unless it documents a technically sound rationale that demonstrates the alternative provides equivalent or better functionality and security. | Functionality | |
| 3050 | +| CSS_MCI_2 | MCI | Errors connected to MCI aggregate error infrastructure must be level signals; pulses are not permitted. | Functionality | |
| 3051 | +| CSS_MCI_3 | MCI | `cptra_ss_cptra_generic_fw_exec_ctrl_2_mcu_o` must be looped back to `cptra_ss_cptra_generic_fw_exec_ctrl_2_mcu_i` unless the SoC controls MCU firmware updates. An integrator that does not use the loopback must satisfy all applicable requirements in [FW Execution Control Connections](#fw-execution-control-connections), [MCI Caliptra Core Connectivity Requirements](#mci-caliptra-core-connectivity-requirements), and [MCU FW Update Flows](#mcu-fw-update-flows). The integrator must follow applicable recommendations in those sections unless it documents a technically sound rationale that demonstrates the alternative provides equivalent or better functionality and security. | Functionality | |
| 3052 | +| CSS_MCI_4 | MCI | `cptra_ss_mci_cptra_rst_b_o` must be looped back to `cptra_ss_mci_cptra_rst_b_i` unless the SoC modifies Caliptra reset control. An integrator that does not use the loopback must satisfy all applicable requirements in [Caliptra Core Reset Control](#caliptra-core-reset-control), [MCI Integration Requirements](#mci-integration-requirements), and [Reset Ordering](#reset-ordering). The integrator must follow applicable recommendations in those sections unless it documents a technically sound rationale that demonstrates the alternative provides equivalent or better functionality and security. | Functionality | |
| 3053 | +| CSS_MCI_5 | MCI | SoC integrators must analyze RDC and CDC effects of any modification to Caliptra or MCU reset control to ensure safety of the logic against metastability. | Timing | |
| 3054 | +| CSS_MCI_6 | MCI | `SOC_DFT_EN` and `SOC_HW_DEBUG_EN` outputs are not guaranteed stable during scan mode. Integrators must not rely on their stability once scan mode is active and must independently stabilize any downstream DFT/debug control signals derived from them, per [DFT Reset Control](#mci-integration-requirements). | Threat Model | |
| 3055 | +| CSS_I3C_1 | I3C | Connect `cptra_ss_i3c_recovery_payload_available_o` to `cptra_ss_i3c_recovery_payload_available_i` if no external I3C. Integrators using an external I3C must implement equivalent logic to provide as an input. | Functionality | |
| 3056 | +| CSS_I3C_2 | I3C | Connect `cptra_ss_i3c_recovery_image_activated_o` to `cptra_ss_i3c_recovery_image_activated_i` if no external I3C. Integrators using an external I3C must implement equivalent logic to provide as an input. | Functionality | |
| 3057 | +| CSS_I3C_3 | I3C | I3C targets must be programmed with STATIC address and a unique set of PID/BCR/DCR CSRs via AXI | Functionality | |
| 3058 | +| CSS_I3C_4 | I3C | The I3C core must be statically configured during the MCU boot flow as either an I3C Target or an AXI Recovery Interface; this selection is mutually exclusive and cannot be changed dynamically after boot. | Functionality | |
| 3059 | +| CSS_I3C_5 | I3C | If the SoC requires both AXI Recovery and standard I3C Target functionality simultaneously, a second I3C core must be instantiated outside of Caliptra SS. | Functionality | |
| 3060 | +| CSS_Tech_1 | MCU | `css_mcu0_dmi_jtag_to_core_sync.v` must be replaced with a technology-specific synchronizer that provides at least two synchronization stages and preserves reset behavior. The replacement must generate exactly one `clk`-cycle `reg_en` and `reg_wr_en` pulse for each synchronized JTAG read or write request. See CSS_Tech_6 for validation requirements. | Timing | |
| 3061 | +| CSS_Tech_2 | MCU | Technology-specific clock gaters must replace `css_mcu0_rvclkhdr`/`css_mcu0_rvoclkhdr` in `css_mcu0_beh_lib.sv` or set TECH_SPECIFIC_EC_RV_ICG. | Timing | |
| 3062 | +| CSS_Tech_3 | MCU | `css_mcu0_rvsyncss` in `css_mcu0_beh_lib.sv` must be replaced with a technology-specific synchronizer that provides at least two synchronization stages and preserves width, reset polarity, and reset values. See CSS_Tech_6 for validation requirements. | Timing | |
| 3063 | +| CSS_Tech_4 | MCI | Technology-specific replacements are required for the Caliptra Core synchronizers reused by MCI, including `caliptra_2ff_sync` and `caliptra_prim_flop_2sync`, and for clock-gating cells. Synchronizer replacements must meet CSS_Tech_6; in particular, MCI reset-window, boot, halt, error, and firmware-update crossings require latency analysis. See [MCI Integration Requirements](#mci-integration-requirements). | Timing | |
| 3064 | +| CSS_Tech_5 | Caliptra Core | Integrators must perform all technology-specific cell replacements documented as recommendations in the [Caliptra Core Integration Specification](https://github.com/chipsalliance/caliptra-rtl/blob/main/docs/CaliptraIntegrationSpecification.md#Integrator-RTL-modification-requirements). All clock-gating and synchronizer cell replacements defined in that section are mandatory in Caliptra Subsystem integrations; synchronizer replacements must meet CSS_Tech_6. | Functionality | |
| 3065 | +| CSS_Tech_6 | Caliptra Subsystem | For every synchronizer replacement required by CSS_Tech_1, CSS_Tech_3, CSS_Tech_4, or CSS_Tech_5, the library implementation must implement synchronizer functionality that is equivalent to the replaced module. Additional synchronizer stages are permitted only after the integrator validates that its added destination-clock latency preserves reset and boot ordering, pulse/event delivery, asynchronous FIFO behavior, and multi-bit security-state behavior. The integrator owns CDC/RDC sign-off, targeted protocol simulation, and regression validation of every replaced instance and its downstream logic. | Timing | |
| 3066 | +| CSS_Cfg_1 | Caliptra Subsystem | Build processes must define the Verilog macro `CALIPTRA_MODE_SUBSYSTEM`. | Functionality | |
| 3067 | +| CSS_Cfg_2 | Caliptra Subsystem | Build processes must define the Verilog macro `CALIPTRA_INTERNAL_TRNG`. Integrations of Caliptra Subsystem shall not use an external TRNG. The TRNG self-test threshold registers (`CPTRA_iTRNG_ENTROPY_CONFIG0` and `CPTRA_iTRNG_ENTROPY_CONFIG1`) MUST be set to non-zero values to enable entropy self-testing. These requirements supplement but do not replace any Caliptra Core Integration Requirements pertaining to Internal TRNG. | Functionality | |
| 3068 | +| CSS_Cfg_3 | MCU | Integrators are permitted to reconfigure the MCU for their own needs per [MCU Core Configuration Customization](#MCU-Core-Configuration-Customization), but integrators shall not replace the MCU with any alternative microprocessor core. | Functionality | |
| 3069 | +| CSS_Cfg_4 | I3C | The Verilog macro `DISABLE_INPUT_FF` must NOT be defined. Defining it removes the synchronizer flip-flop on the I3C SCL input signal, creating a CDC violation. | Functionality | |
| 3070 | +| CSS_Core_1 | Caliptra Core | In addition to all requirements listed in this table, integrators must adhere to all integration requirements defined in the Caliptra Core Integration Specification. Caliptra Subsystem Integration Requirements supplement but do not replace any Caliptra Core Integration Requirements. | Trademark Compliance | |
| 2691 | 3071 | |
| 2692 | 3072 | |
| 2693 | 3073 | # Terminology |