What Caliptra Asks of Your SoC: An Integrator's Walkthrough

Caliptra is an open root of trust block for data centre SoCs, published as a specification, RTL, ROM and firmware. It began at the Open Compute Project, and its code now lives in the CHIPS Alliance. Adopting it means accepting a contract: the block does a small job carefully, and the SoC team owns almost everything around it.

This post walks through that contract for integrators: what the block does, how it boots, which interfaces it exposes, what you must supply and what it leaves out. Our illustrative estimate puts Caliptra's share of a cold boot at about 46 ms at 400 MHz and about 184 ms at 100 MHz, and more than half of that is an allowance we chose, so you should replace it with your own measurement.

Key takeaways

• Caliptra measures and attests. In passive mode it authenticates its own firmware, while the SoC keeps responsibility for authenticating the rest of its boot chain.
• There are two integration modes. Passive mode leaves update and recovery with the SoC or platform. Subsystem mode adds a manufacturer control unit, I3C streaming boot and a fuse controller, and it requires the internal TRNG.
• The integration specification carries a long list of SoC requirements, many of them tied directly to the threat model. Fuses, the obfuscation key, scan handling and bus user IDs are where a careless integration can undo the block's assurances.
• Invasive physical attacks, backend integration, operational security and certification are outside the specification's scope.

What the block does

The specification describes Caliptra as a silicon root of trust and, in particular, a root of trust for measurement. The SoC measures the code and configuration it boots and hands those measurements to Caliptra. Caliptra stores them and reports them in signed attestations, using identities built on the TCG DICE model. Its stated aim is a deliberately small scope that fits many kinds of device, with CPU SoCs as the top priority and NICs, accelerators and storage among the other targets.

Inside, the block runs on a 32-bit VeeR EL2 RISC-V core. The hardware specification lists 96 KiB of ROM, 256 KiB of ICCM, 256 KiB of DCCM and a set of accelerators: SHA-2, SHA-3, HMAC, ECC P-384, AES and the Adams Bridge engine for ML-DSA and ML-KEM. Key, PCR and data vaults hold state away from firmware where the design requires it. The PCR bank has 32 entries of 384 bits each.

Identity is a chain. A unique device secret seed sits obfuscated in fuses and is used to derive the IDevID key. Field entropy, which the owner can program, feeds the LDevID key. Below those sit the FMC alias and runtime alias keys, each tied to the firmware that holds it. A DICE Protection Environment then lets runtime firmware derive identities for other SoC components. Change the firmware and the alias identities change with it, and that property is what makes the attestation useful.

Passive or Subsystem

This is the first real decision, because it moves work between your team and the IP.

	Passive mode	Subsystem mode
Who starts the flow	SoC ROM	MCU ROM, with Caliptra ROM
How firmware arrives	SoC pushes it into the mailbox	A platform component, typically BMC-like, streams it using OCP streaming boot over I3C
Update and recovery	SoC or an external root of trust	Provided through the subsystem flow
Mailbox SRAM	256 KiB	16 KiB, plus an external staging area that must sit inside the crypto boundary
TRNG	Internal recommended; a shared TRNG API exists but is discouraged for production	Internal TRNG required
Bus role	AXI manager interfaces tied off	AXI manager used for DMA and streaming boot

Subsystem mode brings more of the surrounding logic as open IP, including the fuse controller and life cycle controller. It also ties you to the OCP recovery flow and to MCU firmware. Passive mode suits a team that already has a mature SoC boot ROM and a platform recovery story.

The boot flow, step by step

Here is the passive cold boot, drawn from the main specification, the integration specification and the ROM specification.

1. Clock and reset. The clock runs for at least 10 cycles before cptra_pwrgood asserts. The SoC then waits at least 10 more cycles before deasserting cptra_rst_b.
2. Fuse download. The boot state machine raises ready_for_fuses. Immutable logic or ROM on the SoC side writes the fuse registers, then sets fuse done, which locks them until the next power-good cycle.
3. ROM starts. Resets are released and Caliptra ROM runs its known answer tests. It decrypts the seed and field entropy using the obfuscation key, then derives the IDevID and LDevID layers.
4. Mailbox opens. Until ROM enables the mailbox, hardware drops writes to it. ROM then signals that it is ready for firmware.
5. Measurements and firmware load. Any security-sensitive code the SoC loaded before this point must be stashed in Caliptra. ROM can hold at most eight stashed measurements before runtime firmware boots. If the SoC exceeds that, attestation must be disabled until the next cold reset. The SoC then pushes the firmware bundle.
6. Validation. ROM checks the key hashes against fuses, checks revocation, verifies vendor and owner signatures, verifies the table of contents and the FMC and runtime digests, and compares the security version number with the fuses.
7. Handover. ROM derives the FMC alias layer, locks memory regions and launches FMC. FMC hands over to runtime firmware, which raises ready_for_runtime and offers the attestation APIs.
8. The rest of the SoC boot. Each later SoC stage authenticates, measures and starts the next, depositing its measurement in Caliptra first.

A warm reset is cheaper. The specification says ROM skips DICE key generation and firmware load there, because keys already exist and firmware is already in ICCM. That depends on SRAM contents surviving, which becomes a requirement on your memory design.

A worked estimate: the boot budget

The published cycle counts are useful, but no source we read gives a total for boot time. So here is a rough one. The operation counts are our reading of the ROM specification, and the transfer assumptions and software allowance are illustrative numbers we chose. Only the per-operation cycle counts come from the project's documents.

Item	Calculation	Cycles	ms at 400 MHz
ECC P-384 key generation	3 × 719,675	2,159,025	5.40
ECC P-384 signing	2 × 736,978	1,473,956	3.68
ECC P-384 verification	4 × 960,404	3,841,616	9.60
ML-DSA-87 key generation	3 × 17,428	52,284	0.13
ML-DSA-87 signing (average)	2 × 126,937	253,874	0.63
ML-DSA-87 verification	4 × 18,252	73,008	0.18
Firmware transfer, illustrative	2 × 32,768 words × 8 cycles	524,288	1.31
Software allowance, illustrative	Chosen figure	10,000,000	25.00
Total		18,378,051	45.9

Rows are rounded. The counts assume three layers of keys, two certificates, each signature checked after signing, vendor and owner signatures on the firmware, and ML-DSA chosen over LMS. The transfer line assumes a 128 KiB bundle (32,768 words), moved once into the mailbox and once out of it. The allowance covers known answer tests, hashing, ROM and FMC software, runtime alias derivation and waiting for entropy.

Three things stand out. ECC work totals about 18.7 ms, while ML-DSA adds about 0.95 ms, roughly a twentieth as much, so on these figures the post-quantum signatures are not what sets the budget. Next, the time scales with the clock: if every cycle scales, the same total is about 91.9 ms at 200 MHz and about 183.8 ms at 100 MHz. And the largest single line is a guess. Run the real ROM in simulation or on an emulator to replace it. The ROM documentation also describes a fake ROM for pre-silicon work that shortens boot, so make sure you time the real one.

Area deserves a similar sketch. The specification expects Caliptra to be under 1 mm² of a large SoC. As an illustrative planning figure, 1 mm² is 0.25% of a 400 mm² die and 1% of a 100 mm² die. For memory, passive mode needs 768 KiB of SRAM data (256 + 256 + 256). With 7 ECC bits on each 32-bit word that becomes 936 KiB of raw capacity (768 × 39 ÷ 32), before ROM and the Adams Bridge SRAMs. Subsystem mode needs 528 KiB of data, or 643.5 KiB raw, plus the staging area.

For a published reference, the Adams Bridge document gives about 45,900 µm² at 5 nm for one masking configuration. The integration specification also has a representative netlist table, but it names no node, so get your numbers from your own flow and memory compiler.

The interfaces you connect

Interface	What to know
AXI subordinate	Single outstanding transaction, in-order responses, 32-bit aligned access. Mailbox data and TRNG data registers need full-word writes.
Mailbox and status wires	ready_for_fuses, ready_for_mb_processing, ready_for_runtime, mailbox_data_avail. The mailbox has a lock and an access list keyed on AXI user.
SRAM	ICCM, DCCM, mailbox and Adams Bridge memories are exported so you can use your own compiler. ROM is reached through its own IMEM port.
Security inputs	security_state, scan_mode, cptra_obf_key (256 bits), cptra_csr_hmac_key (512 bits).
Entropy	Internal TRNG sample inputs, or a request and response API with an external source in passive mode.
Errors and generic wires	cptra_error_fatal, cptra_error_non_fatal, plus 64-bit generic inputs and outputs.
JTAG	A standard five-wire TAP. Core clock must be at least twice the TCK frequency for JTAG data to cross correctly.
Trace	Do not connect. The specification says these ports are unvalidated.

What the integrator must provide

The integration specification's SoC requirements table is the document to work through line by line. These are the items we would put first. Items marked with an asterisk there can be waived only with documented, approved justification.

• Fuses. All core fuses in the fuse map must exist, including a 512-bit obfuscated seed, 256 bits of field entropy, 384-bit vendor and owner key hashes and a 128-bit runtime version counter. Field entropy programming needs its own API, with burning of individual bits prohibited. Debug read paths must be disabled in the production state.
• Obfuscation key. Generate it with 256 bits of entropy and drive it by ECO before tape-out, or from a PUF. Keep its flops off scan chains, and keep it unreachable from firmware.
• Security state and debug. Drive security state wires from your own life cycle logic. If the SoC is under debug, Caliptra must be told.
• Scan. Hold scan_mode high for 5,000 clocks before scan is enabled, so that secrets are flushed.
• Clock and power. Use an on-die clock source. Restrict programmable clock controls to the SoC manager. Do not power-gate Caliptra separately from the SoC, and tie its power-good to the reset that triggers cold boot.
• SRAM. Close timing on a one-cycle read path, size for SECDED, keep contents across warm reset, and repair and initialise only around power-good events.
• Bus identity. Every agent with a route to Caliptra needs a suitable AXI user value, and 0xFFFFFFFF is reserved. One agent writes fuses, and only a chosen subset reaches the mailbox.
• Primitives and backend. Map the generic primitives to library cells, apply size-only constraints to tagged cells and check that synthesis and place and route did not remove them. The specification supports 400 MHz at 0.72 V on an unnamed advanced node as of April 2025, and your own design must still converge.
• Manufacturing. Provision the IDevID certificate through a controlled flow, and set policies against seed leakage, cloning and spurious certificates.
• Errors. Report the error outputs. Fatal errors recover only through a power-good reset.

The specification also says the reference RTL and firmware are intended to be adopted as they are, without modification. Plan to wrap the block rather than change it. Where it fits in your programme, our SoC lifecycle on The Semiconductor Hub shows when these decisions fall due.

What it does not cover

• Your SoC's boot chain. Caliptra does not authenticate SoC firmware in passive mode; it records what the SoC measured. The SoC or platform keeps integrity of the other chain-of-trust elements.
• Your SoC security engine. The specification expects one alongside Caliptra, and says the two have different roles rather than a hierarchy.
• Invasive attacks. Depackaging and delayering are out of scope. Non-invasive physical attacks are in scope, but fault injection and power or electromagnetic countermeasures are described as a strong recommendation. Our post on analog security in multi-die systems looks at nearby attack surfaces that a digital block cannot see.
• Backend and test. Foundry IP integration, physical design countermeasures, analogue IP and post-manufacture test are all excluded.
• Update and recovery in the core. These come from the subsystem or an external root of trust.
• Data path cryptography. The services are for the control plane, so line-rate encryption needs its own engine.
• Direct sealing and owner enrolment. Caliptra does not seal secrets directly, though DPE can support an external sealer such as a TPM. It does not generate an LDevID CSR, so owners who want to endorse LDevID need proprietary flows.
• Certification and operations. Certification and operational security are out of scope. A KAT flow helps FIPS work, but an open block does not hand you a certificate. Regulation is a further question, covered from a chip supplier's side in our post on the EU Cyber Resilience Act.

FAQ

Which version should we read?

Check the release page first. As of 7 November 2026, the RTL repository's latest tagged releases were v2.1.2 and v2.0.4, both dated 19 March 2026. The main branch documents carry a 2.1 cover, and some already describe 2.2 work, so pin your reading to the tag you plan to use.

Can we use the Caliptra name for a modified design?

The project publishes a trademark policy and a checklist. Read those with your own counsel, since this post is not legal advice.

Does the 400 MHz figure bind us?

No. The integration specification says other frequencies are up to the user, and your boot budget moves with the clock.

Sources

• CHIPS Alliance, Caliptra repository README, read 7 November 2026.
• CHIPS Alliance, "Caliptra: A Datacenter System on a Chip (SoC) Root of Trust (RoT)", Revision 2.1, main branch, last changed 17 September 2026.
• CHIPS Alliance, "Caliptra Integration Specification", Version 2.1, main branch, last changed 6 November 2026.
• CHIPS Alliance, Caliptra Hardware Specification, main branch, last changed 6 November 2026.
• CHIPS Alliance, "Caliptra - ROM Specification v2.1", caliptra-sw repository, last changed 8 October 2026.
• CHIPS Alliance, Caliptra Subsystem Hardware Specification and Integration Specification, caliptra-ss repository, main branch, read 7 November 2026.
• CHIPS Alliance, Adams Bridge Hardware Specification and ML-DSA documentation, adams-bridge repository, main branch, read 7 November 2026.
• CHIPS Alliance, caliptra-rtl release listing, releases v2.1.2 and v2.0.4, 19 March 2026.

The boot and area estimates use illustrative assumptions and our own operation counts, alongside cycle and area figures published by the project on the dates shown. Those project figures are its own statements and may change between releases. This post is not legal, compliance or certification advice.