Caliptra Integration Specification

Version 2.1

Scope

This document describes the Caliptra hardware implementation requirements, details, and release notes. This document is intended for a high-level overview of the IP used in Caliptra.

This document is not intended for any micro-architectural design specifications. Detailed information on each of the IP components are shared in individual documents, where applicable.

Overview

This document contains high level information on the Caliptra hardware design. The details include open-source IP information, configuration settings for open-source IP (if applicable), and IP written specifically for Caliptra.

For more information, see Caliptra: A Datacenter System on a Chip (SoC) Root of Trust (RoT).

References and related specifications

The blocks described in this document are either obtained from open-source GitHub repositories, developed from scratch, or modification of open-source implementations. Links to relevant documentation and GitHub sources are shared in the following table.

Table 1: Related specifications

Caliptra Core

For information on the Caliptra Core, see the High level architecture section of Caliptra: A Datacenter System on a Chip (SoC) Root of Trust (RoT).

SoC interface definition

The following figure shows the SoC interface definition.

Figure: SoC Interface Block Diagram

Integration parameters

The following table describes integration parameters.

Table 2: Integration parameters

Table 3: Integration Defines

Interface

The following tables describe the interface signals.

Table 4: Clocks and resets

Table 5: AXI Subordinate Interface

Table 6: Mailbox notifications

Table 7: Caliptra SRAM interface

Table 8: Adams-Bridge SRAM Interface

Adams-Bridge SRAM interface is used to connect the necessary SRAM instances for Adams-Bridge. There are 8 SRAMs, 2 of which have 2 banks. Each SRAM has a parameterized data width and depth used to calculate the addr width.

All memories are modeled as 1 read 1 write port RAMs with a flopped read data. See abr_1r1w_ram.sv and abr_1r1w_be_ram.sv for examples. Strobe width describes the number of bits enabled by each strobe. All strobed memories are byte enabled in the design. See ABR Memory requirement for more details.

The full set of wires is encapsulated in the abr_mem_if construct abr_memory_export at the Caliptra boundary.

The table below details the interface required for each SRAM. Driver direction is from the perspective of Caliptra.

Table 9: JTAG interface

Table 10: RISC-V Trace interface Trace ports have been directly connected from Caliptra's instance of the VeeR-EL2 RISC-V core to the top-level. However, use of these ports has not been validated. Integrators shall leave these ports unconnected. Support for these ports may be added in a future release.

Table 11: Subsystem Straps and Control

Table 12: Security and miscellaneous

Architectural registers and fuses

Control registers and fuses are documented on GitHub.

• External Registers: caliptra_top_reg — caliptra_top_reg Reference (chipsalliance.github.io)
• Internal Registers - clp — clp Reference (chipsalliance.github.io)

Fuses

Fuses may only be written during the BOOT_FUSE state of the Boot FSM and require a cptra_pwrgood to be recycled to be written again.

After all fuses are written, the fuse done register at the end of the fuse address space must be set to 1 to lock the fuse writes and to proceed with the boot flow.

Although fuse values (and the fuse done register) persist across a warm reset, SoC is still required to perform a write to the fuse done register while in the BOOT_FUSE state in order to complete the bringup from reset. See Boot FSM for further details.

Note: Starting in Caliptra 2.0 subsystem strap and other configuration registers have been added to the fuse region. Subsystem straps are expected to be programmed during the same time as fuses per Caliptra spec. The following SS registers in the fuse region are not straps, are intended for internal use in Caliptra, and cannot be written by any SoC agents; therefore, categorizing them under the FUSE range has no effect:

• SS_DBG_SERVICE_REG_RSP
• SS_SOC_DBG_UNLOCK_LEVEL
• SS_GENERIC_FW_EXEC_CTRL

The remaining register SS_DBG_SERVICE_REG_REQ is initialized by the same SoC agent as fuses and is the only agent that can make subsystem debug service requests.

Interface rules

The following figure shows the reset rules and timing for cold boot flows.

Figure: Reset rules and timing diagram

Deassertion of cptra_pwrgood indicates a power cycle that results in returning Caliptra to its default state. All resettable flops are reset.

Deassertion of cptra_rst_b indicates a warm reset cycle that resets all but the “sticky” registers (fuses, error logging, etc.).

Assertion of BootFSM_BrkPoint stops the boot flow from releasing Caliptra from reset after fuse download. Writing a 1 to the GO field of the CPTRA_BOOTFSM_GO register allows the boot flow to proceed.

AXI

Arbitration

Caliptra has two interfaces attached to the AXI bus: a subordinate, incapable of initiating transfers, and a manager interface. The AXI manager is only enabled in Caliptra Subsystem mode, and must be tied to 0 in all other use-cases. The AXI subordinate is used by SoC agents to interact with the Caliptra external registers. If SoCs have multiple AXI agents or other proprietary-fabric protocols that require any special fabric arbitration, that arbitration is done at SoC level.

AXI User

AXI address user request signals (ARUSER and AWUSER, collectively "AxUSER") are used to uniquely identify AXI agents that have issued the request to Caliptra. Refer to Mailbox AXI User Attribute Register and SoC Integration Requirements for additional details.

Unsupported features

The Caliptra AXI subordinate has the following usage restrictions:

• Single outstanding transaction is serviced at a time (read or write). Operation is half-duplex due to the underlying register access interface.
  • AXI read and write requests may be accepted simultaneously by the AXI subordinate, but internal arbitration will service them one at a time.
• Responses are in order
• Burst data interleaving is not supported
• SoC agents shall not initiate AXI burst transfers to the SoC interface, except as write bursts to the mbox_datain register or read bursts from the mbox_dataout register. Such bursts shall be of the AXI "FIXED" burst type.
• Accesses to these registers shall not be "narrow". This means that AxSIZE must be set to 0x2 and WSTRB must be set to 0xF.
  • mbox_datain
  • mbox_dataout
  • CPTRA_TRNG_DATA
• Violations of the AXI specification by AXI managers will result in undefined behavior. Examples include:
  • AxSIZE values larger than interface width (greater than 0x2).
  • AxLEN larger than legal value (256 maximum burst size, 16 for FIXED bursts, and total burst length must be 4096 Bytes or less).
  • Number of data beats on W channel does not match burst length indicated on AWLEN.
  • RRESP or BRESP has an undefined value.
  • WLAST is driven incorrectly, driven on multiple beats, or never driven.
• Exclusive accesses are not supported. I.e. AxLOCK must be tied to 0.
• The following signals are unused/unconnected:
  • AxCACHE
  • AxPROT
  • AxREGION
  • AxQOS

Undefined address accesses

All accesses that are outside of the defined address space of Caliptra are responded to by Caliptra’s SoC interface:

• All reads to undefined addresses get completions with zero data.
• All writes to undefined addresses are dropped.
• All other undefined opcodes are silently dropped.
• Access to mailbox memory region with invalid AXI_USER are dropped.
• Access to a fuse with invalid AXI_USER are dropped.
• Access to the trng with invalid AXI_USER are dropped.
• SLVERR is asserted for any of the above conditions.

All accesses must be 32-bit aligned. Misaligned writes are dropped and reads return 0x0.

DMA Assist Engine

Caliptra contains a DMA assist engine and AXI manager interface that is used in Subsystem mode to initiate AXI transactions to the SoC AXI interconnect. When Caliptra is integrated in passive mode the DMA assist block is not available for use; all AXI manager interfaces must be tied to 0 and must not be connected to the SoC interconnect. For details on the DMA block in Subsystem mode operation, refer to the Caliptra Subsystem Hardware Specification.

Undefined mailbox usages

A trusted/valid requester that locks the mailbox and never releases the lock will cause the mailbox to be locked indefinitely.

Caliptra firmware internally has the capability to force release the mailbox based on various timers but there is no architectural requirement to use this capability.

Straps

Straps are signal inputs to Caliptra that are sampled once on reset exit, and the latched value persists throughout the remaining uptime of the system. Straps are sampled on either cptra_pwrgood signal assertion (cold reset exit) or cptra_noncore_rst_b deassertion (warm reset exit) – refer to interface table for list of straps. In 2.0, Caliptra adds support for numerous Subsystem-level straps. These straps are initialized on warm reset deassertion to the value from the external port, but may also be rewritten by the SoC firmware at any time prior to CPTRA_FUSE_WR_DONE being set. These must be programmed by SoC FW at the same time as Caliptra Fuses per Caliptra Spec. Once written and locked, the values of these straps persist until a cold reset.

Obfuscation key

SoC drives the key at the tape-in time of the SoC using an Engineering Change Order (ECO) and must be protected from common knowledge. For a given SoC construction, this can be driven using a PUF too.

The key must follow the security rules defined in the Caliptra architectural specification.

SoC must ensure that there are no SCAN cells on the flops that latch this key internally to Caliptra.

CSR HMAC key

SoC drives the key at the tape-in time of the SoC using an Engineering Change Order (ECO) and must be protected from common knowledge.

The key must follow the security rules defined in the Caliptra architectural specification.

SoC must ensure that there are no SCAN cells on the flops that latch this key internally to Caliptra.

Late binding interface signals

The interface signals generic_input_wires, generic_output_wires, and strap_ss_strap_generic_N are placeholders on the SoC interface reserved for late binding features. This may include any feature that is required for correct operation of the design in the final integrated SoC and that may not be accommodated through existing interface signaling (such as the mailbox).

While these late binding interface pins are generic in nature until assigned a function, integrators must not define non-standard use cases for these pins. Defining standard use cases ensures that the security posture of Caliptra in the final implementation is not degraded relative to the consortium design intent. Bits in generic_input_wires and strap_ss_strap_generic_N that don't have a function defined in Caliptra must be tied to a 0-value. These undefined input bits shall not be connected to any flip flops (which would allow run-time transitions on the value).

Each wire connects to a register in the SoC Interface register bank through which communication to the internal microprocessor may be facilitated. Each of the generic wire signals is 64 bits in size. The size of the generic strap is indicated in Table 11.

Activity on any bit of the generic_input_wires triggers a notification interrupt to the microcontroller indicating a bit toggle.

The following table describes the allocation of functionality on generic_input_wires. All bits not listed in this table must be tied to 0.

Table 13: generic_input_wires function binding

The following table describes the allocation of functionality to strap_ss_strap_generic_N. All straps not listed in this table must be tied to 0.

Table 14: strap_ss_strap_generic_N function binding

SoC interface operation

The Caliptra mailbox is the primary communication method between Caliptra and the SoC that Caliptra is integrated into.

The Caliptra mailbox uses an AXI interface to communicate with the SoC. The SoC can write to and read from various memory mapped register locations over the AXI interface in order to pass information to Caliptra.

Caliptra in turn also uses the mailbox to pass information back to the SoC. The interface does not author any transaction on the AXI interface. The interface only signals to the SoC that data is available in the mailbox and it is the responsibility of the SoC to read that data from the mailbox.

Boot FSM

The Boot FSM detects that the SoC is bringing Caliptra out of reset. Part of this flow involves signaling to the SoC that Caliptra is ready for fuses. After fuses are populated and the SoC indicates that it is done downloading fuses, the boot FSM wakes up the rest of Caliptra by deasserting the internal reset. Refer to CaliptraHardwareSpecification.md for more details and diagrams.

The boot FSM first waits for the SoC to assert cptra_pwrgood and deassert cptra_rst_b. The SoC first provides a stable clock to Caliptra. After a minimum of 10 clock cycles have elapsed on the stable clock, the SoC asserts cptra_pwrgood. The SoC waits for a minimum of 10 clocks after asserting cptra_pwrgood before deasserting cptra_rst_b. In the BOOT_FUSE state, Caliptra signals to the SoC that it is ready for fuses. After the SoC is done writing fuses, it sets the fuse done register and the FSM advances to BOOT_DONE.

BOOT_DONE enables Caliptra reset deassertion through a two flip-flop synchronizer.

SoC access mechanism

The SoC communicates with the mailbox through an AXI Interface. The SoC acts as the requester with the Caliptra mailbox as the receiver.

The AXI_USER bits are used by the SoC to identify which device is accessing the mailbox.

External Staging Area

To save SRAM area when Caliptra operates in Subsystem mode, the mailbox (MBOX) SRAM is reduced to 16 KiB.
Instead of passing images directly to Caliptra through the mailbox, the SoC can configure an external staging SRAM that Caliptra fetches from and processes.

Caliptra Core receives the base address of this staging area through the SOC_IFC register SS_EXTERNAL_STAGING_AREA_BASE_ADDR. The address must be an AXI address accessable via the Caliptra DMA controller. This register is exposed as a strap strap_ss_external_staging_area_base_addr and is overridable by SW until FUSE_DONE is set.

For hitless updates or other image-processing operations, the Caliptra mailbox should be used to:

1. Notify Caliptra that an image is available for processing.
2. Specify the command to run on the image.
3. Indicate the size of the image in the staging area.

References:

• Caliptra ROM MBOX Commands
• Caliptra Runtime FW MBOX Commands
• Caliptra HW API

The external staging area must be within the Caliptra crypto boundary. Meaning there must be access restrictions similar to the MBOX preventing trusted entities from manipulating or accessing the data being processed by Caliptra.

Mailbox

The Caliptra mailbox is a 256 KiB when in passive mode and 16 KiB when in subsystem mode buffer used for exchanging data between the SoC and the Caliptra microcontroller. See External Staging Area why the MBOX SRAM size is smaller in subsystem mode.

When a mailbox is populated by the SoC, initiation of the operation by writing the execute bit triggers an interrupt to the microcontroller. This interrupt indicates that a command is available in the mailbox. The microcontroller is responsible for reading from and responding to the command.

When a mailbox is populated by the microcontroller, an output wire to the SoC indicates that a command is available in the mailbox. The SoC is responsible for reading from and responding to the command.

Mailboxes are generic data-passing structures with a specific protocol that defines legal operations. This protocol for writing to and reading from the mailbox is enforced in hardware as described in the Caliptra mailbox errors section. How the command and data are interpreted by the microcontroller and SoC are not enforced in this specification.

Sender Protocol

Sending data to the mailbox:

1. Requester queries the mailbox by reading the LOCK control register.
   1. If LOCK returns 0, LOCK is granted and will be set to 1.
   2. If LOCK returns 1, MBOX is locked for another device.
2. Requester writes the command to the COMMAND register.
3. Requester writes the data length in bytes to the DLEN register.
4. Requester writes data packets to the MBOX DATAIN register.
5. Requester writes to the EXECUTE register.
6. Requester reads the STATUS register. Status can return:
   1. CMD_BUSY - 2’b00 – Indicates the requested command is still in progress
   2. DATA_READY - 2’b01 – Indicates the return data is in the mailbox for requested command
   3. CMD_COMPLETE- 2’b10 – Indicates the successful completion of the requested command
   4. CMD_FAILURE- 2’b11 – Indicates the requested command failed
7. Requester reads the response if DATA_READY was the status.
8. Requester resets the EXECUTE register to release the lock.

Notes on behavior:

Once LOCK is granted, the mailbox is locked until that device has concluded its operation. Caliptra has access to an internal mechanism to terminate a lock early or release the lock if the device does not proceed to use it or to recover from deadlock scenarios. The following figure shows the sender protocol flow.

Figure: Sender protocol flow chart

Receiver Protocol

Upon receiving indication that mailbox has been populated, the appropriate device can read the mailbox. This is indicated by a dedicated wire that is asserted when Caliptra populates the mailbox for SoC consumption.

Caliptra will not initiate any mailbox commands that require a response from the SoC. Caliptra initiated mailbox commands are “broadcast” and available to any user on the SoC. SoC will not be able to write the DLEN or DATAIN register while processing a Caliptra initiated mailbox command.

Receiving data from the mailbox:

1. On mailbox_data_avail assertion, the receiver reads the COMMAND register.
2. Receiver reads the DLEN register.
3. Receiver reads the CMD register.
4. Receiver reads the MBOX DATAOUT register.
   • Continue reading MBOX DATAOUT register until DLEN bytes are read.
5. If a response is required, the receiver can populate the mailbox with the response by updating the DLEN register and writing to DATAIN with the response. (NOTE: The new DLEN value will not take effect until control is returned to the sender via write to the status register).
6. Set the mailbox status register appropriately to hand control back to the sender.
7. The sender will reset the EXECUTE register.
   • This releases the LOCK on the mailbox.

The following figure shows the receiver protocol flow.

Figure: Receiver protocol flowchart

TAP mailbox mode

When Caliptra sets the tap_mode register, the mailbox will transition from RDY_FOR_DATA to EXECUTE_TAP instead of EXECUTE_SOC. This will pass control of the mailbox to the TAP. TAP will follow the Receiving data from the mailbox protocol detailed above.

When TAP acquires the mailbox lock, the mailbox will transition from RDY_FOR_DATA_to EXECUTE_UC. This transition results in the assertion of the internal interrupt signal uc_mailbox_data_avail to UC. This will pass control of the mailbox to the UC. UC will follow the Receiving data from the mailbox protocol detailed above.

Mailbox arbitration

From a mailbox protocol perspective, as long as CPTRA_VALID_AXI_USER registers carry valid requesters, mailbox lock can be obtained by any of those valid requesters but only one of them at any given time. While the mailbox flow is happening, all other requesters will not get a grant.

A request for lock that is denied due to firmware having the lock results in an interrupt to the firmware. Firmware can optionally use this interrupt to release the lock.

There is no fair arbitration scheme between SoC and microcontroller. It is first come, first served. When the mailbox is locked for microcontroller use and SoC has unsuccessfully requested the mailbox (due to mailbox actively being used), the mailbox generates an interrupt to the microcontroller as a notification.

Further, there is no arbitration between various AXI_USER attributes. AXI_USER attributes exist for security and filtering reasons only.

MAILBOX AXI USER attribute register

It is strongly recommended that these AXI_USER registers are either set at integration time through integration parameters or be programmed by the SoC ROM before any mutable firmware or ROM patches are applied.

SoC SHALL not use value 0xFFFFFFFF as a valid AXI user value for any of the below settings. This is reserved for Caliptra-internal usage.

Programmable registers

Caliptra provides 5 programmable registers that SoC can set at boot time to limit access to the mailbox peripheral. The default AXI_USER set by the integration parameter CPTRA_DEF_MBOX_VALID_AXI_USER is valid at all times. CPTRA_MBOX_VALID_AXI_USER registers become valid once the corresponding lock bit CPTRA_MBOX_AXI_USER_LOCK is set.

Table 15: AXI_USER register definition

Parameter override

Another option for limiting access to the mailbox peripheral are the integration time parameters that override the programmable AXI_USER registers. At integration time, the CPTRA_SET_MBOX_AXI_USER_INTEG parameters can be set to 1 which enables the corresponding CPTRA_MBOX_VALID_AXI_USER parameters to override the programmable register.

Table 16: AXI_USER Parameter definition

Caliptra mailbox protocol

After the SoC side has written the EXECUTE register, the mailbox sends an interrupt to the microcontroller.

The microcontroller reads the COMMAND and DLEN registers, as well as the data populated in the mailbox.

The microcontroller can signal back to SoC through functional registers, and populate COMMAND, DLEN, and MAILBOX as well.

Caliptra mailbox errors

Mailbox is responsible for only accepting writes from the device that requested and locked the mailbox.

If the SoC violates this protocol, the mailbox flags a protocol violation and enters an error state. Two protocol violations are detected:

1. Access without lock: Writes to any mailbox register by SoC or reads from the dataout register, without having first acquired the lock, are a violation.
   1. If any agent currently has the lock, accesses by agents other than the one holding the lock are ignored.
   2. If no agent currently has the lock, the violation results in a flagged error.
2. Out of order access: SoC must follow the rules for the sender and receiver protocol that define access ordering and progression for a mailbox command.
   1. If, after acquiring the lock, an SoC agent performs any register write (or read from the dataout register) outside of the prescribed ordering, this is a flagged violation.
   2. Such access by any SoC agent that does not have the lock is ignored.

After a mailbox protocol violation is flagged, it is reported to the system in several ways:

• The mailbox FSM enters the ERROR state in response to an out of order access violation, and the new FSM state is readable via the mailbox status register. The LOCK value is preserved on entry to the ERROR state. The access without lock violation does not result in a state change. After entering the ERROR state, the mailbox may only be restored to the IDLE state by:

  • System reset
  • Write to the force unlock register by firmware inside Caliptra (via internal bus)

  Either of these mechanisms will also clear the mailbox LOCK.

• Mailbox protocol violations are reported as fields in the HW ERROR non-fatal register. These events also cause assertion of the cptra_error_non_fatal interrupt signal to SoC. Upon detection, SoC may acknowledge the error by clearing the error field in this register via bus write.

• Mailbox protocol violations generate an internal interrupt to the Caliptra microcontroller. Caliptra firmware is aware of the protocol violation.

The following table describes AXI transactions that cause the Mailbox FSM to enter the ERROR state, given that the register “mbox_user” contains the value of the AXI USER that was used to originally acquire the mailbox lock.

Table 17: Mailbox protocol error trigger conditions

* mbox_user value is not used when Caliptra has lock and is sending a Caliptra to SoC mailbox operation.

SoC SHA acceleration block

Overview

The SHA acceleration block is in the SoC interface. The SoC can access the accelerator’s hardware API and stream data to be hashed over the AXI interface.

SHA acceleration block uses a similar protocol to the mailbox, but has its own dedicated registers. Caliptra is the only permitted user of SHA acceleration, either in streaming mode (via AXI) or in mailbox mode. Use of the SHA acceleration block over AXI is only available in Caliptra Subsystem, and is only available to Caliptra, which will access it via the AXI DMA block. The SHA accelerator checks the AXI AxUSER signal to block any access that originates from an agent other than Caliptra's AXI DMA.

SHA_LOCK register is set on read. A read of 0 indicates the SHA was unlocked and will now be locked for the requesting user.

SHA_MODE register sets the mode of operation for the SHA.

See the Hardware specification for additional details.

• 2’b00 - SHA384 streaming mode
• 2’b01 - SHA512 streaming mode
• 2’b10 - SHA384 mailbox mode (Caliptra only, invalid for SoC requests)
• 2’b11 - SHA512 mailbox mode (Caliptra only, invalid for SoC requests)

SoC Sender Protocol

Sending data to the SHA accelerator:

1. Requester queries the accelerator by reading the SHA_LOCK control register.
   • If SHA_LOCK returns 0, SHA_LOCK is granted and is set to 1.
   • If SHA_LOCK returns 1, it is locked for another device.
2. Requester writes the SHA_MODE register to the appropriate mode of operation.
3. Requester writes the data length in bytes to the SHA_DLEN register.
4. Requester writes data packets to the SHA_DATAIN register until SHA_DLEN bytes are written.
5. Requester writes the SHA_EXECUTE register, this indicates that it is done streaming data.
6. Requesters can poll the SHA_STATUS register for the VALID field to be asserted.
7. Once VALID is asserted, the completed hash can be read from the SHA_DIGEST register.
8. Requester must write 1 to the LOCK register to release the lock.

TRNG REQ HW API

For SoCs that choose to not instantiate Caliptra’s internal TRNG, we provide a TRNQ REQ HW API.

While the use of this API is convenient for early enablement, the current Caliptra hardware is unable to provide the same security guarantees with an external TRNG. In particular, it is highly advisable to instantiate an internal TRNG if ROM glitch protection is important.

1. Caliptra asserts TRNG_REQ wire (this may be because Caliptra’s internal hardware or firmware made the request for a TRNG).
2. SoC writes the TRNG architectural registers.
3. SoC write a done bit in the TRNG architectural registers.
4. Caliptra deasserts TRNG_REQ.

Having an interface that is separate from the SoC mailbox ensures that this request is not intercepted by any SoC firmware agents (which communicate with SoC mailbox). It is a requirement for FIPS compliance that this TRNG HW API is always handled by SoC hardware gasket logic (and not some SoC ROM or firmware code).

TRNG DATA register is tied to TRNG VALID AXI USER. SoC can program the TRNG VALID AXI USER and lock the register using TRNG_AXI_USER_LOCK[LOCK]. This ensures that TRNG DATA register is read-writeable by only the AXI USER programmed into the TRNG_VALID_AXI_USER register. If the CPTRA_TNRG_AXI_USER_LOCK.LOCK is set to ‘0, then any agent can write to the TRNG DATA register. If the lock is set, only an agent with a specific TRNG_VALID_AXI_USER can write.

The ROM and firmware currently time out on the TRNG interface after 250,000 attempts to read a DONE bit. This bit is set in the architectural registers, as referenced in 3 in the preceding list.

Internal TRNG

TRNG self-test ROM configuration

The internal TRNG is configured by the ROM to extract entropy used to initialize Control Flow Integrity (CFI) countermeasures. Since the ROM does not use entropy for any cryptographic operations, the TRNG self-tests are not configured for FIPS compliance, but rather to ensure that the quality of the entropy output is sufficient for ROM operation.

The default self-test parameters are provided to the ROM via the CPTRA_iTRNG_ENTROPY_CONFIG0 and CPTRA_iTRNG_ENTROPY_CONFIG1 registers.

The ROM configures self tests with the following parameters.

Adaptive test

The adaptive self-test thresholds are configured as follows if the high and low thresholds provided in the CPTRA_iTRNG_ENTROPY_CONFIG0 are non-zero.

entropy_src.ADAPTP_HI_THRESHOLDS.FIPS_THRESH = CPTRA_iTRNG_ENTROPY_CONFIG0.HIGH_THRESHOLD
entropy_src.ADAPTP_LO_THRESHOLDS.FIPS_THRESH = CPTRA_iTRNG_ENTROPY_CONFIG0.HIGH_THRESHOLD

Otherwise, the ROM will use 75% and 25% of the FIPS window size for the default high and low thresholds.

W = 2048 (bits)
entropy_src.ADAPTP_HI_THRESHOLDS.FIPS_THRESH = \(3 * (W / 4)\) = 1536
entropy_src.ADAPTP_LO_THRESHOLDS.FIPS_THRESH = \(W / 4\) = 512

It is strongly recommended to avoid using the default values.

Repetition count test

Caliptra supports two implementations of the repetition count test, one that counts repetitions per physical noise source (REPCNT); and, another that counts repetitions at the symbol level (REPCNTS). The ROM configures the REPCNT version.

The self-test is configured as follows if the CPTRA_iTRNG_ENTROPY_CONFIG1 register is not zero.

entropy_src.REPCNT_THRESHOLDS.FIPS_THRESH = CPTRA_iTRNG_ENTROPY_CONFIG1.REPETITION_COUNT

Otherwise, the ROM will use a default value configuration:

entropy_src.REPCNT_THRESHOLDS.FIPS_THRESH = 41

It is strongly recommended to avoid using the default values.

Recommended TRNG self-test thresholds

The thresholds should be tuned to match the entropy estimate of the noise source (H), which is calculated by applying a NIST-approved entropy estimate calculation against raw entropy extracted from the target silicon.

Important: It is important to note that the TRNG will discard samples that do not pass any of the health tests. Since there is a compression function requiring 2048 bits of good entropy to produce a 384 bit seed, the ROM may stall if the self-test thresholds are too aggressive or if the values are misconfigured. To avoid boot stall issues, it is strongly recommended to characterize the noise source on target silicon and select reliable test parameters. The ROM only needs to provide sufficient entropy for countermeasures, so FIPS-level checks can be performed later, in a less boot-timing-sensitive stage.

The following sections illustrate the self-test parameter configuration. The entropy_src block provides additional tests, but Caliptra's ROM focuses primarily on the adaptive and repetition count (REPCNT) tests. All other tests are left with their reset value configuration, which is equivalent to running the test with the most permissive settings.

Test parameters

The variable names are as defined in NIST SP 800-90B.

\(α = 2^{-40}\) (recommended)
\(H = 0.5\) (example, implementation specific)
\(W = 2048\) (constant in ROM/hw)

Adaptive proportion test

The test is configured with to sum all the bits per symbol, due to entropy_src.CONF.THRESHOLD_SCOPE being enabled. The test essentially treats the combined input as a single binary stream, counting the occurrences of '1's.

Note: The critbinom function (critical binomial distribution function) is implemented by most spreadsheet applications.

CPTRA_iTRNG_ENTROPY_CONFIG0.high_threshold = \(1 + critbinom(W, 2^{-H}, 1 - α)\)
CPTRA_iTRNG_ENTROPY_CONFIG0.high_threshold = \(1 + critbinom(2048, 2^{-H}, 1 - 2^{-40})\)
CPTRA_iTRNG_ENTROPY_CONFIG0.high_threshold = 1591

CPTRA_iTRNG_ENTROPY_CONFIG0.low_threshold = W - CPTRA_iTRNG_ENTROPY_CONFIG0.high_threshold
CPTRA_iTRNG_ENTROPY_CONFIG0.low_threshold = 2048 - CPTRA_iTRNG_ENTROPY_CONFIG0.high_threshold
CPTRA_iTRNG_ENTROPY_CONFIG0.low_threshold = 457

Repetition count threshold

The repetition count test as configured in the ROM makes no FIPS compliance claims due to the fact that counts are aggregated for each individual bit. This results in a less restrictive threshold as the test will wait for 4x more repetitions before failing. From an entropy quality perspective, this is deemed acceptable for the current Caliptra release.

\[ \begin{aligned} & RcThresh = \frac{-log_2(α)}{H} + 1 \ & RcThresh = \frac{40}{H} + 1 \ & RcThresh = 81 \end{aligned} \]

CPTRA_iTRNG_ENTROPY_CONFIG1.repetition_count = RcThresh = 81

FIPS Compliance

Caliptra 1.x and 2.0 do not make any FIPS conformance claims on the self-tests configured by the ROM and executed by the internal TRNG. This is due to the test configuration. See previous sections for more details.

SRAM implementation

Overview

SRAMs are instantiated at the SoC level. Caliptra provides the interface to export SRAMs from internal components.

SRAM repair logic (for example, BIST) and its associated fuses, which are proprietary to companies and their methodologies, is implemented external to the Caliptra boundary.

SRAMs must NOT go through BIST or repair flows across a “warm reset”. SoC shall perform SRAM repair during a powergood cycling event ("cold reset") and only prior to deasserting cptra_rst_b. During powergood cycling events, SoC shall also initialize all entries in the SRAM to a 0 value, prior to deasserting caliptra_rst_b.

Mailbox SRAM is implemented with ECC protection. Data width for the mailbox is 32-bits, with 7 parity bits for a Hamming-based SECDED (single-bit error correction and double-bit error detection).

RISC-V internal memory export

To support synthesis flexibility and ease memory integration to various fabrication processes, all SRAM blocks inside the RISC-V core are exported to an external location in the testbench. A single unified interface connects these memory blocks to their parent logic within the RISC-V core. Any memory implementation may be used to provide SRAM functionality in the external location in the testbench, provided the implementation adheres to the interface requirements connected to control logic inside the processor. Memories behind the interface are expected to be implemented as multiple banks of SRAM, from which the RISC-V processor selects the target using an enable vector. The I-Cache has multiple ways, each containing multiple banks of memory, but I-Cache is disabled in Caliptra and this may be removed for synthesis.

The following memories are exported:

• Instruction Closely-Coupled Memory (ICCM)
• Data Closely Coupled Memory (DCCM)

Table 7 indicates the signals contained in the memory interface. Direction is relative to the exported memory wrapper that is instantiated outside of the Caliptra subsystem (that is, from the testbench perspective).

SRAM timing behavior

• [Writes] Input wren signal is asserted simultaneously with input data and address. Input data is stored at the input address 1 clock cycle later.
• [Reads] Input clock enable signal is asserted simultaneously with input address. Output data is available 1 clock cycle later from a flip-flop register stage.
• [Writes] Input wren signal is asserted simultaneously with input data and address. Data is stored at the input address 1 clock cycle later.

The following figure shows the SRAM interface timing.

Figure: SRAM interface timing

SRAM parameterization

Parameterization for ICCM/DCCM memories is derived from the configuration of the VeeR RISC-V core that has been selected for Caliptra integration. Parameters defined in the VeeR core determine signal dimensions at the Caliptra top-level interface and drive requirements for SRAM layout. For details about interface parameterization, see the Interface section. Complete configuration parameters of the RISC-V Core may be found in common_defines.sv. The following table explains some parameters that are used to derive interface signal widths for exported RISC-V SRAM signals.

Table 18: SRAM parameterization

Example SRAM machine check reliability integration

This section describes an example implementation of integrator machine check reliability.

This example is applicable to scenarios where an integrator may need control of or visibility into SRAM errors for purposes of reliability or functional safety. In such cases, integrators may introduce additional layers of error injection, detection, and correction logic surrounding SRAMs. The addition of such logic is transparent to the correct function of Caliptra, and removes integrator dependency on Caliptra for error logging or injection.

Note that the example assumes that data and ECC codes are in non-deterministic bit-position in the exposed SRAM interface bus. Accordingly, redundant correction coding is shown in the integrator level logic (i.e., integrator_ecc(caliptra_data, caliptra_ecc)). If the Caliptra data and ECC are deterministically separable at the Caliptra interface, the integrator would have discretion to store the ECC codes directly and calculate integrator ECC codes for the data alone.

Figure: Example machine check reliability implementation

Error detection and logging

1. Caliptra IP shall interface to ECC protected memories.
2. Caliptra IP calculates and applies its own ECC code, which produces a total of 39-bit data written to external or INTEGRATOR instantiated SRAMs.
3. Each 39-bit bank memory internally calculates 8-bit ECC on a write and stores 47 bits of data with ECC into SRAM.
4. On read access syndrome is calculated based on 39-bit data.
5. If parity error is detected and syndrome is valid, then the error is deemed single-bit and correctable.
6. If no parity error is detected but syndrome == 0 or the syndrome is invalid, the error is deemed uncorrectable.
7. On both single and double errors, the read data is modified before being returned to Caliptra.
8. Since single-bit errors shall be corrected through INTEGRATOR instantiated logic, Caliptra never sees single-bit errors from SRAM.
9. Double-bit or uncorrectable errors would cause unpredictable data to be returned to Caliptra. Since this condition shall be detected and reported to MCRIP, there is no expectation that Caliptra will operate correctly after a double error.
10. On detection, single errors are reported as transparent to MCRIP, double errors are reported as fatal.
11. Along with error severity, MCRIP logs physical location of the error.
12. After MCRIP logs an error, it has a choice to send out in-band notification to an external agent.
13. MCRIP logs can be queried by SoC software.

Error injection

1. MCRIP supports two error injection modes: intrusive and non-intrusive.
2. Intrusive error injection:
   1. Can force a single or double error to be injected, which would result in incorrect data to be returned on read access.
   2. The intrusive error injection mode is disabled in Production fused parts via Security State signal.
3. Non-intrusive error injection:
   1. Allows external software to write into MCRIP error log registers.
   2. The non-intrusive error injection does not interfere with the operation of memories.
   3. The non-intrusive error injection is functional in Production fused parts.

Caliptra error handling flow

1. Any implementation of error and recovery flows must adhere to the error handling requirements specified in Caliptra.md
2. SoC level reporting and handling of fatal & non-fatal errors is product-specific architecture, outside the scope of Caliptra core definition. For example, a CPU and a PCIe device may handle fatal and non-fatal errors differently.

SoC integration requirements

The following table describes SoC integration requirements.

For additional information, see Caliptra assets and threats.

Table 19: SoC integration requirements

Table 20: Caliptra synthesis warnings for FEV evaluation

OCP LOCK Caliptra ROM & Firmware Requirements

The following rules outline additional steps that are divided between Caliptra ROM and Caliptra Runtime firmware to ensure secure operation protocol compliance to OCP L.O.C.K. As described in the Caliptra Hardware Specification, when operating in OCP LOCK mode Key Vault slot 16 (KV16) is designated for holding the MDK and Key Vault slot 23 (KV23) is designated for holding the MEK.

• DOE error status (KV write failure):
  Introduce a new status bit; ROM must check it after any DOE flow to ensure the KV write succeeded.
• HEK DOE flow:
  Must be locked after execution (like other DOE flows). ROM must run the HEK DOE flow even in non-LOCK contexts to lock it. Reset only by hard reset.
• Derivations & locking:
  • Derive the MDK to KV16, then set the lock_wr control bit of KV16.
  • If OCP LOCK is enabled, derive HEK to KV22, then set the lock_wr control bit of KV23.
    • Perform this before setting OCP_LOCK_IN_PROGRESS since HEK derivation depends on the HEK seed and standard CDI derivatives (from standard KV slots).
• Setting lock state:
  If OCP LOCK is enabled, ROM MUST set OCP_LOCK_IN_PROGRESS before transitioning to the First Mutable Code (FMC) image.
• KV23 usage constraints:
  Never attempt to write anything to KV23 except MEK (produced by AES).
  • DOE will flag an error and stall if a write to KV23 is attempted while OCP LOCK is enabled. Note that this differs from other cryptographic engines, which use the SS_OCP_LOCK_CTRL.LOCK_IN_PROGRESS bit to enforce the respective ruleset. This is because HEK seed deobfuscation is performed by the ROM prior to setting LOCK_IN_PROGRESS.
• DMA programming with KV:
  The programmed byte count must match the value on the input strap_ss_key_release_key_size strap. The programmed destination address must match the value on the input strap_ss_key_release_base_addr. Violation of either of these rules will trigger a command decode error in the DMA.
• KV filtering rules:
  Cryptographic operations attempting to read from a Standard Key Vault slot and write a result to a LOCK Key Vault slot will fail (the same rule holds for the LOCK Key Vault slot → Standard Key Vault slot path). The error status is reported as a Key Vault Write failure in the respective cryptographic engine's register block.
• AES API updates:
  • Similar to all cryptographic core operations in Caliptra, firmware must set both the Key Vault Read Control and Key Vault Write Control registers prior to beginning the AES operation.
  • When AES operation parameters match the configuration for which output data is written to KV23, result data is masked from being presented on the dataout register. Also, the STATUS.OUTPUT_LOST register bit will be asserted to reflect that output data has been blocked.
  • AES operations used to decrypt Key Content into KV23 must be performed using automatic mode; manual operation is not supported for this process.
  • Firmware shall execute the clear operation after any AES operation used to generate or load the MEK.
• Strap validation:
  Read and confirm valid values for:
  • SS_KEY_RELEASE_BASE_ADDR
  • KEY_RELEASE_KEY_SIZE
• Firmware must clear any obfuscated MEK from memory immediately after use.

Integrator RTL modification requirements

Several files contain code that may be specific to an integrator's implementation and should be overridden. This overridable code is either configuration parameters with integrator-specific values or modules that implement process-specific functionality. Code in these files should be modified or replaced by integrators using components from the cell library of their fabrication vendor. The following table describes recommended modifications for each file.

Table 21: Caliptra integrator custom RTL file list

Synthesis Constraints

To ensure the integrity of security countermeasures, silicon integrators must apply size_only (or an equivalent) constraint to all cells whose instance names contain the u__size_only__ tag. This prevents synthesis and Place-and-Route (PNR) tools from optimizing away critical redundant logic.

Primitive Instantiation

Caliptra uses redundant logic to counteract Fault Injection (FI) and Side Channel Analysis (SCA). This logic is built using generic primitive modules, which act as placeholders. Integrators must replace these generic primitives with corresponding technology-specific cells from their standard cell library. This abstraction allows for applying the necessary constraints directly to the technology cells.

The following generic primitives require replacement with technology-specific cells. Ensure the instance names for these replacement cells include the u__size_only__ tag, as shown in the example below.

• caliptra_prim_generic_and2
• caliptra_prim_generic_buf
• caliptra_prim_generic_clock_mux2
• caliptra_prim_generic_xnor2
• caliptra_prim_generic_xor2
• caliptra_prim_generic_flop
• caliptra_prim_generic_flop_en

To integrate technology-specific replacements, set the CALIPTRA_PRIM_MODULE_PREFIX and CALIPTRA_PRIM_ROOT environment variables. For details on how CALIPTRA_PRIM_MODULE_PREFIX is used to select between generic and technology-specific modules, see the implementation in caliptra_prim_module_name_macros.svh.

Example: Technology-Specific Buffer

The following example shows how to create a technology-specific wrapper for the caliptra_prim_generic_buf primitive.

// In this example:
// - `CALIPTRA_PRIM_MODULE_PREFIX` is assumed to be `caliptra_prim_tech_name`.
// - `TECH_DEPENDENT_BUF` is the name of the technology-specific buffer cell.
// - `PORT_NAME_IN` and `PORT_NAME_OUT` are its input and output ports.

module caliptra_prim_tech_name_buf #(
  parameter int Width = 1
) (
  input  logic [Width-1:0] in_i,
  output logic [Width-1:0] out_o
);

  for (genvar k = 0; k < Width; k++) begin : gen_bufs
    // The instance name "u__size_only__buf" contains the required tag.
    // Synthesis tools must be configured to apply "size_only"
    // constraints to any instance whose name includes "u__size_only__".
    // This naming convention should be used for all replaced primitives.

    TECH_DEPENDENT_BUF u__size_only__buf (
      .<PORT_NAME_IN>(in_i[k]),
      .<PORT_NAME_OUT>(out_o[k])
    );
  end

endmodule : caliptra_prim_tech_name_buf

CDC analysis and constraints

Clock Domain Crossing (CDC) analysis is performed on the Caliptra core IP. The following are the results and recommended constraints for Caliptra integrators using standard CDC analysis EDA tools.

In an unconstrained environment, several CDC violations are anticipated. CDC analysis requires the addition of constraints to identify valid synchronization mechanisms and/or static/pseudo-static signals.

Analysis of missing synchronizers

• All of the signals, whether single-bit or multi-bit, originate from the CaliptraClockDomain clock and their endpoint is the JTAG clock domain.
• The violations occur on the read path to the JTAG.
• We only need to synchronize the controlling signal for this interface.
• Inside the dmi_wrapper, the dmi_reg_en and dmi_reg_rd_en comes from dmi_jtag_to_core_sync, which is a 2FF synchronizer.

The following code snippets and schematic diagrams illustrate the CDC violations that end at the JTAG interface.

Figure: Schematic diagram and code snippet showing JTAG-originating CDC violations

CDC analysis conclusions

• Missing synchronizers appear to be the result of “inferred” and/or only 2-FF instantiated synchronizers.
  • dmi_jtag_to_core_sync.v contains inferred 2FF synchronizers on the control signals “dmi_reg_wr_en” and “dmi_reg_rd_en”.
  • 2FF synchronizer inferences are considered non-compliant and should be replaced by an explicitly instantiated synchronization module, which is intended to be substituted on a per-integrator basis.
    • cdc report scheme two_dff -severity violation
• Multi-bit signals are effectively pseudo-static and are qualified by synchronized control qualifiers.
  • Pseudo-static: wr_data, wr_addr
    • cdc signal reg_wr_data -module dmi_wrapper -stable
    • cdc signal reg_wr_addr -module dmi_wrapper -stable
• The core clock frequency must be at least twice the TCK clock frequency for the JTAG data to pass correctly through the synchronizers.

CDC constraints

• cdc report scheme two_dff -severity violation
• cdc signal reg_wr_data -module dmi_wrapper -stable
• cdc signal reg_wr_addr -module dmi_wrapper -stable
• cdc signal rd_data -module dmi_wrapper -stable

RDC analysis and constraints

Reset Domain Crossing (RDC) analysis is performed on the Caliptra core IP. The following are the results and recommended constraints for Caliptra integrators using standard RDC analysis EDA tools.

In an unconstrained environment, several RDC violations are anticipated. RDC analysis requires the addition of constraints to identify valid synchronization mechanisms from one reset domain to another.

Constraining reset domains

Reset domains

The following table identifies the major reset domains in Caliptra core IP design.

Table 22: Reset definitions (functional resets are marked in bold)

Reset structure

The reset definitions can be visually represented as shown in the following diagram.

Figure: Reset tree for Caliptra

RDC false paths

The following table shows the false paths between various reset groups.

Table 23: Reset domain crossing false paths

Reset sequencing scenarios

The resets defined in Table 22 have the following sequencing phases, which are applicable for different reset scenarios: cold boot, cold reset, warm reset and firmware reset.

The reset sequencing is illustrated in the following waveform.

Figure: Reset sequencing waveform for Caliptra

Reset ordering

The following table defines the order in which resets can get asserted. A ">>" in a cell at row X and column Y indicates that if the reset in row X is asserted, the reset in row Y is also asserted. For rest of the cells (in which symbol ">>" is not present) the preceding assumption is not true and so the paths between those resets are potential RDC violations. The black cells are ignored because they are between the same resets.

Table 24: Reset sequence ordering constraints

Reset constraints and assumptions

The following set of constraints and assumptions must be provided before running RDC structural analysis of Caliptra Core IP.

1. Caliptra Core IP assumes the primary reset inputs are already synchronized to their respective clocks. The integrator must add external reset synchronizers to achieve the same.
   • cptra_pwrgood and cptra_rst_b resets must be synchronized to cptra_clk
   • Deassertion of jtag_trst_n reset must be synchronized to jtag_clk. The signal can be asserted asynchronously.
2. The following debug register, which is driven from JTAG, is not toggled during functional flow.
   • u_caliptra.rvtop.veer.dbg.dmcontrol_reg[0] = 0
3. Set scan_mode to 0 for functional analysis.
4. Stamp or create functional resets for cptra_noncore_rst_b and cptra_uc_rst_b at the definition points, as mentioned in Table 22.
5. Create funtional reset grouping - This step must be customized as per the EDA tool, which is being used for RDC analysis. The goal of this customization is to achieve the following three sequencing requirements/constraints.
   • Gate all clocks when cptra_noncore_rst_b is asserted. This ensures that the capture flop clock is gated while the source flop's reset is getting asserted, thereby preventing the capture flop from becoming metastable. The result is when cptra_noncore_rst_b is going to be asserted, the following signals are constrained to be at 1 at around that time.
     • soc_ifc_top1.i_soc_ifc_boot_fsm.rdc_clk_dis
     • soc_ifc_top1.i_soc_ifc_boot_fsm.arc_IDLE
   • Gate Veer core clock when cptra_uc_rst_b is asserted. This ensures that the capture flop clock is gated while the source flop's reset is getting asserted, thereby preventing the capture flop from becoming metastable. The result is when cptra_uc_rst_b is going to be asserted, the following signal is constrained to be at 1 at around that time.
     • soc_ifc_top1.i_soc_ifc_boot_fsm.fw_update_rst_window
   • Quiesce the AHB bus before cptra_uc_rst_b is asserted. Since the firmware reset request is triggered by software, it can ensure that all AHB transcations are flushed out before initiating a reset request. This is done by generating a signal, fw_update_rst_window, which is asserted (driven to 1) around the firmware reset assertion edge. When fw_update_rst_window is asserted, the force_bus_idle signal of the AHB decoder is driven to 1, which ensures that all AHB requestes are driven low. So when cptra_uc_rst_b is going to get asserted, the following signals are constrained to be at 0 at around that time.
     • doe.doe_inst.i_doe_reg.s_cpuif_req
     • ecc_top1.ecc_reg1.s_cpuif_req
     • hmac.hmac_inst.i_hmac_reg.s_cpuif_req
     • key_vault1.kv_reg1.s_cpuif_req
     • pcr_vault1.pv_reg1.s_cpuif_req
     • data_vault1.dv_reg1.s_cpuif_req
     • sha512.sha512_inst.i_sha512_reg.s_cpuif_req
     • soc_ifc_top1.i_ahb_slv_sif_soc_ifc.dv
     • sha256.sha256_inst.i_sha256_reg.s_cpuif_req
     • csrng.u_reg.u_ahb_slv_sif.dv
     • entropy_src.u_reg.u_ahb_slv_sif.dv
     • aes_inst.ahb_slv_sif_inst.dv
     • aes_inst.aes_clp_reg_inst.s_cpuif_req
   • The AES Core State Machine is assumed to be in the IDLE state
     • aes_inst.aes_inst.u_aes_core.u_aes_control.gen_fsm[0].gen_fsm_p.u_aes_control_fsm_i.u_aes_control_fsm.aes_ctrl_cs[5:0] = 6'b1001
6. Constrain the RDC false paths as per Table 23.

RDC violations and waivers

Considering the given constraints, three sets of crossings were identified as RDC violations. All of them can be waived as explained in Table 25. Note that the report may differ across EDA tools due to variations in structural analysis, which can be influenced by a range of settings.

Table 25: Reset domain crossing violations

For violations in Sl No 1 and 2, the schematic for the crossing is shown in the following figure.

Figure: Schematic for RDC violations #1 and #2

This violation can be waived because if the CPU is halted, there is no way to trigger a firmware update reset as it is initiated by the microcontroller itself. Thus, it can be ensured that on cptra_uc_rst_b, cpu_halt_status will be at the reset value already, which in turn ensures that there are no glitches on the output clock of CG.

For violations in Sl No 3 and 4, the schematic for the crossing is shown in the following figure.

Figure: Schematic for RDC violations #3 and #4

In the preceding schematic, an RDC crossing violation is identified at the data_q flop, which is located on the right-hand side of the figure. The analysis for prim_packer_fifo_bypass is elaborated here, with the same scenario applying to prim_packer_fifo_recon.

The fifo load and wr_data equations are as follows:

Table 26: Reset domain crossing scenarios for #3 and #4 crossing

Referring to the preceding table, if it can be ensured that fw_ov_fifo_wr_pulse is 0 when cptra_uc_rst_b is asserted, RDC crossings (Case #3) can be avoided. This condition is described in the preceding Constraints section.

For violation in Sl No 5, SOC should ensure that there are no active transactions on the AXI interface while asserting cptra_rst_b.

Synthesis findings

Synthesis has been performed at CALIPTRA_WRAPPER level which encompasses the following :-

• caliptra_top
• Memories instantiated outside using tech specific macros

Design converges at 400MHz 0.72V using an industry standard, advanced technology node as of 2025 April.

Note: Any synthesis warnings of logic optimization must be reviewed and accounted for.

Netlist synthesis data

The following table illustrates representative netlist synthesis results using industry standard EDA synthesis tools and tool configurations.

These metrics are inclusive of VeeR core, Caliptra logic, imem/dmem RAM, ROM.

The area is expressed in units of square microns.

The target foundry technology node is an industry standard, advanced technology node as of 2025 April.

Table 27: Netlist synthesis data

ROM area is not accounted for in the above table.

NOTE: RTL2Syn formality is not run as of now, we will update the results once we have run the flow.

Recommended LINT rules

A standardized set of lint rules is used to sign off on each release. The lint policy may be provided directly to integrators upon request to ensure lint is clean in the SoC.

Terminology

The following terminology is used in this document.

Table 28: Terminology