📄 Source: chipsalliance/caliptra-ss/docs/CaliptraSSHardwareSpecification.md @ 2041523

Caliptra Subsystem Hardware Specification

Version 2p1

Scope
- Document Version
Caliptra Subsystem Requirements
Caliptra Subsystem Architectural Flows
I3C Streaming Boot (Recovery) Interface
AXI Streaming Boot (Recovery) Interface
Caliptra Core AXI Manager & DMA assist
Caliptra Subsystem Fuse Controller
Caliptra Subsystem Life Cycle Controller
Manufacturer Control Unit (MCU)
Manufacturer Control Interface (MCI)

Scope

This document defines technical specifications for a subsystem design utilizing Caliptra RoT in Subystem Mode. This document, along with Caliptra Hardware Specification, shall comprise the Caliptra Subsystem technical specification.

Document Version

Date	Document Version	Description
Jan 31st, 2025	v0p8	Work in progress
Apr 30th, 2025	v1p0-rc1	Initial release candidate of Caliptra Gen 2.0 Subsystem Documents. Specifcations updated with: - Updated details on component features (MCU mailbox, MCU trace buffer, MCI error aggregation, FC fuse zeroization) - Details on design connectivity with top-level ports - Port and register updates
Oct 12th, 2025	v2p1	Final release of Caliptra Subsystem 2.1

Caliptra Subsystem Requirements

Definitions

RA: Recovery Agent / Streaming boot Agent
MCI: Manufacturer Control Interface
MCU: Manufacturer Control Unit

Caliptra-Passive-Mode (Legacy)

SOC manages boot media peripherals and Caliptra is used as Root of trust for measurements.

Caliptra-subsystem-mode

Caliptra owns the recovery interface (peripheral independent) and Caliptra is THE RoT of the SoC. Any SOC specific variables that needs to be stored and retrieved securely from NV storage is handled using Caliptra.

Caliptra Subsystem Architectural Requirements

MCU [Manufacturer Control Unit] runs Manufacturer specific FW authenticated, measured & loaded by Caliptra at boot time.
MCU will use Caliptra RT FW to auth/measure/load all of the FW belonging to the SOC.
MCU ROM/FW on MCU should be capable of performing SOC specific initialization.
MCU ROM/FW should be able to perform SoC management functions including performing reset control, SoC specific security policy enforcement, SOC initial configuration (eg. any GPIO programming, glitch detection circuits, reading/moving non-secret fuses etc.).

Note: Widgets that toggle the reset or other wires that set security permissions are SOC specific implementations.

Fuse controller for provisioning Caliptra fuses -> IFP (In-field programmable) fusing is performed by MCU RT; SW partition fuses in fuse controller are managed by MCU (ROM or RT); Caliptra HW is responsible for reading the secret fuses (Caliptra ROM, MCU ROM or any other SOC ROM or any RT FW should NOT have access to read the secret fuses in production).
Recovery stack must be implemented. Please refer to I3C recovery section for more details and references. OCP Recovery registers implemented in I3C must follow the security filtering requirements specified in the recovery implementation spec (eg. MCU can ONLY access subset of the recovery registers as defined by the recovery implementation).
Supports silicon t0 boot to load and run required FW across chiplets.
OCP recovery stack is implemented in Caliptra for Caliptra-subsystem-mode
MCU SRAM (or part of the SRAM that is mapped for Code/Data execution) should be readable/writeable ONLY by Caliptra until Caliptra gives permission to MCU to use it.
Caliptra can only load its FW, SOC manifest and MCU FW by reading the recovery interface registers.
Caliptra ROM should know the offset of the recovery interface at its boot time. SOC has a choice to program this interface using MCU ROM or Hard strapped register address at integration time (Hard strapping at SOC integration time is recommended)
Caliptra HW must know the offset of the registers where secrets (UDS, FE) and assets (PK hashes) exist at boot time. These should be hard strapped/configured at integration time.
Caliptra ROM must know the address to where UDS-seed needs to be written to; this address should be hard strapped/configured at integration time.
Any registers holding secrets/assets in fuse controller must follow the same rules as Caliptra 1.0/2.0 fuse register requirements (eg. clear on debug, clear on read once etc.)
MCU SRAM and ROM sizes should be configurable at SOC integration time.

Caliptra Subsystem HW Requirements

Caliptra 2.0 HW requirements (Subsystem Support)

Full AXI read/write channels (aka AXI manager) for subsystem (for MCU and Caliptra) a. For backward compatibility, AXI mgr. interface can be a no-connect and that configuration is validated.
HW logic/Programmable DMA

Read MMIO space for variable length.
Data returned from the above read can be exposed directly to the FW OR allow it to be written to a subsystem/SOC destination as programmed by ROM/FW.
Programmable logic to allow for SOC directed writes (from FW or from the above route back) to be sent through the SHA accelerator.
(Future open/stretch goal): If AES engine accelerator is integrated into Caliptra, then implement decryption before sending the writes back to the destination programmed by the ROM/FW.
This widget should have accessibility in manufacturing and debug mode over JTAG (can be exposed using the same JTAG interface as Caliptra 1.0). Ensure through validation that no asset can be read using this widget in those modes.

Expand manuf flow register to include UDS programming request steps
SOC Key Release HW (Required for OCP Lock flow too)

Separate SOC Key Vault must be implemented (it is a separate structure from the current Caliptra KV).
In at least one configuration, the SOC KV must be implemented as an SRAM that is external and configurable by the SOC OR or an internal configurable SOC KV structure. If this is achievable within the Caliptra 2.0 milestone, only one of these would be the chosen implementation and configuration. This will be a design decision based on effort & schedule.
If implemented as a SRAM, data written and read into the SOC KV SRAM is decrypted & encrypted so that SOC DFT or other side channels cannot exfilterate the data.
Caliptra FW will indicate to the SOC KV Release HW to release the key by supplying the key handle to read from.
Destination address to which the key must be written to is programmed by the Caliptra FW into AXI MGR DMA HW.
SOC KV must have the same attributes as Caliptra internal KV. Additionally, it must also have an attribute of read-once and clear.

Ability to use two or more cryptos concurrently
Change APB -> AXI-Sub with the same capabilities (AXI USERID filtering replaces PAUSER based filtering, multiple targets for SHA acc, mailbox, fuses, registers etc. all)
Future/Stretch Goal: Parity support on AXI-SUB & MGR

MCU HW requirements

MCU should not be in the FIPS boundary and must not have any crypto functions. MCU must use Caliptra for any security flows (eg. security policy authorization) or traditional RoT support (eg. SPDM).
MCU VeeR must support PMP & User mode.
MCU AXI is directly connected to the SOC fabric in a way that allows a MMIO based control of the SoC as required for SOC security, manageability and boot functionality.
MCU HW should add AXI-ID without any involvement of the ROM or FW running on the MCU; Implying any AXI access out of MCU (LSU side) should carry MCU USERID that HW populates.
MCU executes from a SRAM that is at subsystem level.
MCU uses instruction cache for speed up
It is required that all NV read/writes (eg. NV variables in flash) that require a RoT support to securely store/restore must go through Caliptra.
NV-storage peripheral shall be built in such a way that it will only accept transactions from MCU.
Support for MCU first fetch vector to direct towards MCU SRAM post reset

Subsystem Components HW requirements

Fabric

AXI Interconnect connects Caliptra, I3C, Fuse Controller, Life Cycle Controller, MCU and its memory components with the rest of the SOC.

Note: Because each SOC integration model is different, AXI interconnect is NOT implemented by the subsystem but subsystem must validate using an AXI interconnect VIP to ensure all the components operate per the flows documented in this specification.
For the VIP interconnect configuration, all subtractively decoded transactions are sent towards SoC. AXI interconnect & Subsystem is validated with the assumption that all of them are running on the same clock domain.

To be documented: AXI-USERID requirements

MCU SRAM

Since it's used for instruction and data execution – therefore requires AXI Sub with USERID filtering.
Provide JTAG accessibility to allow for SRAM to be populated in a secured debug mode at power on time (debug policies will be same as Caliptra)
MCU SRAM should have an aperture that can only be unlocked by Caliptra after it loads the image
MCU SRAM has an aperture for MCU ROM to use part of the SRAM as a stack for its execution.
MCU SRAM supports an aperture to be used as a MCU Mailbox.

MCU ROM

MCU ROM also needs to have AXI Sub for any data access from MCU and thereby requires AXI-ID/USERID filtering.

I3C

I3C on AXI interconnect with AXI Subordinate
Spec 1.1.1 aligned, but only with optional features that are required per PCIe ECN # <>
AXI Sub must be supported.
UserID to MCU and Caliptra
MCU access lock for I3C recovery and data (FIFO) registers until recovery flow is completed. In other words, MCU ROM must not impact the data flow into Recovery IFC registers. Stretch Goal: DMA data payload back to destination (Caliptra or MCU)

Fuse Controller

AXI sub interface
Secrets (separate USERID and access constraints) vs SW partition separation
Registers implemented for “Secrets” should follow the same rules as Caliptra (no scan, clear on specific life cycle/security states)
Life cycle transition shall be implemented in hardware with no ROM/FW implementation and provides redundancy against fault & glitch attacks in the digital logic itself.
SOC debug in production mode shall be supported with the help Caliptra through post quantum resilient algorithms.
When debug mode is intended to be enabled & when enabled, all secrets/assets as defined should be wiped and provide the indication to SOC for any secrets/assets it may have.

MCI

HW logic to move secret fuses from Fuse controller to Caliptra.

Caliptra Subsystem Hardware Block Diagram

Figure: Caliptra Subsystem Block Diagram

Caliptra Subsystem Architectural Flows

Please refer to Caliptra Security Subsystem Specification for more details.

I3C Streaming Boot (Recovery) Interface

The I3C recovery interface acts as a standalone I3C target device for recovery. It will have a unique address compared to any other I3C endpoint for the device. It will comply with I3C Basic v1.1.1 specification. It will support I3C read and write transfer operations. It must support Max read and write data transfer of 1-256B excluding the command code (1 Byte), length (2 Byte), and PEC (1 Byte), total 4 Byte I3C header. Therefore, max recovery data per transfer will be limited to 256-byte data.

I3C recovery interface is responsible for the following list of actions:

Responding to command sent by Recovery Agent (RA)
Updating status registers based on interaction of AC-RoT and other devices
Asserting / Deasserting “payload_available” & “image_activated” signals

Streaming Boot (Recovery) Interface hard coded logic

Hardware registers size is fixed to multiple of 4 bytes, so that firmware can read or write with word boundary. Address offset will be programmed outside of the I3C device. Register access size must be restricted to individual register space and burst access with higher size must not be allowed.

Figure: I3C Streaming Boot (Recovery) Interface Logic Block Diagram

Hardware Registers

Note: Accessing the same address for INDIRECT_FIFO_DATA register will write or read the FIFO. It will not be available to access randomly as specified by the specification.

TODO: Add a link to rdl -> html file

Streaming Boot (Recovery) Interface Wires

Payload available

The Recovery Interface (I3C target) should receive a write transaction to INDIRECT_FIFO_DATA reg from BMC - 256B + 4B (Header), and wait for each I3C write to finish. Once I3C write transaction to INDIRECT_FIFO_DATA register is completed and PEC verification is successful, then the I3C target must assert "payload_available". DMA assist must wait for "payload_available" before reading. It must read 256B or last read with remaining data.
The "payload_available" signal remains asserted until Recovery Interface receives Read from DMA over AXI for INDIRECT_FIFO_DATA.

Image_activated

The I3C target will assert "image_activated" signal as soon as write to RECOVERY_CTRL register is received.
ROM will clear “image_activated” bit by writing to RECOVERY_CTRL register via DMA assist after the image is authenticated. As defined in the OCP Recovery Specification, RECOVERY_CTRL, byte 2 is used to specify the image activation control, and is Write-1-Clear. ROM must write 0xFF to this field to clear the image recovery status, which will also result in the Recovery Interface deasserting the “image_activated” signal to Caliptra.

I3C Streaming Boot (Recovery) Flow

Please refer to Caliptra Subsystem OCP Streaming Boot Sequence.

Figure: Caliptra Subsystem I3C Streaming Boot (Recovery) Flow

Caliptra ROM Requirements for OCP Streaming Boot

Caliptra firmware must follow these rules when implementing the OCP Streaming Boot flow:

Caliptra ROM and RT Firmware must wait for "image_activated" signal to assert before processing the image.
When image is sent to Caliptra Subsystem, Caliptra ROM & RT firmware must program DMA assist according to the rules defined in OCP Streaming Boot Payloads.
Once the image is processed, Caliptra ROM & RT firmware must initiate a write with data 1 via DMA to clear byte 2 “Image_activated” of the RECOVERY_CTRL register. This will allow BMC (or streaming boot initiator) to initiate subsequent image writes.

I3C and Caliptra-AXI Interactions

Received transfer data can be obtained by the driver via a read from XFER_DATA_PORT register. Received data threshold is indicated to BMC by the controller with TX_THLD_STAT interrupt if RX_THLD_STAT_EN is set. The RX threshold can be set via RX_BUF_THLD. In case of a read when no RX data is available, the controller shall raise an error on the frontend bus interface (AHB / AXI).

AXI Streaming Boot (Recovery) Interface

This feature allows streaming data or firmware by MCU over the AXI bus of the I3C module which is repurposed as a streaming boot interface while disabling I3C usage.

AXI Streaming Boot Flow implementation

The AXI Streaming Boot flow reuses the logic already present in the I3C core used in the Caliptra-SS design, with a runtime option essentially bypassing most of the I3C core communication logic (including the I3C recovery flow logic). The loopback functionality is configurable via the REC_INTF_CFG CSR which is set to I3C mode by default. Streaming boot CSRs are accessible over AXI. The transactions to the I3C core may be filtered using the AXI ID field. The logic is implemented so that the streaming boot implementation in the Caliptra core (HW & ROM) can operate without any changes. In order to enable setting W1C streaming boot registers, AXI streaming mode introduces an additional register - REC_INTF_REG_W1C_ACCESS.

AXI Streaming Boot Handler

In the regular (I3C) mode of the core, the Streaming Boot (Recovery) Handler strongly relies on the communication with the I3C Core internal logic by interfacing with TTI Queues. The bypass implementation modifies the I3C Core logic to allow direct access over the AXI bus to the structures specified by the OCP Streaming boot for compliance with the Caliptra Subsystem Streaming Boot Sequence.

The default design of the Streaming Boot Handler includes many blocks specifically designed to translate I3C bus traffic into recovery messages. It also automatically responds to the I3C commands by writing transaction descriptors and data for the TTI Queues.

Figure: Streaming Boot (Recovery) Handler in the I3C Core

In order enable the AXI streaming boot mechanism while reusing the existing logic and keeping compliance with Caliptra, the I3C core provides a custom bypass feature allowing direct communication with the Streaming Boot Handler via the AXI bus. The bypass disables the I3C communication logic. Data is routed from the TTI TX Queue to the Recovery Executor block, and written directly to the Indirect Data FIFO. The Caliptra ROM can access the data from the Indirect FIFO over the AXI bus (the same way it does in the regular I3C streaming boot flow). The dataflow in bypass mode (marked with green arrows) is depicted in the diagram below.

Figure: AXI Streaming Boot Handler in I3C Bypass Mode

AXI Streaming Boot CSRs

With the bypass feature enabled, the FIFO status CSRs in the Streaming Boot CSR file will be updated by the Streaming Bott Handler module. However, some registers like e.g. INDIRECT_FIFO_CTRL which are updated by I3C commands in a standard streaming boot flow, will have to be accessed and configured properly from the software running on the Caliptra MCU via the AXI bus. All configurable registers are writable from software, read only registers provide status information about Streaming Boot Handler internals, e.g. details about size and fill level of the Indirect FIFO.

Caliptra Core AXI Manager & DMA assist

SOC_IFC includes a hardware-assist block that is capable of initiating DMA transfers to the attached SoC AXI interconnect. The DMA transfers include several modes of operation, including raw transfer between SoC (AXI) addresses, moving data into or out of the SOC_IFC mailbox, directly encrypting/decrypting images with the AES block, and directly driving data through AHB CSR accesses to datain/dataout registers. One additional operating mode allows the DMA engine to autonomously wait for data availability via the OCP Recovery interface (which will be slowly populated via an I3C or similar interface).

Caliptra arms transfers by populating a transaction descriptor to the AXI DMA CSR block via register writes over the internal AHB bus. Once armed, the DMA will autonomously issue AXI transactions to the SoC until the requested data movement is completed. The DMA uses an internal FIFO to buffer transfer data. For any transfer using AXI Writes (Write Route is not disabled), the DMA waits until sufficient data is available in the FIFO before initiating any AXI write requests.

When arming the engine, Caliptra firmware is expected to have information about available AXI addresses that are legal for DMA usage. The DMA can facilitate transfer requests with 64-bit addresses. DMA AXI Manager logic automatically breaks larger transfer sizes into multiple valid AXI burst transfers (max 4KiB size), and legally traverses 4KiB address boundaries. The DMA AXI Manager supports a maximum transfer size of 1MiB in total. FIXED AXI bursts are allowed, to facilitate a FIFO-like operation on either read or write channels.

AXI Feature Support

The DMA assist initiates transactions on the AXI manager interface in compliance with the AXI specification. The generated AXI transactions adhere to the following rules:

All address requests will be aligned to the data width of the interface, which is configured as 32-bit in the 2.0 release.
The DMA will not issue Narrow transfers. That is, AxSIZE will always be set to match the data width of the interface (4 bytes).
All data lanes are used on all transfers. That is, the AXI manager Write channel will always set WSTRB to all 1s.
At most, 2 reads and 2 writes will be initiated at any time.
- When using a non-zero block_size for the transfer, in accordance with the Streaming Boot feature, at most 1 read and 1 write will be issued concurrently.
All transactions are initiated with AxID = 0, meaning that both reads and writes require in-order responses.
The maximum burst length initiated is constrained by the following parameters:
- Any transfer using the INCR burst type is restricted by both the maximum allowable length of an AXI transaction (AxLEN=255 or total byte count of 4KiB, whichever is smaller) and the size of the internal FIFO. In the 2.0 release the internal FIFO is configured with a depth of 512 bytes; the maximum transaction size allowed is 256 bytes, to allow up to 2 transactions to be outstanding at a time. In summary, the transfer size will always be 256 bytes or less (AxLEN = 63), as this is the smallest of (AxLEN = 255 -> 1KiB, 4KiB, and 256 bytes).
- Any transfer using the FIXED burst type is restricted by the AXI specification to a burst length of 16.
- When the block_size field is set to a non-zero value when arming the DMA, all transfers are restricted in size to specified block_size, in bytes.
- AXI transactions must not cross a 4KiB boundary, per the specification. If the transfer size requires crossing a boundary, the DMA will break it into smaller transactions that will go up to the boundary, then start from the next alignment boundary.

Routes

In the AXI DMA control state machine, both the read and write interfaces have their own “route”. A route is configured for read and write channels for every DMA operation that is requested. Routes determine how data flows through the DMA block.

Read routes always apply when an AXI read is requested and must be disabled otherwise. Any AXI read pushes the response data into the internal FIFO. The read route determines where this data is ultimately sent when it is popped from the FIFO. For the AHB route, data from the FIFO is populated to the dataout register, where it may be read via AHB by the Caliptra RV core. For the mailbox route, data from the FIFO flows into the mailbox; for these operations, the mailbox address is determined by the destination address register value, with an offset applied based on how many bytes have been written to the mailbox. For the AXI route, data from the FIFO flows into the AXI Write Manager, whereupon it is sent out to AXI on the WDATA signal. For the Read DISABLE route, data output from the FIFO always flows into the AXI write channel. In this case, data originates from a source other than an AXI read, so AXI reads are inactive.

Write routes always apply when an AXI write is requested and must be disabled otherwise. Any AXI write reads data from the internal FIFO before sending it over AXI. The write route determines where this data originates before it is pushed onto the FIFO. For the AHB route, a write to the datain register via AHB results in write data being pushed onto the FIFO. For the mailbox route, data is read from the mailbox and pushed onto the FIFO; for these operations, the mailbox address is determined by the source address register value, with an offset applied based on how many bytes have been read from the mailbox. For the AXI route, data flows from the AXI Read Manager into the FIFO. For the Write DISABLE route, data received on the AXI read channel is always pushed into the FIFO and then sent to an internal destination rather than a destination on the AXI bus, so AXI writes are inactive.

Example 1: Write Route == MBOX and Read Route == DISABLE

Example 2: Read Route == AHB and Write Route == DISABLE

Example 3: Read Route == AXI and Write Route == AXI

OCP Streaming Boot Payloads

The DMA block supports a special mode of operation that is intended for use in reading Firmware Image Payloads (for Streaming Boot) from the Recovery Interface, present in the Caliptra Subsystem. This operation mode relies on three key control signals: the payload_available signal input from the recovery interface, the read_fixed control bit, and the block_size register (from the DMA control CSR block).

This special mode of operation is only used for AXI Reads. To trigger the DMA to operate in this mode, Caliptra Firmware must program the block_size register to a non-zero value that is a power-of-two. Caliptra Firmware must also program the read_fixed control bit. Once the “go” bit is set, causing the DMA to begin operation, the DMA control logic will wait for the payload_available input to trigger. When this occurs, the DMA controller issues a read that has a size equal to (or smaller) than the configured block_size (the read may be smaller if required by AXI rules). This process repeats until the amount of data indicated in the byte_size register has been transferred.

When programming an AXI to AXI transfer for a Streaming Boot Payload (e.g., to transfer an SoC Firmware manifest into an AXI-attached SRAM), firmware must also follow these rules:

Programmed value of block_size must not exceed the largest legal AXI transaction size for a FIXED burst type. The DMA assist has a native data width of 4-bytes, so transaction size is restricted to 64-bytes due to the AXI specification limit of AxLEN == 15 for FIXED transactions.
Destination address must be aligned to the programmed value of block_size. For example, if block_size is set to 64-bytes, destination address must be an integer multiple of 0x40.

In all cases other than reading Recovery Interface Payloads, the block_size register must be programmed to 0.

AES Mode

The DMA block can directly stream images from AXI to AES for decrypt/encrypt, and then stream the processed image over AXI to some SOC storage. This can be done by configuring the AXI DMA as:

AES Mode == 1
(optional) aes_gcm_mode in DMA == 1
Read Route == AXI
Write Route == AXI
Block Size == 0 (OCP Stream Boot Disabled)
Read/Write Fixed == 0
Source Address == Start of image
Destination Address == Start address where processed image should be stored
Configure Byte Count - must be DWORD aligned

Other Read/Write Routes and Block sizes are not supported.

The AXI DMA AES Mode ONLY streams the image into and out of AES. It is Firmware's responsibility to:

Fully configure AES before streaming the image via AXI DMA
Push the IV, AAD header, and any other data into AES before streaming the image via AXI DMA
Retrieve any tags from AES after the image has been processed.

If the input image size is not a multiple of 4 DWORDS, the AES FSM will properly pad the AES input data with 0s. When streaming the image out it reads all 4 DWORDS from the AES, but only writes up to the last DWORD of the image to the destination. If aes_gcm_mode register is set, at the start of the transfer it updates the GCM shadow byte count and phase registers in AES to the appropriate byte count and GCM_TEXT phase. Before the last block transfer to the AES it will again update the GCM shadow register to the appropriate values.

Input images can be in little endian or big endian. It is FW's responsibility to configure the AES wrapper's ENDIAN_SWAP register.

If AXI DMA encounters any errors (AXI or other errors) it will finish the transfer and report an error. It is the Firmware's responsibility to clear the error in the AXI DMA and flush the AES if required.

When AXI DMA is using AES Caliptra shall not try to access AES via AHB until AXI DMA has completed.

AES is not directly exposed on the AXI bus for external entities, it is protected behind the AXI DMA and can only be accessed via Caliptra uC AHB or the Caliptra DMA.

AES Mode: Read Route == AXI, Write Route == AXI, AES Mode == 1

Programming Flowchart

General Rules:

If either Read or Write route is configured to AXI RD -> AXI WR, both routes must be configured as AXI RD -> AXI WR.
Read Route and Write Route must not both be disabled.
If Read Route is enabled to any configuration other than AXI RD-> AXI WR, Write route must be disabled.
If Read Route is disabled, Write route must be enabled to a configuration that is not AXI RD -> AXI WR.
If Read Route is disabled, Read Fixed field is ignored.
If Write Route is disabled, Write Fixed field is ignored.
Addresses and Byte Counts must be aligned to AXI data width (1 DWORD).
Block Size is used only for reads from the Subsystem Recovery Interface. When block size has a non-zero value, the DMA will only issue AXI read requests when the payload available input signal is set to 1, and will limit the size of read requests to the value of block size. For all other transactions (such as AXI writes, or any single-dword access to a subsystem register via the DMA), block size shall be set to a value of 0 for every transaction.
AES mode is only valid with Read/Write routes AXI RD -> AXI WR, Read/Write Fixed = 0, and Block Size 0.

Steps:

Write Byte Count
Write Block Size
Write Source Addr (value is ignored if data is from AHB)
Write Dest Addr (value is ignored if data is to AHB).
1. To perform an accelerated SHA operation on incoming read data, firmware sets the Read/Write route to AXI RD-> AXI WR, and the destination address to the SoC address for the SHA Acceleration data in aperture.
Set Interrupt Enables (optional)
If Mailbox R/W: Acquire Mailbox Lock
If SHA Acc Op:
1. First acquire Sha Accel Lock via AXI by using this flow (with the AHB-> AXI WR route) to initiate AXI manager action
2. Initiate Sha Accel streaming operation via AXI by using this flow (with the AHB-> AXI WR route) to initiate AXI manager action
3. Run this operation with the AXI RD -> AXI WR route to move data from SoC location into Sha Accelerator
If AES Mode:
1. Fully configure AES with IV/KEY see AES spec for more details
2. Stream in any header info to AES like AAD
3. Set read/write routes to AXI
4. Set AES_MODE in DMA
5. Set aes_gcm_mode in DMA if this is the AES mode
Set Control Register
1. Set Read/Write Routes
2. Set Read/Write Fixed=0/1
3. GO
4. (All 3 may be single write or separate, GO must be last bit to set)
If AHB data: Wait for RD FIFO not empty or WR FIFO not full
Push/Pop data (using Rd Data/Wr Data register offsets) until all requested bytes transferred
If AHB Error – check status0 for Error, then check for “Command Error”
Wait for TXN Done Interrupt (or Poll Status0)
Read Status0, confirm Busy=0, Error=0

Descriptor

https://chipsalliance.github.io/caliptra-rtl/main/internal-regs/?p=clp.axi_dma_reg

Caliptra Subsystem Fuse Controller

FUSE controller is an RTL module that is responsible for programming and reading the FUSEs. This module has an AXI interface that is connected to Caliptra Subsystem’s AXI interconnect. This module provides the device with one-time programming functionality, resulting in non-volatile programming that cannot be reversed. This functionality is delivered via an open-source FUSE Controller and a proprietary FUSE/OTP Macro. This RTL module manages the following FUSE partition mapping, which can be found in the Fuse Controller Memory Map.

Partition Details

The Fuse Controller is configured a total of 16 partitions (See Fuse Controller's Fuse Partition Map), while it can support different number of partitions based on SoC product requirements. Secret FUSE partitions are prefixed with the word "Secret" and are associated with specific Life Cycle (LC) states, such as "MANUF" or "PROD." This naming convention indicates the LC state required to provision each partition.

Key Characteristics of Secret Partitions

Programming Access:
- UDS_SEED and FIELD_ENTROPY partitions can only be programmed by the Caliptra Core.
- Secret partitions are buffered, meaning they are stored in registers and are erased (temporarily zeroized) if Caliptra-SS enters debug mode.
Locking Mechanism:
- Write access to a partition can be permanently locked when no further updates are required.
- To lock a partition, an integrity constant is calculated and programmed alongside the data for that partition.

Partition-Specific Behaviors

Life Cycle Partition

The life cycle partition remains active across all stages and cannot be locked.
This ensures that the device can transition back to the RMA state in case of unexpected failures during production.

Vendor Test Partition

The vendor test partition is used for FUSE programming smoke checks during manufacturing.
Unlike other partitions, ECC uncorrectable errors in this partition do not trigger fatal errors or alerts due to the nature of FUSE smoke checks, which may leave certain FUSE words in inconsistent states.

Locking the Validated Public Key Partition

During firmware authentication, the ROM validates the vendor public keys provided in the firmware payload. These keys, which support ECC, MLDSA, and LMS algorithms, are individually hashed and compared against stored fuse values (e.g., CPTRA_CORE_VENDOR_PK_HASH_n). Once a valid key is identified, the ROM locks that specific public key hash and all higher-order public key hash entries until the next cold reset. This ensures that the validated key’s fuse entry remains immutable. Importantly, the locking mechanism is applied only to the public key hashes. The associated revocation bits, which allow for runtime key revocation, remain unlocked. To support this, the fuse controller (FC) implements two distinct partitions:

PK Hash Partition
- Purpose:
  - Contains the CPTRA_CORE_VENDOR_PK_HASH[i] registers for i ranging from 1 to N.
  - Once a key is validated, the corresponding hash and all higher-order hashes are locked by MCU ROM, making them immutable until a cold reset.
- Layout & Details:
  - Partition Items: CPTRA_CORE_VENDOR_PK_HASH[i] where i ranges from 1 to N.
    - Default N: 1
    - Maximum N: 16
    - Size: N × 384 bits (each hash is 384-bit)
    - Programming:
      - The first key (i=1) is programmed during the manufacturing phase.
      - The remaining keys (if any, i.e., N–1) can be programmed during manufacturing or in the field (production).
  - Partition Item:
    - CPTRA_CORE_VENDOR_PK_HASH_VALID is used to indicate which of the N keys is valid. Therefore, the length is N to support N-bit hot-encoding.
PK Hash Revocation Partition
- Purpose: This partition stores runtime-updateable revocation bits and PQC type information.
- Layout & Details:
  - For each vendor public key (VENDOR_PK_HASH[i]), the partition contains:
    - ECC Revocation Bits: 4 bits (e.g., CPTRA_CORE_ECC_REVOCATION[i])
    - LMS Revocation Bits: 32 bits (e.g., CPTRA_CORE_LMS_REVOCATION[i])
    - MLDSA Revocation Bits: 4 bits (e.g., CPTRA_CORE_MLDSA_REVOCATION[i])
    - PQC Key Type Bits: 1-bit one-hot encoded selection (e.g., CPTRA_CORE_PQC_KEY_TYPE[i])
  - Attributes:
    - This partition is kept separate from the PK hash partition to allow for runtime updates even after the validated public key is locked.
Volatile Locking Mechanism

To ensure that the validated public key remains immutable once selected, the FC uses a volatile lock mechanism implemented via the new register otp_ctrl.VENDOR_PK_HASH_LOCK.
Once the ROM determines the valid public key (e.g., the 3rd key is selected), it locks the corresponding fuse entries in the PK hash partition.
The lock is applied by writing a specific value to otp_ctrl.VENDOR_PK_HASH_LOCK.
If the OCP L.O.C.K. is enabled, the same lock mechanism is also applied on CPTRA_SS_LOCK_HEK_PROD_X fuse patitions.
- Example:
```
// Lock the 3rd vendor public key hash and all higher order key hashes
write_register(otp_ctrl.VENDOR_PK_HASH_LOCK, 0xFFF2);
// This operation disables any further write updates to the validated public key fuse region.
```
- The ROM polls the STATUS register until the Direct Access Interface (DAI) returns to idle, confirming the completion of the lock operation. If any errors occur, appropriate error recovery measures are initiated.
- Once locked, the PK hash partition cannot be modified, ensuring that the validated public key remains unchanged, thereby preserving the secure boot chain.
- If there needs to be update or programming sequence in PK_HASH set, it needs to be in ROM execution time based on a valid request. Therefore, requires cold-reset.
- The PK hash revocation partition remains unlocked. This design allows the chip owner to update revocation bits and PQC type settings at runtime, enabling the dynamic revocation of keys without affecting the locked public key.

Hardware Integrity Checker

Once partitions are locked, the hardware integrity checker performs two primary integrity checks to ensure the consistency of the volatile buffer registers:

ECC Protection:
- All buffered partitions include additional ECC protection (8-bit ECC for each 64-bit block), which is monitored concurrently.
Digest Verification:
- The digest of each partition is recomputed at semi-random intervals and compared to the digest stored alongside the partition.

Purpose

These integrity checks verify whether the contents of the buffer registers remain consistent with the calculated digest. They do not verify the consistency between storage flops and the FUSE.

Notes

Zeroization of Secret Partitions: Secret partitions are temporarily zeroized when Caliptra-SS enters debug mode to ensure security.
Locking Requirement: After the device finishes provisioning and transitions into production, partitions that no longer require updates should be locked to prevent unauthorized modifications.
Further Information: For more information about the conditional states, please refer to OpenTitan open-source silicon Root of Trust (RoT) project.

General Guidance

Reset Considerations

It is important to note that values in OTP can be corrupted if a reset/zeroization occurs during a programming operation. This should be of minor concern for SW, however, since all partitions except for the LIFE_CYCLE partition are being provisioned in secure and controlled environments, and not in the field. The LIFE_CYCLE partition is the only partition that is modified in the field - but that partition is entirely owned by the life cycle controller and not by SW.

Programming Already Programmed Regions

OTP words cannot be programmed twice, and doing so may damage the memory array. Hence the OTP controller performs a blank check and returns an error if a write operation is issued to an already programmed location.

Caliptra Subsystem Life Cycle Controller

It is an overview of the architecture of the Life-Cycle Controller (LCC) Module for its use in the Caliptra Subsystem. The LCC is responsible for managing the life-cycle states of the system, ensuring secure transitions between states, and enforcing security policies.

Caliptra Subsystem, SOC Debug Architecture Interaction

Figure below shows the Debug Architecture of the Caliptra Subsystem and some important high-level signals routed towards SOC. The table in Key Components and Interfaces section shows all the signals that are available to SOC (outside of Caliptra Subsystem usage).

Figure: Caliptra Subsystem & SOC Debug Architecture Interaction Note: SoC Debug Architecture of the Caliptra Subsystem with LCC; the red dashed circles highlight the newly added blocks and signals.

The figure below shows the LCC state transition and Caliptra Subsystem enhancement on LCC state transitions. It illustrates the life cycle flow of Caliptra Subsystem.

Figure: Caliptra Subsystem Life Cycle Controller Summary

Note: Caliptra Subsystem life cycle flow. This flow shows legal state transitions in life cycle controller by excluding its invalid states for simplicity.

Caliptra Subsystem LCC State Definitions

Name	Encoding	Description
RAW	FUSE	This is the default state of the FUSE. During this state, no functions other than transition to TEST_UNLOCKED0 are available. The token authorizing the transition from RAW to TEST_UNLOCKED0 is a value that is secret global to all devices. This is known as the RAW_UNLOCK token.
TEST_LOCKED{N}	FUSE	TEST_LOCKED{N} states have identical functionality to RAW state and serve as a way for the Silicon Creator to protect devices in transit. It is not possible to provision FUSE root secrets during this state. This is enforced by hardware and is implementation defined. To progress from a TEST_LOCKED state to another TEST_UNLOCKED state, a TEST_UNLOCKED token is required.
TEST_UNLOCKED{N}	FUSE	Transition from RAW state using token stored in FUSE. This state is used for manufacturing and production testing. During this state: CLTAP (chip level TAPs) is enabled; Debug functions are enabled; DFT functions are enabled. It is expected that LCC tokens will be provisioned into FUSE during these states. Once provisioned, these tokens are no longer readable by software.
MANUF	FUSE	Transition from TEST_UNLOCKED state using token stored in FUSE. This is a mutually exclusive state to PROD and PROD_END. To enter this state, MANUF_TOKEN is required. This state is used for developing provisioning and mission mode. In this state, UDS and Field Entropy FUSE partitions can be provisioned. During this state: CLTAP (chip level TAPs) is enabled; Debug functions are enabled; DFT functions are disabled
PROD	FUSE	Transition from MANUF state using token stored in FUSE. PROD is a mutually exclusive state to MANUF and PROD_END. To enter this state, PROD_TOKEN is required. This state is used both for provisioning and mission mode. During this state: CLTAP is disabled; Debug functions are disabled; DFT functions are disabled; Caliptra Subsytem can grant SoC debug unlock flow if the conditions provided in “SoC Debug Flow and Architecture for Production Mode” section are satisfied. SoC debug unlock overwrites the signals and gives the following cases: CLTAP is enabled; Debug functions are enabled based on the defined debug policy; DFT is enabled but this DFT enable is called SOC_DFT_EN, which has less capabilities than DFT_EN granted in TEST_UNLOCKED.
PROD_END	FUSE	This state is identical in functionality to PROD, except the device is never allowed to transition to RMA state. To enter this state, a PROD_END token is required. Only transition to SCRAP mode is allowed.
RMA	FUSE	Transition from TEST_UNLOCKED / PROD / MANUF using token stored in FUSE. It is not possible to reach this state from PROD_END. If the RMA transition is requested, the request must follow the asserted RMA PPD pin. Without this pin, RMA request is discarded. See `cptra_ss_lc_Allow_RMA_or_SCRAP_on_PPD_i` in Caliptra Subsystem Integration Specification Document. When transitioning from PROD or MANUF, an RMA_UNLOCK token is required. When transitioning from TEST_UNLOCKED, no RMA_UNLOCK token is required. During this state: CLTAP is enabled; Debug functions are enabled; DFT functions are enabled
SCRAP	FUSE	Transition from any state. If the SCRAP transition is requested, the request must follow the asserted SCRAP PPD pin. Without this pin, SCRAP request is discarded. See `cptra_ss_lc_Allow_RMA_or_SCRAP_on_PPD_i` in Caliptra Subsystem Integration Specification Document. During SCRAP state the device is completely dead. All functions, including CPU execution are disabled. The only exception is the TAP of the life cycle controller which is always accessible so that the device state can be read out. No owner consent is required to transition to SCRAP. Note also, SCRAP is meant as an EOL manufacturing state. Transition to this state is always purposeful and persistent, it is NOT part of the device’s native security countermeasure to transition to this state.
INVALID	FUSE	Invalid is any combination of FUSE values that do not fall in the categories above. It is the “default” state of life cycle when no other conditions match. Functionally, INVALID is identical to SCRAP in that no functions are allowed and no transitions are allowed. A user is not able to explicitly transition into INVALID (unlike SCRAP), instead, INVALID is meant to cover in-field corruptions, failures or active attacks.

Note

The LCC performs state transitions in a forward-only manner. It begins in the RAW state and follows the sequence: TEST_UNLOCKED and TEST_LOCKED, then MANUF, then PROD, and finally either PROD_END or RMA. After transitioning to TEST_UNLOCKED, the LCC can branch to any of the following states: MANUF, PROD, PROD_END, or RMA. However, once the LCC transitions to PROD, PROD_END, or RMA, it cannot return to the MANUF state. Additionally, note that the LCC cannot branch to RMA from PROD_END.

DFT & DFD Life-cycle States

In addition to the decoding signals of the Life-Cycle Controller (LCC) proposed in the OpenTitan open-source silicon Root of Trust (RoT) project, we introduce new signals: SOC_DFT_EN as SOC_HW_DEBUG_EN. These signals are critical for managing the test and debug interfaces within the Caliptra Subsystem, as well as at the broader SoC level.

While this architecture document explains how the Caliptra Subsystem provides DFT and DFD mechanisms through the DFT_EN, SOC_HW_DEBUG_EN, and SOC_DFT_EN signals, it also offers greater flexibility by supporting various SoC debugging options through the broader SoC debug infrastructure. The architecture does not constrain the SoC’s flexibility with the core security states of Caliptra and LCC states. We establish a set of clear guidelines for how the Caliptra Subsystem transitions through the unprovisioned, manufacturing, and production phases, ensuring security. However, this architecture remains flexible, offering multiple levels of debugging options in production debug mode. Level 0 is designated for debugging the Caliptra Subsystem itself, while higher levels can be interpreted and customized by the SoC designer to implement additional debugging features. For instance, if the SoC designer wishes to include extra DFT and DFD capabilities, they can utilize one of the debug levels provided during production debug mode and expand its functionality accordingly. For more details, see “SoC Debug Flow and Architecture for Production Mode” Section and “Masking Logic for Debugging Features in Production Debug Mode” Section.

The DFT_EN signal is designed to control the scan capabilities of both the Caliptra Subsystem and the SoC. When DFT_EN is set to HIGH, it enables the scan chains and other Design for Testability (DFT) features across the system, allowing for thorough testing of the chip. This signal is already provided by the existing LCC module, ensuring compatibility with current test structures. However, the SoC integrator has the flexibility to assign additional functionality to one of the debugging options provided by the debug level signals during production debug mode. For example, at the SoC level, an integrator may choose to use one of these levels to enable broader SoC DFT features, allowing for system-level testing while maintaining Caliptra's protection. To enable SoC DFT signal, SoC needs to set SOC_DFT_EN signal HIGH by using the infrastructure defined in “Masking Logic for Debugging Features in Production Debug Mode” Section. Note that SOC_DFT_EN has a different capabilities than DFT_EN signal. DFT_EN is contolled by LCC, while SOC_DFT_EN is controlled by MCI.

The SOC_HW_DEBUG_EN signal is a new addition that governs the availability of the Chip-level TAP (CLTAP). CLTAP provides a hardware debug interface at the SoC level, and it is accessible when SOC_HW_DEBUG_EN is set to HIGH. For further details on how this signal integrates with the overall system, refer to the “TAP Pin Muxing” Section of this document.

In the manufacturing phase, the Caliptra Subsystem asserts SOC_HW_DEBUG_EN high, with the signal being controlled by the LCC. In PROD mode, this signal is low. However, the SoC integrator has the flexibility to enable CLTAP during production debug mode by incorporating additional logic, such as an OR gate, to override the SOC_HW_DEBUG_EN signal, like DFT_EN. This architecture provides a mask register that allows SoC to program/configure this overriding mechanism at integration time or using MCU ROM. This allows the SoC to maintain control over hardware debug access while preserving the intended security protections in production.

Table: LCC State and State Decoder output ports

LCC State and State Decoder Output Ports

LCC State\Decoder Output	DFT_EN	SOC_DFT_EN	SOC_HW_DEBUG_EN
RAW	Low	Low	Low
TEST_LOCKED	Low	Low	Low
TEST_UNLOCKED	High	High	High
MANUF*	Low	TOKEN - CONDITIONED**	High
PROD*	Low	TOKEN - CONDITIONED**	TOKEN - CONDITIONED**
PROD_END	Low	Low	Low
PROD_END*	Low	TOKEN - CONDITIONED**	TOKEN - CONDITIONED**
RMA	High***	High	High
SCRAP	Low	Low	Low
INVALID	Low	Low	Low
POST_TRANSITION	Low	Low	Low

*: Caliptra can enter debug mode and update these signals even though LCC is in MANUF or PROD, PROD_END states. This case is explained in “How does Caliptra Subsystem enable manufacturing debug mode?” and “SoC Debug Flow and Architecture for Production Mode”.

**: SOC_DFT_EN and SOC_HW_DEBUG_EN can be high if Caliptra SS grants debug mode (either manufacturing or production). This case is explained in “How does Caliptra Subsystem enable manufacturing debug mode?” and “SoC Debug Flow and Architecture for Production Mode”. SOC_HW_DEBUG_EN is set high to open CLTAP and SOC_DFT_EN enables DFT by SoC design support. However, this condition also needs to go through the flow described in “SoC Debug Flow and Architecture for Production Mode”. Caliptra Subsystem state should be set to either the manufacturing mode debug unlock or Level 0 of the production debug unlock.

***: RMA state enables DFT_EN but Caliptra Core enters the debug mode when LCC enters RMA state. Thus, Caliptra Core clears UDS and Field Entropy secrets.

TAP Pin Muxing

The LCC includes a TAP interface, which operates on its own dedicated clock and is used for injecting tokens into the LCC. Notably, the LCC TAP interface remains accessible in all life cycle states, providing a consistent entry point for test and debug operations. This TAP interface can be driven by either the TAP GPIO pins or internal chip-level wires, depending on the system's current configuration.

Figure: Caliptra Subsystem Life Cycle Controller Summary Note: Above figure of TAP pin muxing block diagram with a conceptual representation. SOCs may implement this in their own way

SOC logic incorporates the TAP pin muxing to provide the integration support and manage the connection between the TAP GPIO pins and the Chip-Level TAP (CLTAP). As illustrated in figure above, this muxing logic determines the source that drives the LCC TAP interface. The selection between these two sources is controlled by the SOC_HW_DEBUG_EN signal. When SOC_HW_DEBUG_EN is set to high, control is handed over to the CLTAP, allowing for chip-level debug access through the TAP GPIO pins. Conversely, when SOC_HW_DEBUG_EN is low, the TAP GPIO pins take control, enabling external access to the LCC TAP interface.

LCC State and State Decoder Output Ports Table outlines the specific LCC states that enable the SOC_HW_DEBUG_EN signal. These states include TEST_UNLOCK, MANUF, PROD (debug unlocked version only), and RMA. In these states, the LCC allows internal chip-level debug access via CLTAP, thereby facilitating advanced debugging capabilities. This muxing approach ensures that the TAP interface is appropriately secured, and that access is granted only under specific conditions, aligning with the overall security and functional requirements of the Caliptra Subsystem. Note: It is important to note that CLTAP provides access to the TAP interfaces of the LCC, MCU, or Caliptra Core. This functionality is managed by SoC logic, not by Caliptra-SS. Consequently, the SoC integration effort should ideally include an additional mux after CTAP to route the connection to one of the following: the LCC TAP, MCU TAP, or Caliptra Core TAP.

TAP pin muxing also enables routing to Caliptra TAP. This selection happens when DEBUG_INTENT_STRAP is high. This selection is done through the GPIO and indicates that Caliptra will enter debug mode if the secret tokens are provided. Caliptra Subsystem has two debug modes: manufacturing debug and production debug. Entering these debug flows are explained in the following sections: How does Caliptra Subsystem enable manufacturing debug mode?, SoC Debug Flow and Architecture for Production Mode and Masking Logic for Debugging Features in Production Debug Mode

Note: The Caliptra TAP can run exact flow with AXI, targeting the mailbox and SOC provides that interface to platform.

How does Caliptra Subsystem enable manufacturing debug mode?

The following figure illustrates how Caliptra Subsystem enters the manufacturing debug mode. To enter this mode, LCC should be in MANUF state. While being in manufacturing debug mode, LCC does not change its state from MANUF to any other state. During the MANUF state, Caliptra Subsystem can enable manufacturing debug flow by following steps:

Figure: Caliptra Subsystem Manuf Debug Life Cycle View Note: The flow diagram on the right side shows the LCC states (grey boxes) and their transitions, while the flow diagram on the left illustrates Caliptra SS’s enhancements to the LCC for the manufacturing phase. Specifically, the flow on the left depicts the routine for entering manufacturing debug mode.

Flow Explanation

(Platform) Assert BootFSMBrk : Temporarily halting the Caliptra HW bootfsm boot process to allow for secure operations like token injection and verification.
(Platform) Assert DEBUG_INTENT_STRAP: If Caliptra core HW samples this pin as high and sees that LCC is in MANUF mode, it prepares itself for entering debug mode. Once the DEBUG_INTENT_STRAP is detected, Caliptra HW immediately wipes out its secret assets, including the Unique Device Secret (UDS) and Field entropy, ensuring that no sensitive data remains accessible. If this Pin is not high, Caliptra continues always in non-debug mode without taking any further action listed with the following states.
(Platform over TAP) MANUF_DEBUG_UNLOCK_REQ: The system intends to be in debug mode for manufacturing services.
(Platform over TAP) Write to Boot Continue: Resuming the boot process after halting it with BootFSMBrk.
ROM reads MANUF_DEBUG_UNLOCK_REQ at optimal time for ROM and clears mailbox lock and asserts MANUF_DEBUG_UNLOCK_IN_PROGRESS.
Platform over TAP requests Caliptra mailbox lock. If lock is obtained, then platform over TAP writes to TAP mailbox to inject Token via TAP Register Write: Enabling the injection of a token through TAP and writing to a specific register.
ROM Executes Hash Hashing: Calculates the hash value of the injected token using a SHA-512 hash core. Before starting this operation.
Token Comparison: A constant-time comparison between the authentication values of injected token and the FUSE content.
ROM Drives MANUF_DEBUG_UNLOCK Signal: The ROM writes to a register that controls the MANUF_DEBUG_UNLOCK signal based on the result of the token verification.

Note: The manufacturing debug flow relies on the hash comparison hardness rather than an authentication check provided with an asymmetric cryptography scheme. However, the following sections show that production debug flow relies on asymmetric cryptography scheme hardness. The reason behind this choice is that the manufacturing phase is the early phase of the delivery, and this phase is entered in an authorized entity’s facility. Therefore, this architecture keeps the manufacturing phase simpler.

Production Debug Unlock Architecture

The Caliptra Subsystem includes SoC debugger logic that supports Caliptra’s production debug mode. This debugger logic extends the capabilities of the Lifecycle Controller (LCC) by providing a production debug mode architecture that the LCC does not inherently support, except in the RMA state. This architecture manages the initiation and handling of the production debug mode separately from the LCC's lifecycle states.

The process of enabling production debug mode begins when the DEBUG_INTENT_STRAP pin is asserted high via the SoC’s GPIO. This pin signals Caliptra to start the debug mode when the LCC is in the PROD and PROD_END states. Before the debug unlock flow, the MCU reads all hashed public keys from the fuse macros and writes them to the SS_PROD_DEBUG_UNLOCK_AUTH_PK_HASH_REG_BANK registers. Additionally, the MCU sets the number of public keys used for production debug unlock by writing to the SS_NUM_OF_PROD_DEBUG_UNLOCK_AUTH_PK_HASHES register. The value DEBUG_AUTH_PK_HASH_REG_BANK_OFFSET represents an address offset, while NUM_OF_DEBUG_AUTH_PK_HASHES defines how many public keys are available for reading. These two values establish the debug policy depth for different debugging levels.

Overview of Debug Unlock Initiation

The process begins when the platform sets three conditions:

The DEBUG_INTENT field in the SS_DEBUG_INTENT register.
The PROD_DEBUG_UNLOCK_REQ bit in the SS_DBG_MANUF_SERVICE_REG_REQ register.
The CPTRA_BOOT_GO allows Caliptra Core to continue its execution. On reset, the Caliptra ROM checks these two signals. If both are asserted, the ROM begins the production debug unlock process. Upon detecting a valid debug intent:
Caliptra hardware erases its secret assets, including the Unique Device Secret (UDS) and Field Entropy, before exposing any debug interfaces, ensuring sensitive data is irreversibly destroyed.
Caliptra ROM sets the TAP_MAILBOX_AVAILABLE and PROD_DBG_UNLOCK_IN_PROGRESS bits in the SS_DBG_MANUF_SERVICE_REG_RSP register.

Note: Similar to the manufacturing debug flow, BootFSMBrk must be asserted to halt Caliptra ROM execution. Otherwise, the ROM may advance past the debug request before PROD_DEBUG_UNLOCK_REQ is populated. BootFSMBrk is a prerequisite for entering the debug flow ONLY if Caliptra core ROM needs to be debugged; for run-time injection of prod debug unlock token, setting BootFSMBrk is not required.

Secure Debug Unlock Protocol

The production debug unlock flow uses a challenge-response authentication model involving public key verification and hybrid cryptography (ECC and MLDSA). The flow includes the following steps:
- AUTH_DEBUG_UNLOCK_REQ Command: Caliptra ROM polls the Mailbox interface, awaiting an AUTH_DEBUG_UNLOCK_REQ from the platform.
- The request payload includes:

Field	Size (bytes)	Description
Length	4	Must be 2 DWORDs.
Unlock Level	1	Requested unlock level.
Reserved	3	Reserved.

If the payload is invalid, Caliptra ROM:
- Sets the PROD_DBG_UNLOCK_FAIL bit.
- Clears the PROD_DBG_UNLOCK_IN_PROGRESS bit.
- Exits the debug unlock process.
Upon successful initial validation, Caliptra ROM sends back an AUTH_DEBUG_UNLOCK_CHALLENGE payload:

Field	Size (bytes)	Description
Length	4	Should be 21 DWORDs.
Unique Device Identifier	32	Caliptra device identifier.
Challenge	48	Randomly generated nonce.

The platform signs the challenge data and sends an AUTH_DEBUG_UNLOCK_TOKEN:

Field	Size (bytes)	Description
Length	4	Should be 0x753 DWORDs.
Unique Device Identifier	32	Echoed from challenge.
Unlock Level	1	Echoed from initial request.
Reserved	3	Reserved.
Challenge	48	Echoed from challenge.
ECC Public Key	96	P-384 public key.
MLDSA Public Key	2592	MLDSA-87 public key.
ECC Signature	96	Signature of challenge message.
MLDSA Signature	4628	Signature of challenge message.

Finally, Caliptra ROM reads the expected SHA2-384 public key hash from the corresponding register by using the following equation:
- SS_PROD_DEBUG_UNLOCK_AUTH_PK_HASH_REG_BANK_OFFSET + ((Unlock Level - 1) * 48 bytes)
If hash of AUTH_DEBUG_UNLOCK_CHALLENGE's MLDSA and ECC public keys match with the read value from SS_PROD_DEBUG_UNLOCK_AUTH_PK_HASH_REG_BANK_OFFSET, ROM uses these MLDSA and ECC public keys to perform the authentication.
Upon successful validation:
- Sets the PROD_DBG_UNLOCK_SUCCESS bit.
- Writes the CALIPTRA_SS_SOC_DEBUG_UNLOCK_LEVEL register granted debug level with a one-hot encoding result (1 << (Unlock Level - 1)).
- Clears the TAP_MAILBOX_AVAILABLE bit.
- Clears the PROD_DBG_UNLOCK_IN_PROGRESS bit.
- Exits the debug unlock process.

Granting Production Debug Mode:

If authentication succeeds, Caliptra ROM does not immediately grant full production debug mode. Instead, the ROM sets the appropriate "debug level" signal, which corresponds to the type of debug access being requested.
Caliptra ROM writes CALIPTRA_SS_SOC_DEBUG_UNLOCK_LEVEL register, which will be wired to the specific debug enable signal. This signal is part of an N-wide signal that is mapped to the payload encoding received during the debug request. N is defined by NUM_OF_DEBUG_AUTH_PK_HASHES. The default version of N is 8. The payload encoding can either be one-hot encoded or a general encoded format, and this signal is passed to the SoC to allow it to make the final decision about the level of debug access that should be granted. In Caliptra’s subsystem-specific implementation, the logic is configured to handle one-hot encoding for these 8 bits. The level 0 bit is routed to both Caliptra and the MCU TAP interface, allowing them to unlock based on this level of debug access. This granular approach ensures that the system can selectively unlock different levels of debugging capability, depending on the payload and the authorization level provided by the debugger.

Granting Production Debug Mode with Caliptra Runtime FW: Although the flow above describes ROM-based authentication, the same challenge–response mechanism may be executed by Caliptra Runtime Firmware. In this case, RT FW performs the challenge-response authentication steps via mailbox commands, which will be used to update the debug unlock level. The DEBUG_INTENT_STRAP must still be asserted high before Caliptra subsystem is out of reset. This ensures that even RT-based debug enablement remains gated by hardware intent and cannot be triggered purely through software.

Masking Logic for Debugging Features in Production Debug Mode (MCI)

In the production debug mode, the SoC can enable certain debugging features—such as DFT_EN and SOC_HW_DEBUG_EN—using a masking mechanism implemented within the Manufacturer Control Interface (MCI). This masking infrastructure allows the SoC to selectively control debug features that are normally gated by Caliptra’s internal signals. The masking logic functions as a set of registers, implemented in the MCI, that can be written by the SoC to override or enable specific debugging functionalities in production debug mode. The masking registers in the MCI act as an OR gate with the existing debug signals. For instance, if DFT_EN is controlled by Caliptra, the SoC can assert the corresponding mask register to enable Design for Test (DFT) capabilities in the SoC, even if Caliptra has not explicitly enabled it. Similarly, the SOC_HW_DEBUG_EN signal can be masked through the MCI registers, giving the SoC the flexibility to unlock TAP interfaces and provide the required debugging in production.

Figure: Caliptra Subsystem Infrastructure for SOC flexibility to override various debug signals

This mechanism is only authorized when both the LCC and Caliptra core are in the PROD state and operating in production debug mode. The masking logic ensures that these features are enabled securely, in line with the production debug flow described in the "SoC Debug Flow and Architecture for Production Mode" section. By leveraging the MCI’s masking infrastructure, the SoC integrator has greater flexibility to implement custom debugging options during production without compromising the security framework established by Caliptra.

**Note: Unlike the production state, the manufacturing state supports only a single debug level. Although it uses the same masking register to override DFT_EN, only the register’s least significant bit is used in manufacturing debug mode.

LCC Interpretation for Caliptra “Core” Security States

Caliptra Core has five security states as given with the figure below (Copied from Caliptra core specification). Three of these states enable debugging with different features, while two of these states are in non-debug mode. Caliptra Subsystem implements gasket logic to translate the LCC states to Caliptra “Core” security states.

Figure: Caliptra Core Security States

This translation is essential for ensuring that the system behaves correctly according to its current lifecycle stage, whether it is in a development phase, production, or end-of-life states. The LCC provides specific decoding signals—DFT_EN, SOC_DFT_EN, SOC_HW_DEBUG_EN—that accommodates the debug capabilities and security states of the Caliptra Core. Depending on the values of these signals, the Caliptra Core transitions between different security states as follows:

Non-Debug Mode: This state is enforced when the LCC is in RAW, TEST_LOCKED, SCRAP, INVALID, or POST_TRANSITION states. In these states, the DFT_EN, SOC_DFT_EN, SOC_HW_DEBUG_EN signals are all low, ensuring that no debug functionality is available. Caliptra remains in a secure, non-debug state, with no access to debugging interfaces.

Unprovisioned Debug Mode: When the LCC is in the TEST_UNLOCKED state, the DFT_EN, SOC_DFT_EN, SOC_HW_DEBUG_EN signals are all set high, enabling debug functionality. In this mode, the Caliptra Core allows extensive debugging capabilities, which is typically used during early development and bring-up phases.

Manufacturing Non-Debug Mode: This state occurs when the LCC is in the MANUF state, with SOC_HW_DEBUG_EN high and DFT_EN and SOC_DFT_EN low. In this state, the secrets have been programmed into the system, and the Caliptra can generate CSR (Certificate Signing Request) upon request. However, it remains in a secure, non-debug mode to prevent reading secrets through the debugging interfaces.

Manufacturing Debug Mode: Also occurring in the MANUF state, this mode is enabled when SOC_HW_DEBUG_EN is high. Here, the Caliptra Core provides debugging capabilities while maintaining security measures suitable for manufacturing environments. In this state, DFT_EN is low. However, SOC_DFT_EN can be set high if LSB of MCI_REG_SOC_DFT_EN_0 is set to high in MANUF debug state MCI-LCC-Signal-Masking.

Production Non-Debug Mode: This state is active when the LCC is in the PROD or PROD_END states, with all debug signals (DFT_EN, SOC_HW_DEBUG_EN) set to low. The Caliptra Core operates in a secure mode with no debug access, suitable for fully deployed production environments.

Production Debug Mode: This state is active when the LCC is in the PROD or PROD_END states, with debug DFT_EN, SOC_HW_DEBUG_EN set to low. Caliptra Core provides debugging capabilities while maintaining security measures suitable for manufacturing environments. However, SOC_DFT_EN and SOC_HW_DEBUG_EN can be set high with MCI masking registers MCI-LCC-Signal-Masking.

Production Debug Mode in RMA: In the RMA state, all debug signals are set high, allowing full debugging access. This state is typically used for end-of-life scenarios where detailed inspection of the system's operation is required.

The table below summarizes the relationship between the LCC state, the decoder output signals, and the resulting Caliptra “Core” security state:

Table: LCC state translation to Caliptra "Core" security states

LCC State vs Decoder Output	DFT_EN	SOC_DFT_EN	SOC_HW_DEBUG_EN	Caliptra “Core” Security States
RAW	Low	Low	Low	Prod Non-Debug
TEST_LOCKED	Low	Low	Low	Prod Non-Debug
TEST_UNLOCKED	High	High	High	Unprovisioned Debug
MANUF	Low	Low	High	Manuf Non-Debug
MANUF*	Low	High**	High	Manuf Debug
PROD	Low	Low	Low	Prod Non-Debug
PROD*	Low	High**	High**	Prod Debug
PROD_END	Low	Low	Low	Prod Non-Debug
PROD_END*	Low	High**	High**	Prod Debug
RMA	High	High	High	Prod Debug
SCRAP	Low	Low	Low	Prod Non-Debug
INVALID	Low	Low	Low	Prod Non-Debug

Note: In RAW, TEST_LOCKED, SCRAP and INVALID states, Caliptra “Core” is not brought out of reset. *: These states are Caliptra SS’s extension to LCC. Although the LCC is in either MANUF or PROD, PROD_END states, Caliptra core can grant debug mode through the logics explained in “How does Caliptra Subsystem enable manufacturing debug mode?” and “SoC Debug Flow and Architecture for Production Mode”. **: SOC_HW_DEBUG_EN and DFT_EN can be overridden by SoC support in debug mode of MANUF and PROD, PROD_END states.

Exception: Non-Volatile Debugging Infrastructure and Initial RAW State Operations

The Caliptra Subsystem features a non-volatile debugging infrastructure that allows the SoC integrator to utilize a dedicated SRAM for early-stage debugging during the VolatileUnlock state. This SRAM provides a means to store executable content for the MCU, enabling early manufacturing debug operations.

It is important to note that the VolatileUnlock state is not a standard LCC state but rather a temporary state. Unlike other LCC states, the LCC can transition to this state without requiring a power cycle, provided the necessary global VolatileUnlock token is passed. This token is unique in that it is not stored in the FUSE partition but is instead a global netlist secret.

Once in the VolatileUnlock state, the MCU can execute instructions stored in the SRAM, which can be initialized through a backdoor mechanism. This capability allows for basic FUSE tests and calibration operations during early debugging. However, the VolatileUnlock state is inherently unstable and temporary—if a reset is applied or the Caliptra Subsystem undergoes a power cycle, the LCC will return to the RAW state.

LCC RAW Unlock Token Generation & Setting

The hashed RAW unlock token is stored as a netlist constant. Its value is determined by the cptra_ss_raw_unlock_token_hashed_i input of caliptra_ss_top. Every integrator must set the hashed token to a unique value. tools/scripts/lc_ctrl_script/gen_lc_ctrl_token.py can be used to generate the hashed token. The unhashed RAW unlock token is a secret that must be obtained from a cryptographically secure random number generator. The aforementioned tool accepts an unhashed token as input or, if omitted, generates an unhashed token using Python's secrets module.

The hashed RAW unlock token must be applied to the cptra_ss_raw_unlock_token_hashed_i input of caliptra_ss_top. It's also required in SW that performs a volatile RAW unlock.

The unhashed RAW unlock token is required in SW that performs a non-volatile RAW unlock.

SOC LCC Interface usage & requirements

The interaction between the SoC and the LCC within the Caliptra Subsystem is pivotal for maintaining the security and functionality of the overall system. This section outlines the specific usage and requirements for interfacing with the LCC from the SoC perspective.

SOC_HW_DEBUG_EN Utilization: The SOC_HW_DEBUG_EN signal plays a crucial role in controlling access to the Chip-Level TAP (CLTAP). When SOC_HW_DEBUG_EN is asserted high, it enables the exposure of registers to the TAP interface that are deemed secure for access during debugging. This is particularly important when CLTAP is open, as it allows authorized debugging operations while ensuring that sensitive or secure information remains protected.

LCC Outputs for Security/Debug Purposes: Beyond the primary debug controls, all other LCC outputs, as listed in the signal table below, are available for use by the SoC for any security or debugging purposes. These outputs provide the SoC with additional control signals that can be leveraged to enhance system security, monitor debug operations, or implement custom security features.

Integration with Clock/Voltage Monitoring Logic: If the SoC includes clock or voltage monitoring logic, it is recommended that these components be connected to the LCC's escalation interface. By integrating with the LCC, the SoC can ensure that any detected anomalies, such as voltage fluctuations or clock inconsistencies, trigger appropriate secure transitions as defined in this document. This connection enhances the overall security posture by enabling the LCC to respond dynamically to potential threats or system irregularities.

These requirements ensure that the SoC and LCC work in tandem to maintain a secure environment, particularly during debugging and system monitoring. By adhering to these guidelines, the SoC can leverage the LCC’s capabilities to protect sensitive operations and enforce security policies across the system.

LCC Module: Summarized Theory of operation

The LCC is designed to handle the various life-cycle states of the device, from initial provisioning through manufacturing to production and eventual decommissioning (RMA). It provides mechanisms for state transitions, secure key management, and debug control, ensuring that the device operates securely throughout its lifecycle. For more information, please refer to the Life-cycle controller documentation. While the LCC is reused from OpenTitan, Caliptra Subsystem’s security & debug architecture has some differences. Therefore, Subsystem implements the functions required to meet Caliptra specific requirements.

LCC has the same power up sequence as described in Life cycle controller documentation of OpenTitan open-source silicon Root of Trust (RoT) project. After completing the power up sequence, the LCC enters the normal operation routine. During this phase, its output remains static unless specifically requested to change. The LCC accepts life-cycle transition change requests from its TAP interface (TAP Pin Muxing). There are two types of state transitions: (i) unconditional transitions and (ii) conditional transitions.

For unconditional transitions, the LCC advances the state by requesting an FUSE update to the FUSE controller. Once the programming is confirmed, the life cycle controller reports a success to the requesting agent and waits for the device to reboot.

For conditional transitions, the LCC can also branch different states (TEST_UNLOCK, MANUF, PROD, PROD_EN, RMA) based on the received token through the TAP interface and compared the received tokens against the ones stored in FUSE . This branching is called conditional transitions. For more information about the conditional states, please refer to OpenTitan open-source silicon Root of Trust (RoT) project.

Notes:

Some tokens are hardcoded design constants (specifically for RAW to TEST_UNLOCK), while others are stored in FUSE.
Conditional transitions will only be allowed if the FUSE partition holding the corresponding token has been provisioned and locked.
For transition counter limits and token hashing mechanism, please refer to OpenTitan open-source silicon Root of Trust (RoT) project [1].
The LCC enters the post transition handling routine after completing conditional and unconditional transitions. During this routine, the LCC disables all of its decoded outputs and puts the system in an inert state.

Manufacturer Control Unit (MCU)

MCU is an instance of VeeR EL2 core. The following features are enabled on MCU - iCache, dedicated DCCM, AXI interfaces with seperate AXI USER ID to ROM and MCI, bit manipulation extensions that we have for Caliptra core (Zba, Zbb, Zbc, Zbs) and PMP + SMEPMP with max PMP entries. Please see Caliptra subsystem integration spec for the configuration options available at subsystem level.

If the MCU VeeR instance must be regenerated with new configuration, a shell script is available in the Caliptra Subsystem repository. The script is located at tools/scripts/veer_build_command.sh.

Manufacturer Control Interface (MCI)

Overview

The Manufacturer Control Interface (MCI) is a critical hardware block designed to supplement the Manufacturer Control Unit (MCU) within a System on Chip (SoC). The primary functions of the MCI include providing an SRAM bank, facilitating restricted communication through a mailbox from external entities, and managing a bank of Control/Status Registers (CSRs). Additionally, the MCI incorporates a Watchdog Timer and a Boot Sequencing Finite State Machine (FSM) to manage timing and control during the SoC boot sequence after power application. This boot sequence encompasses reset deassertion, initialization of the Fuse Controller, initialization of the Lifecycle Controller, and enabling the JTAG block for debugging and manufacturing processes.

The following diagram illustrates the internal components of the MCI.

MCI Feature Descriptions

Control/Status Registers (CSRs)

The Control/Status Registers (CSRs) within the MCI are designed to provide critical control and status monitoring functions for the SoC. These registers include configuration settings, status indicators, and control bits that allow communication and management of the various operations of the MCI. The CSR bank is accessible via the AXI interface and is mapped into the memory space to facilitate straightforward access and manipulation.

MCI Reg Spec

MCI CSR Access Restrictions

Certain registers within the CSR bank have write access restrictions based off of:

AXI User
Lock bits (SS_CONFIG_DONE, CAP_LOCK, etc.)

The privilaged users for the MCI CSRs are:

MCU
MCI SOC Config User (MSCU)
MCU SRAM Config User (MSRCU)

All of these AXI Users come from straps and are not modifiable by SW. MCU is given the highest level of access and is expected to configure MCI registers and lock the configuration with various SS_CONFIG_DONE and LOCK bits. It also has access to certain functionalality like timers that are needed by the SOC but are critical for MCU functionality.

The MSCU is meant as a secondary config agent if the MCU is unable to configure MCI. Example when in the no ROM config it is expected the MCSCU can configure and lock down the MCI configuration. MSCU can be disabled by setting the strap to 0x0. For debug the MSCU strap can be set to all 1s meaning every access will give this level of privilege. The MCRCU populates the MCU FW update in MCU SRAM. There are a few registers within the MCI register bank it has special access to for facilitating the FW update. The registers can be split up into a few different categories:

Write restrictions	Description
MCU Only	These registers are only meant for MCU to have access. There is no reason for SOC or the MCI SOC Config User to access the. Example is the MTIMER
MCU or MSCU	Access restricted to trusted agents but not locked. Example:RESET_REQUEST for MCU.
MCU or MSRCU	Access restricted to trusted agents but not locked. Example:RESET_REASON for MCU.
MCU or MSCU and CONFIG locked	Locked configuration by MCU ROM/MSCU and configured after each warm reset
Sticky MCU or MSCU and CONFIG locked	Locked configuration by MCU ROM/MSCU and configured after each cold reset
Locked by SS_CONFIG_DONE_STICKY	Configuration once per cold reset.
Locked by SS_CONFIG_DONE	Configuration once per warm reset.
MCU or MSCU until CAP_LOCK	Configured by a trusted agent to show HW/FW capabilieds then locked until next warm reset
MBOX_USER_LOCK	Mailbox specific configuration locked by it's own LOCK bit. Configured afer each arem reset.

MCI Straps

All MCI straps shall be static before mci_rst_b is deasserted. Some straps have further restrictions as described below.

MCI has the following types of straps:

Strap Type	Sampled or Direct Use	Description
Non-configurable Direct	Direct	Used directly by MCI and not sampled at all. These shall be constant non-configurable inputs to CSS/MCI. Inside MCI these are not overridable by SW.
Non-configurable Sampled	Sampled*	Sampled once per cold boot and not overridable by SW
Configurable Sampled	Sampled**	Sampled once per warm boot and SW can override via MCI Register Bank until SS_CONFIG_DONE is set.

*NOTE: Strap sampling occurs when mci_rst_b is deasserted and is typically performed once per cold boot. This process is controlled by the SS_CONFIG_DONE_STICKY register; when set, sampling is skipped. If a warm reset happens before SS_CONFIG_DONE_STICKY is set, the straps will be sampled again, although this is not the usual behavior.

**NOTE: Strap sampling occurs when mci_rst_b is deasserted.

Strap Name	Strap Type	Description
`strap_mcu_lsu_axi_user`	Non-configurable Direct	MCU Load Store Unit AXI User. Given Special Access within MCI.
`strap_mcu_ifu_axi_user`	Non-configurable Direct	MCU Instruction Fetch Unit AXI User. given special access within MCI.
`strap_mcu_sram_config_axi_user`	Non-configurable Direct	MCU SRAM Config agent who is given special access to MCU SRAM Execution region to load FW image. Typically set to Caliptra's AXI User.
`strap_mci_soc_config_axi_user`	Non-configurable Direct	MCI SOC Config User (MSCU). AXI agent with MCI configuration access.
`strap_mcu_reset_vector`	Configurable Sampled	Default MCU reset vector.
`ss_debug_intent`	Non-configurable Sampled	Provides some debug access to MCI. Show the intent to put the part in a debug unlocked state. Although not writable by SW via AXI. This is writable via DMI.

Subsystem Boot Finite State Machine (CSS-BootFSM)

The Boot Sequencer FSM is responsible for the orderly and controlled boot process of the Caliptra Subsystem. This state machine ensures that all necessary initialization steps are completed in the correct sequence after power application. The boot sequence includes MCU and Caliptra Reset deassertions, Fuse Controller Initialization, and Lifecycle Controller Initialization.

The following boot flow explains the Caliptra subsystem bootFSM sequence.

Note: SOC may have other HW FSM steps that were done before Caliptra (CSS) is brought out of reset such as locking a PLL or calibrating a CRO, setting up GPIOs, test logic bring up etc. using SOC HW FSM.

SOC asserts Caliptra SS powergood and desserts Caliptra SS reset to MCI

a. SOC may choose to connect the same signals to the AXI fabric or bring it out of reset using a different signals. But the requirement is that before MCU is out of reset, fabric should be operational.
CSS-BootFSM will sample straps in MCI and will drive its outputs to reset defaults.

c. Note: In allowed LCC states, MCU TAP will be available when MCI is brought out of reset. Uncore registers in MCI will be available, but Core registers within MCU will only be available when MCU reset is deasserted.
CSS-BootFSM will go through Caliptra Subsystem Fuse controller (CSS FC) Init Sequence Init Sequence/handshakes
CSS-BootFSM will go through Caliptra Subsystem Life Cycle Controller (CSS LCC) Init Sequence/handshakes

a. SOC Note: Note that LCC shall start on an SOC generated internal clock to prevent clock stretch attacks

b. SOC Note: If the life cycle state is in RAW, TEST* or RMA, and if TRANSITION_CTRL.EXT_CLOCK_EN is set to one, the CLK_BYP_REQ signal is asserted in order to switch the main system clock to an external clock signal. This functionality is needed in certain life cycle states where the SOC internal clock source may not be fully calibrated yet, since the FUSE macro requires a stable clock frequency in order to reliably program the fuse array. Note that the TRANSITION_CTRL.EXT_CLOCK_EN register can only be set to one if the transition interface has been claimed via the CLAIM_TRANSITION_IF mutex. This function is not available in production life cycle states.
If MCU-No-ROM-Config strap is not set, then CSS-BootFSM will bring MCU out of reset and MCU ROM will start executing.

a. Note: MCU ROM may be used by some SOCs for doing additional SOC specific initializations.An example of such a SoC construction is MCI, MCU, CSS Fabric are running on external clock initially. MCU brings up PLL, some GPIO peripherals, does I3C init sequence etc and then performs clock switch to internal PLL clock domain so that the fabric is running on the internal clock domain before secrets are read on it from the fuse controller.
If MCU-No-ROM-Config is not set, MCU ROM will bring Caliptra out of reset by writing a MCI register (CPTRA_BOOT_GO)
If MCU-No-ROM-Config is set, CSS-BootFSM waits for a Caliptra GO write from SOC to bring Caliptra out of reset.

a. Note: MCU Reset Vector will be strapped to the MCU SRAM executable location at integration time.

b. Note: MCI will allow "MCI SOC CONFIG" AXI User to configure MCI registers MCU typically configures.

b. Note: MCI will allow any AXI User to write into SRAM if the LCC & debug state allows. SOC will have flexibility to implement desired logic to write to MCU SRAM to skip MCU ROM and a register bit to bring MCU out of reset. MCU will start executing from the reset vector that was strapped which enables the first fetch vector to access MCI SRAM
Caliptra reset (cptra_rst_b) is deasserted.
Caliptra BootFSM will go through its own boot flow as documented in Caliptra spec, reads secret fuses and sets “ready_for_fuses” to MCI.

Note: In MCU-NO-ROM-CONFIG, steps 11 through 14 & steps 16 through 18 are done by a SOC entity. Otherwise, MCU ROM will do the below steps.
MCU ROM will be polling for this indication
MCU ROM will now read FC’s SW partition for all the required fuses including its own and also write Caliptra fuses. Note that only non-secret fuses are accessible for MCU ROM by fuse controller construction. a. Note: All fuses will be zero if FC is not programmed
MCU ROM will also write owner_pk_hash register (and any other additional pre-ROM configuration writes here)
MCU ROM will do a fuse_write_done write to Caliptra
Caliptra ROM starts to execute from here on.
Once Caliptra populates MCU SRAM, it will set FW_EXEC_CTL[2] which will trigger a reset request to MCU. MCU either needs to enable interrupts or poll on the appropriate bit to detect that Caliptra has requested a reset.
CSS-BootFSM waits for MCU to request the reset. Then CSS-BootFSM will do a halt req/ack handshake with MCU and assert the MCU reset after the MCU reports that it has successfully halted.
MCU ROM will read the reset reason in the MCI and execute from MCU SRAM

Watchdog Timer

The Watchdog Timer within the MCI is a crucial component designed to enhance the reliability and robustness of the SoC. This timer monitors the operation of the system and can trigger a system reset if it detects that the system is not functioning correctly. The Watchdog Timer is configurable through CSRs and provides various timeout periods and control mechanisms to ensure the system operates within defined parameters. The Watchdog timer contains two different timers. These timers can be configured in two different modes:

Cascade
Independent

In cascade mode when the first timer reaches a timeout two things will happen:

An error interrupt will be triggered
Timer 2 will start counting

If the WDT is not serviced before Timer 2 times out two things happen:

NMI output pin is asserted
NMI HW_ERROR_FATAL is triggered which can assert an error_fatal on the MCI port.

In Independent mode the two timers are completely independent of each other. When they timeout an error interrupt will be asserted. The NMI will never be asserted while in independent mode.

MCU Mailbox

There are 2 mailboxes in the MCI. Each Mailbox component of the MCI allows for secure and restricted communication between external SoC entities and the MCU. This communication channel is essential for exchanging control messages, status updates, and other critical information that the MCU will use to monitor system boot, firmware updates, and security critical operations. Mailboxes are designed to ensure that only authorized entities can access and communicate through it, preserving the integrity and security of the SoC operations.

MCU Mailbox Limited Trusted AXI users

There are 5 trusted AXI Users determined at build time via parameters or via MCI lockable registers. These users, a default user 0xFFFF_FFFF, and MCU are the only AXI users that can access or obtain a lock on the mailbox.

Any untrusted AXI user trying to read or write the mailbox will receive an AXI error response (MCU Mailbox Errors).

Trusted users always have read access to the CSRs in the mailbox, but require a lock to write the CSRs or read/write the SRAM.

MCU Mailbox Locking

A Requester will read the "LOCK" register to obtain a lock on the mailbox. This is a read-set register, the lock is acquired when read returns 0. The Requester must be a Trusted user. Once the lock is obtained the Requestor has read access to the entire mailbox and write access to:

All mailbox registers except the following will be RO:
- CMD_STATUS
- TARGET_STATUS
- TARGET_DONE
- TARGET_USER
Mailbox SRAM Unlocking/releasing occurs when the requestor writes 0 to the EXECUTE register. After releasing the mailbox the SRAM is zeroed out(MCU Mailbox SRAM Clearing).

On MCI reset release the MCU MBOX is locked for MCU. The MCU shall set the DLEN to the size of the SRAM and release the MBOX, causing the SRAM to be zeroed. This is done to prevent data leaking between warm resets via the SRAM.

MCU Mailbox Target User

A Target user is an additional user that can access and process the MBOX request. This user can only be setup by MCU and only valid when the TARGET_USER_VALID bit is set.

One example of when a Target user becomes necessary is when the SOC wants Caliptra to process a MBOX request. The SOC will obtain a lock, MCU will see the command request is for Caliptra, MCU will add Caliptra as the Target user and notify Caliptra.

Another example is when MCU itself obtains the mailbox lock. It will add a Target user and notify the Target user via AXI or some other mechanism.

A Target user has read access to the entire mailbox and write access to:

DLEN register
TARGET_STATUS register
TARGET_DONE register
Mailbox SRAM

The Target user will notify MCU it is done processing by setting TARGET_STATUS and TARGET_DONE. Setting TARGET_DONE will interrupt MCU. If required, MCU will then update the CMD_STATUS register with the final status of the command for the Requestor.

If a second Target user is required it is the MCU's responsibility to:

Clear TARGET_STATUS
Clear TARGET_DONE
Set new TARGET_USER

Otherwise these registers are cleared when the mailbox lock is released.

Target users must be an MCU Mailbox trusted user

MCU Mailbox Fully addressable SRAM

The SRAM is fully addressable and reads are not destructive in this mailbox.

Min Size: 0

Max Size: 2MB

If set to 0 the mailbox is not instantiated.

Accesses must be DWORD aligned and BYTE accesses are not supported by the SRAM.

MCU Mailbox SRAM Clearing

When the mailbox lock is released the SRAM is zeroed out from 0 to max DLEN set during the locking period. The flow for clearing the SRAM is:

Requester releases lock
MCU SRAM starts clearing
MCU SRAM clearing ends
Mailbox is unlocked

The Requester is locked out of the mailbox after step 1, even though the lock isn't cleared until step 4.

It is expected that agents write their content from 0 to DLEN. If an agent writes outside of this SRAM area, there is no security guarantee for that content because that data would not be zeroized between mailbox operations.

NOTE: When DLEN = 0 the entire MBOX SRAM is cleared.

MCU Mailbox Interrupts

The following interrupts are sent to MCU:

Interrupt	Description
SOC request MBOX	Asserted when MCU has MBOX lock and an SOC agent tries to obtain the lock. MCU can decide to release the mailbox if this happens.
Mailbox data available from SOC	Asserted when a SOC agent gets lock and assert the EXECUTE register, indicating data is availalbe for MCU.
Target Done	Asserted when the Target user is done processing the data and is ready for MCU to consume or pass data to Requestor.

The following interrup(s) are available for SOC consumption:

Interrupt	Description
Mailbox data available from MCU	Asserted when MCU gets lock and assert the EXECUTE register, indicating data is available for SOC consumption.

MCU Mailbox Errors

Each mailbox has the following errors:

Error Type	Response	Description
Untrusted User Access	Read: - Data return 0 - AXI Error Write: - Data dropped - AXI Error	When an Untrusted user tries to access any address within the MBOX.
Trusted User Illegal Access	Read: - Data return 0 Write: - Data dropped	When a Trusted user tries to: - Access the mailbox when it doesn't have a lock - Tries to write to a register it doesn't have access to. - Tries to access an illegal SRAM address within the mailbox.
Single Bit ECC Error	- Interrupt to MCU - Mailbox ECC SB status set - Data corrected	Single bit ECC error while reading Mailbox.
Double Bit ECC Error	- Error interrupt to MCU - HW_NON_FATAL error set for SOC consumption - Mailbox ECC DB status set - Invalid data returned	Double bit ECC error while reading Mailbox.

Whenever an agent reads data from the SRAM they either need to consume the Double Bit ECC interrupt wire or check the MCU Mailbox status registers to know if the data they received is valid.

MCU Mailbox MCU Access

When there is a mailbox lock the MCU has full access to the mailbox CSRs and SRAM in order to facilitage interactions and help with any lockup.

It is the only agent allowed to set TARGET_USER and update the final CMD_STATUS.

MCU Mailbox Address Map

Start Address	End Address	Name	Description
0x0000_0000	0x01F_FFFF*	MBOX SRAM	Mailbox SRAM
0x0020_0000	0x020_003F	MBOX CSR	Mailbox Control Status Registers

*NOTE: MBOX SRAM size is configurable, but MBOX always reserves 2MB address space. See MCU Mailbox Errors for how access to and invalid SRAM address are handled.

MCU MBOX Register Spec

MCU SRAM

The MCU SRAM provides essential data and instruction memory for the Manufacturer Control Unit. This SRAM bank is utilized by the MCU to load firmware images, store application data structures, and create a runtime stack. The SRAM is accessible via the AXI interface and is mapped into the MCI's memory space for easy access and management. Exposing this SRAM via a restricted API through the SoC AXI interconnect enables seamless and secured Firmware Updates to be managed by Caliptra.

Min Size: 4KB

Max Size: 2MB

AXI USER filtering is used to restrict access within the MCU SRAM based on system state and accessor. Access permissions are based on the AXI USER input straps (either the MCU SRAM Config AXI_USER, or the MCU IFU/LSU AXI USERS). Any write attempt by an invalid AXI_USER is discarded and returns an error status. Any read attempt returns 0 data and an error status. The MCU SRAM contains two regions, a Protected Data Region and an Updatable Execution Region, each with a different set of access rules.

After each MCU reset the Updateable Execution Region may only be read/written by MCU SRAM Config User (typically Caliptra) prior to mcu_sram_fw_exec_region_lock input signal is set. Once fw_exec_region_lock is set it can be read/written by the MCU IFU or MCU LSU until MCU reset is asserted.

The Protected Data Region is only ever read/write accessible by MCU LSU. The span of each region is dynamically defined by the MCU ROM during boot up. Once MCU has switched to running Runtime Firmware, the RAM sizing shall be locked until any SoC-level reset. ROM uses the register FW_SRAM_EXEC_REGION_SIZE to configure the SRAM allocation in 4KB increments. FW_SRAM_EXEC_REGION_SIZE counts in base 0 meaning the smallest the Updateable Execution Region size can be is 4KB. It is possible for the entire SRAM to be allocated to the Updatable Execution Region and there be no Protected Data Region.

The entire MCU SRAM has ECC protection with no ability to disable. Single bit errors are detected and corrected. Double bit errors are detected and error.

MCI actions for single bit errors:

Correct data and pass corrected data back to the initiator.
Send maskable interrupt notification to MCU.

MCI actions for double bit errors:

AXI SLVERR response to the initiator
HW_ERROR_FATAL asserted and sent to SOC

MCU SRAM is accessible via DMI, see DMI MCU SRAM Access for more details.

MCU Hitless Update Handshake

The hitless flow is described in full in Caliptra Top Spec. The Caliptra SS Integration Spec contains all MCI warm reset and hitless update flows and restrictions. This section is focused on the HW registers both Caliptra and MCU will used to complete the flow.

MCI tracks three different RESET_REASON in its register bank:

Reset type	Description
`WARM_RESET`	MCI reset cycle. MCU SRAM has FW image but need Caliptra interaction before jumping to the FW image.
`FW_BOOT_UPD_RESET`	First hitless update since MCI warm reset. MCU SRAM needs full initialization.
`FW_HITLESS_UPD_RESET`	Second or greater hitless update since MCI warm reset. MCU SRAM can be partially initialized since valid content still exists in the MCU SRAM from previous firmware.

WARM_RESET will be set by hardware when a warm reset occurs. It should be cleared by the Caliptra Core during a firmware boot or hitless update flow.

FW_BOOT_UPD_RESET and FW_HITLESS_UPD_RESET are typically set and cleared by the Caliptra Core during a firmware boot or hitless update flow. If Caliptra Core is not used in the design, the SoC needs to designate a different trusted entity to control these registers.

FW_EXEC_CTLR[2] is an input signal to the MCI and is sent as an interrupt (notif_cptra_mcu_reset_req_sts) to the MCU. This interrupt should be cleared by the MCU before it requests a reset with RESET_REQUEST.req. After a warm reset, setting FW_EXEC_CTRL[2] will trigger an interrupt to the MCU, indicating that the MCU should reset itself with RESET_REQUEST.req. After the first MCU reset request, when this input signal is cleared, it triggers the interrupt. The MCU is held in reset until FW_EXEC_CTRL[2] is set, with a minimum reset time determined by the MIN_MCU_RST_COUNTER MCI parameter.

MCI AXI Subordinate

MCI AXI Subordinate decodes the incoming AXI transaction and passes it onto the appropriate submodule within MCI.

The MCI AXI Sub will respond with an AXI error if one of the following conditions is met:

Submodule error response

AXI access misses are:

Writes dropped
Reads return 0

MCI Interrupts

All interrupt status and control registers live in the CSR block. Each interrupt has the following properties:

Status: W1C for SW to clear
Enable: Prevents status from propagating. It does not block the status from being set.
SW Trigger: Ability for SW to manually trigger the interrupt. Typically used for debug.
Counter: Counts number of times the interrupt event was detected (SW or HW).

There are two different groups of interrupts

Error
Notification

Each group of interrupts has its own global status and enable registers that are an aggregate of all interrupts in the group. These status and enable registers have the same properties as the individual interrupt status and enable registers.

All interrupt groups are ORed and sent out on a signal mci_intr pin.

SW access to all interrupt registers are restricted to MCU.

MCI aggregates other Caliptra SS interrupts in this infrastructure. To clear these interrupts FW must:

Service the interrupt at the IP source.
Clear the interrupt in MCI.

Interrupts that are aggregated in MCI:

Caliptra MBOX data available
OTP FC Done Interrupt

MCI Error handling

MCI aggregates the error information (Fatal, Non-Fatal errors from Caliptra, any error signals that fuse controller, i3c etc.) and provides subsystem level FATAL and NON FATAL error signals. For all the error information being collected from other subystem modules, MCI also provides masking capability for MCU FW to program/enable based on SOC specific architectures to provide maximum flexibility.

Aggregate error register assignments are documented in the register specification: TODO: Add a link to rdl -> html file

Regions of 6 bits in the aggregate error registers are reserved for each component. MCU and Caliptra errors are connected to appropriate severity levels. Lifecycle controller, fuse controller and I3C are connected to both severities. Masks are used to set the severity of each error for these components. These can be configured by integrators, ROM, or runtime firmware.

Error Register Bits	Component	Default Error Severity	Description
Aggregate error[5:0]	Caliptra core	Both	Caliptra errors
Aggregate error[11:6]	MCU	Both	DCCM double bit ECC error is fatal DCCM single bit ECC error is non-fatal
Aggregate error[17:12]	Life cycle controller	Fatal	LCC alerts [14:12]
Aggregate error[23:18]	OTP Fuse controller	Fatal	FC Error [23], FC alerts [22:18]
Aggregate error[29:24]	I3C	Non-Fatal	Peripheral reset [25] and escalated reset [24] pins from I3C
Aggregate error[31:30]	Spare bits	None	Spare bits for integrator use

MCI also generates error signals for its own internal blocks, specifically for MCU SRAM & mailboxes double bit ECC and WDT.

MCI Fuse Storage Support

MCI also provides capability to store fuses required for Caliptra subsystem for Caliptra core's usage for production debug unlock feature. MCU will read the fuse controller for the production debug unlock hashes , write to the corresponding registers in the MCI block and lock the registers from being changed by MCU RT FW. Lock is done by writing to do a FUSE_WR_DONE (FIXME: Add specific register & bit names).

MCU Timer

Standard RISC-V timer interrupts for MCU are implemented using the mtime and mtimecmp registers defined in the RISC-V Privileged Architecture Specification. Both mtime and mtimecmp are included in the MCI register bank, and are accessible by the MCU to facilitate precise timing tasks. Frequency for the timers is configured by the SoC using the dedicated timer configuration register, which satisfies the requirement prescribed in the RISC-V specification for such a mechanism. These timer registers drive the timer_int pin into the MCU.

MCU Trace Buffer

MCI hosts the MCU trace buffer. It can hold up to 64 trace packets from the MCU, see MCU Trace Buffer Packet for the data format. Read access to the trace buffer is controlled by the LCC state Translator. When Debug Locked all AXI and DMI accesses to the trace buffer are rejected. See MCU Trace Buffer Error Handling for expected response while Debug Locked.

MCU RISC-V processor can enable/disable tracing with an internal CSR, by default it is enabled. Within MCI there is no way to disable traces.

The trace buffer is a circular buffer where the oldest data is overwritten by new traces when the buffer is full. When a trace packet is stored the write pointer increments by MCU Trace Buffer Packet Size/DWORD

The trace buffer is reset when MCI reset is asserted (warm reset).

MCU Trace Buffer SW Interface

Below is the SW interface to extract trace data:

Register Name	Access Type	Description
DATA	RO	Trace data at READ_PTR location
READ_PTR	RW	Read pointer in trace buffer for DATA. NOTE: this is not an address, meaning increment by 1 to get the next entry.
WRITE_PTR	RO	Offset to store next trace entry in trace buffer. If VALID_DATA is set, WRITE_PTR - 1 is the newest trace entry.
STATUS.VALID_DATA	RO	Indicates at least one entry is valid in the trace buffer.
STATUS.WRAPPED	RO	Indicates the trace buffer has wrapped at least once. Meaning all entries in the trace buffer are valid. If 0, then the oldest entry in the buffer is at ptr=0. If 1, the oldest entry is at WRITE_PTR
CONFIG.TRACE_BUFFER_DEPTH	RO	Indicates the total number of 32 bit entries in the trace buffer. TRACE_BUFFER_DEPTH - 1 is the last valid WRITE/READ_PTR entry in the trace buffer. NOTE: This is the trace buffer depth and not the number of MCU Trace Buffer Packets.

MCU Trace Buffer Registers Spec

MCU Trace Buffer Packet

A single MCU trace packet is more than 32 bits, meaning each trace takes up more than one READ/WRITE_PTR entry. Trace data is stored in the following format:

Assuming there is only one trace stored in the trace buffer the WRITE_PTR would read as 0x4. To get the entire trace packet the user would need to read offsets 0x0, 0x1, 0x2, and 0x3.

MCU Trace Buffer Extraction

To extract trace buffer data the user should send the following transaction:

Write READ_PTR
Read DATA

Repeat these steps until all data required has been extracted.

The user should use the combination of WRITE_PTR, VALID_DATA, WRAPPED, and TRACE_BUFFER_DEPTH to know where valid data lives in the trace buffer.

MCU Trace Buffer Error Handling

AXI access to the MCU Trace Buffer while not in debug mode will result in an AXI error.

DMI access to the MCU Trace Buffer while not in debug mode will result in writes being dropped and reads returning 0.

If the user sets the READ_PTR > (TRACE_BUFFER_DEPTH - 1) and tries to read the DATA register, the behavior is undefined.

MCI Debug

MCI Debug Access

MCI provides DMI access via MCU TAP and a DEBUG AXI USER address for debug access to MCI.

MCI DMI

NOTE: DMI access to MBOX0/1 is not enabled in Caliptra 2.0. This will be enabled in future Caliptra versions

The DMI port on MCU is a dedicated interface that is controlled via the MCU TAP interface. MCI provides two services when it comes to DMI:

MCU DMI enable control (uncore and core)
DMI interface for debug access to MCI address space

MCU DMI Enable Control

The MCU has two different DMI enables:

Core
- Access to internal MCU registers
Uncore
- Access to MCI registers

MCI provides the logic for these enables. When the following condition(s) are met the enables are set:

MCU Core Enable: Debug Mode

MCU Uncore Enable: Debug Mode OR LCC Manufacturing Mode OR DEBUG_INTENT strap set

Note: These are the exact same controls Calipitra Core uses for DMI enable

MCI DMI Interface

The MCI DMI Interface gives select access to the blocks inside MCI.

Access to MCI's DMI space (MCU Uncore) is split into two different levels of security:

Illegal accesses will result in writes being dropped and reads returning 0.

NOTE: MCI DMI address space is different than MCI AXI address space.

MCI DMI Memory Map

Register Name	DMI Address	Access Type	Debug Locked Access	Debug Unlock Access
NOT ENABLED IN 2.0 MBOX0_DLEN	0x50	RO	Yes
NOT ENABLED IN 2.0 MBOX0_DOUT	0x51	RO	Yes
NOT ENABLED IN 2.0 MBOX0_STATUS	0x52	RO	Yes
NOT ENABLED IN 2.0 MBOX0_DIN	0x53	WO	Yes
NOT ENABLED IN 2.0 MBOX1_DLEN	0x54	RO	Yes
NOT ENABLED IN 2.0 MBOX1_DOUT	0x55	RO	Yes
NOT ENABLED IN 2.0 MBOX1_STATUS	0x56	RO	Yes
NOT ENABLED IN 2.0 MBOX1_DIN	0x57	WO	Yes
MCU_SRAM_ADDR	0x58	RW		Yes
MCU_SRAM_DATA	0x59	RW		Yes
MCU_TRACE_STATUS	0x5A	RO		Yes
MCU_TRACE_CONFIG	0x5B	RO		Yes
MCU_TRACE_WR_PTR	0x5C	RO		Yes
MCU_TRACE_RD_PTR	0x5D	RW		Yes
MCU_TRACE_DATA	0x5E	RO		Yes
HW_FLOW_STATUS	0x5F	RO	Yes
RESET_REASON	0x60	RO	Yes
RESET_STATUS	0x61	RO	Yes
FW_FLOW_STATUS	0x62	RO	Yes
HW_ERROR_FATAL	0x63	RO	Yes
AGG_ERROR_FATAL	0x64	RO	Yes
HW_ERROR_NON_FATAL	0x65	RO	Yes
AGG_ERROR_NON_FATAL	0x66	RO	Yes
FW_ERROR_FATAL	0x67	RO	Yes
FW_ERROR_NON_FATAL	0x68	RO	Yes
HW_ERROR_ENC	0x69	RO	Yes
FW_ERROR_ENC	0x6A	RO	Yes
FW_EXTENDED_ERROR_INFO_0	0x6B	RO	Yes
FW_EXTENDED_ERROR_INFO_1	0x6C	RO	Yes
FW_EXTENDED_ERROR_INFO_2	0x6D	RO	Yes
FW_EXTENDED_ERROR_INFO_3	0x6E	RO	Yes
FW_EXTENDED_ERROR_INFO_4	0x6F	RO	Yes
FW_EXTENDED_ERROR_INFO_5	0x70	RO	Yes
FW_EXTENDED_ERROR_INFO_6	0x71	RO	Yes
FW_EXTENDED_ERROR_INFO_7	0x72	RO	Yes
RESET_REQUEST	0x73	RW		Yes
MCI_BOOTFSM_GO	0x74	RW	Yes
CPTRA_BOOT_GO	0x75	RW		Yes
FW_SRAM_EXEC_REGION_SIZE	0x76	RW		Yes
MCU_RESET_VECTOR	0x77	RW		Yes
SS_DEBUG_INTENT	0x78	RW		Yes
SS_CONFIG_DONE	0x79	RW		Yes
SS_CONFIG_DONE_STICKY	0x7A	RW		Yes
MCU_NMI_VECTOR	0x7B	RW		Yes
MCI_DMI_MCI_HW_OVERRIDE (DMI ONLY Reg)	0x7C	RW		Yes

DMI Only Registers

MCI_DMI_MCU_HW_OVERRIDE

Field Name	Bits	Access Type	Description
`mcu_sram_fw_exec_region_lock`	[0]	RW	mcu_sram_fw_exec_region_lock control. ORed with input signal giving debugger control if Caliptra Core in reset while attempting MCU reset flow.
`reserved`	[31:1]	RW	Reserved

DMI MCU SRAM Access

MCU SRAM is only accessable via DMI while in Debug Unlock. While in Debug Unlock DMI has RW permission to the entire MCU SRAM.

Due to limited DMI address space the MCU SRAM is accessable via a two register mailbox.

MCU_SRAM_ADDR
MCU_SRAM_DATA

The first MCU SRAM address is at address 0x0. The address is byte addressable, but all accesses must be DWORD aligned. Failure to align the address will result in undefined behavior. Access to addresses beyond the MCU SRAM size will result in address wrapping.

To write content to the MCU SRAM the flow is:

Write MCU_SRAM_ADDR
Write MCU_SRAM_DATA

To read content from the MCU SRAM the flow is:

Write MCU_SRAM_ADDR
Read MCU_SRAM_DATA

There is no error response on the DMI port, so any ECC error must be checked via the ECC registers in the MCI Register Bank.

Important: MCU core must be halted to access MCU SRAM via DMI. Failure to do so will result in collisions between the two interfaces and an error will be reported.

DMI MCU Trace Buffer Access

Access to the MCU Trace buffer via DMI is the same SW interface as specified in MCU Trace Buffer.

Access is limited to Debug Unlock mode only. Access to this space while not in Debug Unlock will result in writes being dropped and reads return 0x0.

MCI Boot FSM Breakpoint

The MCI Breakpoint is used as a stopping point for debugging Caliptra SS. At this breakpoint the user can either use one of the MCI Debug Access mechanisms to configure MCI before bringing MCU or Caliptra out of reset.

MCI Boot FSM Breakpoint Flow

Assert mci_boot_seq_brkpoint
Deassert MCI Reset
DEBUG ACCESS TO MCI
Set MCI's BRKPOINT_GO register to 1
- Through one of the MCI Debug Access methods.
FSM will continue

MCI Design for Test (DFT)

Reset Controls

MCI controls various resets for other IPs like MCU and Caliptra Core. When the scan_mode input port is set these resets are directly controlled by the mcu_rst_b input intead of the internal MCI logic.

Caliptra 2.1 Documentation

Caliptra Subsystem Hardware Specification

Version 2p1