v2.0: Caliptra_mbox_boot_FSM.png
v2.1: Caliptra_mbox_boot_FSM.png
Image not present in this version
| @@ -1,12 +1,12 @@ | |||
| 1 | 1 | <div style="font-size: 0.85em; color: #656d76; margin-bottom: 1em; padding: 0.5em; background: #f6f8fa; border-radius: 4px;"> | |
| 2 | -📄 Source: <a href="https://github.com/chipsalliance/caliptra-rtl/blob/35b0bc5691b2bd0fc180403914cfabe207379089/docs/CaliptraIntegrationSpecification.md" target="_blank">chipsalliance/caliptra-rtl/docs/CaliptraIntegrationSpecification.md</a> @ <code>35b0bc5</code> | ||
| 2 | +📄 Source: <a href="https://github.com/chipsalliance/caliptra-rtl/blob/6ec0e25bc206d6a192a59c4dba98c7fee682da70/docs/CaliptraIntegrationSpecification.md" target="_blank">chipsalliance/caliptra-rtl/docs/CaliptraIntegrationSpecification.md</a> @ <code>6ec0e25</code> | ||
| 3 | 3 | </div> | |
| 4 | 4 | ||
| 5 | 5 |  | |
| 6 | 6 | ||
| 7 | 7 | <p style="text-align: center;">Caliptra Integration Specification</p> | |
| 8 | 8 | ||
| 9 | -<p style="text-align: center;">Version 2.0.3</p> | ||
| 9 | +<p style="text-align: center;">Version 2.1</p> | ||
| 10 | 10 | ||
| 11 | 11 | <div style="page-break-after: always"></div> | |
| 12 | 12 | ||
| @@ -31,7 +31,7 @@ | |||
| 31 | 31 | | IP/Block | GitHub URL | Documentation | Link | | |
| 32 | 32 | | :--------- | :--------- | :--------- | :--------- | | |
| 33 | 33 | | Cores-VeeR | [GitHub - chipsalliance/Cores-VeeR-EL2](https://github.com/chipsalliance/Cores-VeeR-EL2) | VeeR EL2 Programmer’s Reference Manual | [chipsalliance/Cores-VeeR-EL2 · GitHubPDF](http://cores-swerv-el2/RISC-V_SweRV_EL2_PRM.pdf%20at%20master%20%C2%B7) | | |
| 34 | -| AHB Lite Bus | [aignacio/ahb_lite_bus: AHB Bus lite v3.0 (github.com)](https://github.com/aignacio/ahb_lite_bus) | AHB Lite Protocol<br> [Figure 1: SoC interface block diagram](#soc-interface-definition) | [ahb_lite_bus/docs at master · aignacio/ahb_lite_bus (github.com)](https://github.com/aignacio/ahb_lite_bus/tree/master/docs)<br> [ahb_lite_bus/diagram_ahb_bus.png at master · aignacio/ahb_lite_bus (github.com)](https://github.com/aignacio/ahb_lite_bus/blob/master/diagram_ahb_bus.png) | | ||
| 34 | +| AHB Lite Bus | [aignacio/ahb_lite_bus: AHB Bus lite v3.0 (github.com)](https://github.com/aignacio/ahb_lite_bus) | AHB Lite Protocol<br> [Figure: SoC interface block diagram](#soc-interface-definition) | [ahb_lite_bus/docs at master · aignacio/ahb_lite_bus (github.com)](https://github.com/aignacio/ahb_lite_bus/tree/master/docs)<br> [ahb_lite_bus/diagram_ahb_bus.png at master · aignacio/ahb_lite_bus (github.com)](https://github.com/aignacio/ahb_lite_bus/blob/master/diagram_ahb_bus.png) | | ||
| 35 | 35 | | SHA 256 | [secworks/sha256: Hardware implementation of the SHA-256 cryptographic hash function (github.com)](https://github.com/secworks/sha256) ||| | |
| 36 | 36 | | SHA 512 |||| | |
| 37 | 37 | | SPI Controller | <https://github.com/pulp-platform/axi_spi_master> ||| | |
| @@ -45,7 +45,7 @@ | |||
| 45 | 45 | ||
| 46 | 46 | The following figure shows the SoC interface definition. | |
| 47 | 47 | ||
| 48 | -*Figure 1: SoC Interface Block Diagram* | ||
| 48 | +*Figure: SoC Interface Block Diagram* | ||
| 49 | 49 | ||
| 50 | 50 |  | |
| 51 | 51 | ||
| @@ -68,7 +68,8 @@ | |||
| 68 | 68 | ||
| 69 | 69 | | **Defines** | **Defines file** | **Description** | | |
| 70 | 70 | | :--------- | :--------- | :--------- | | |
| 71 | -| CALIPTRA_INTERNAL_TRNG | config_defines.svh | Defining this enables the internal TRNG source. This must be set to 1 in Subsystem mode. | | ||
| 71 | +| CALIPTRA_FUSE_GRANULARITY_32 | config_defines.svh | Defining this means fuse row granularity is 32-bits. If not defined it means fuse row granularity is 64 bits. If defined, the ``CPTRA_HW_CONFIG.CALIPTRA_FUSE_GRANULARITY_32`` SOC_IFC register bit is set to 1 for 32-bit granularity. Otherwise, it is set to 0 for 64-bit granularity. This is used by Caliptra ROM for UDS and Field Entropy provisioning. | | ||
| 72 | +| CALIPTRA_INTERNAL_TRNG | config_defines.svh | Defining this enables the internal TRNG source. This is recommended to be set to 1 in Core (Passive) mode and must be set to 1 in Subsystem mode. | | ||
| 72 | 73 | | CALIPTRA_MODE_SUBSYSTEM | config_defines.svh | Defining this enables Caliptra to operate in Subsystem mode. This includes features such as the debug unlock flow, AXI DMA (for recovery flow), Subsystem-level straps, among other capabilites. See [Caliptra Subsystem Architectural Flows](https://github.com/chipsalliance/Caliptra/blob/main/doc/Caliptra.md#caliptra-subsystem-architectural-flows) for more details | | |
| 73 | 74 | | USER_ICG | config_defines.svh | If added by an integrator, provides the name of the custom clock gating module that is used in [clk_gate.sv](../src/libs/rtl/clk_gate.sv). USER_ICG replaces the clock gating module, CALIPTRA_ICG, defined in [caliptra_icg.sv](../src/libs/rtl/caliptra_icg.sv). This substitution is only performed if integrators also define TECH_SPECIFIC_ICG. | | |
| 74 | 75 | | TECH_SPECIFIC_ICG | config_defines.svh | Defining this causes the custom, integrator-defined clock gate module (indicated by the USER_ICG macro) to be used in place of the native Caliptra clock gate module. | | |
| @@ -110,7 +111,7 @@ | |||
| 110 | 111 | | rid | IW | Output | Synchronous to clk | R channel read response id signal | | |
| 111 | 112 | | ruser | UW | Output | Synchronous to clk | R channel read response user signal | | |
| 112 | 113 | | rlast | 1 | Output | Synchronous to clk | R channel read response last beat signal | | |
| 113 | -| rvalid | 1 | Output | Synchronous to clk | R channel valid handhsake signal | | ||
| 114 | +| rvalid | 1 | Output | Synchronous to clk | R channel valid handshake signal | | ||
| 114 | 115 | | rready | 1 | Input | Synchronous to clk | R channel ready handshake signal | | |
| 115 | 116 | | awaddr | AW | Input | Synchronous to clk | AW channel address | | |
| 116 | 117 | | awburst | 2 | Input | Synchronous to clk | AW channel burst encoding | | |
| @@ -119,18 +120,18 @@ | |||
| 119 | 120 | | awuser | UW | Input | Synchronous to clk | AW channel user signal. Identifies the requester for mailbox and fuse access. See AXI_USER details for more information. | | |
| 120 | 121 | | awid | IW | Input | Synchronous to clk | AW channel id signal | | |
| 121 | 122 | | awlock | 1 | Input | Synchronous to clk | AW channel lock signal | | |
| 122 | -| awvalid | 1 | Input | Synchronous to clk | AW channel valid handhsake signal | | ||
| 123 | +| awvalid | 1 | Input | Synchronous to clk | AW channel valid handshake signal | | ||
| 123 | 124 | | awready | 1 | Output | Synchronous to clk | AW channel ready handshake signal | | |
| 124 | 125 | | wdata | DW | Input | Synchronous to clk | W channel write data | | |
| 125 | 126 | | wuser | UW | Input | Synchronous to clk | W channel write user | | |
| 126 | 127 | | wstrb | DW/8 | Input | Synchronous to clk | W channel write strobe. Byte enable. | | |
| 127 | 128 | | wlast | 1 | Input | Synchronous to clk | W channel write last beat signal | | |
| 128 | -| wvalid | 1 | Input | Synchronous to clk | W channel valid handhsake signal | | ||
| 129 | +| wvalid | 1 | Input | Synchronous to clk | W channel valid handshake signal | | ||
| 129 | 130 | | wready | 1 | Output | Synchronous to clk | W channel ready handshake signal | | |
| 130 | 131 | | bresp | 2 | Output | Synchronous to clk | B channel write response encoding | | |
| 131 | 132 | | bid | IW | Output | Synchronous to clk | B channel write response id signal | | |
| 132 | 133 | | buser | UW | Output | Synchronous to clk | B channel write response user signal | | |
| 133 | -| bvalid | 1 | Output | Synchronous to clk | B channel valid handhsake signal | | ||
| 134 | +| bvalid | 1 | Output | Synchronous to clk | B channel valid handshake signal | | ||
| 134 | 135 | | bready | 1 | Input | Synchronous to clk | B channel ready handshake signal | | |
| 135 | 136 | ||
| 136 | 137 | ||
| @@ -183,7 +184,7 @@ | |||
| 183 | 184 | Strobe width describes the number of bits enabled by each strobe. All strobed memories are byte enabled in the design. | |
| 184 | 185 | See [ABR Memory requirement](https://github.com/chipsalliance/adams-bridge/blob/main/docs/AdamsBridgeHardwareSpecification.md#memory-requirement) for more details. | |
| 185 | 186 | ||
| 186 | -The full set of wires is encapsulated in the mldsa_mem_if construct mldsa_memory_export at the Caliptra boundary. | ||
| 187 | +The full set of wires is encapsulated in the abr_mem_if construct abr_memory_export at the Caliptra boundary. | ||
| 187 | 188 | ||
| 188 | 189 | The table below details the interface required for each SRAM. Driver direction is from the perspective of Caliptra. | |
| 189 | 190 | ||
| @@ -210,6 +211,7 @@ | |||
| 210 | 211 | ||
| 211 | 212 | ||
| 212 | 213 | *Table 10: RISC-V Trace interface* | |
| 214 | +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. | ||
| 213 | 215 | | Signal name | Width | Driver | Synchronous (as viewed from Caliptra’s boundary) | Description | | |
| 214 | 216 | | :--------- | :--------- | :--------- | :--------- | :--------- | | |
| 215 | 217 | | trace_rv_i_insn_ip | 32 | Output | Synchronous to clk | Trace signals from Caliptra RV core instance. Refer to VeeR documentation for more details. | | |
| @@ -221,23 +223,27 @@ | |||
| 221 | 223 | | trace_rv_i_tval_ip | 32 | Output | Synchronous to clk | Trace signals from Caliptra RV core instance. Refer to VeeR documentation for more details. | | |
| 222 | 224 | ||
| 223 | 225 | ||
| 224 | -*Table 11: Subsystem Straps and Control* | ||
| 226 | +*Table 11: Subsystem Straps, Controls, and iTRNG Configuration* | ||
| 225 | 227 | ||
| 226 | 228 | | Signal name | Width | Driver | Synchronous (as viewed from Caliptra’s boundary) | Description | | |
| 227 | 229 | | :---------- | :--------- | :--------- | :----------------------------------------------- | :--------- | | |
| 228 | 230 | | strap_ss_caliptra_base_addr | 64 | Input Strap | Synchronous to clk | Used in Subsystem mode only. In Passive mode, integrators shall tie this input to 0. | | |
| 229 | 231 | | strap_ss_mci_base_addr | 64 | Input Strap | Synchronous to clk | Used in Subsystem mode only. In Passive mode, integrators shall tie this input to 0. | | |
| 230 | 232 | | strap_ss_recovery_ifc_base_addr | 64 | Input Strap | Synchronous to clk | Used in Subsystem mode only. In Passive mode, integrators shall tie this input to 0. | | |
| 233 | +| strap_ss_external_staging_area_base_addr | 64 | Input Strap | Synchronous to clk | Used in Subsystem mode only. In Passive mode, integrators shall tie this input to 0. | | ||
| 231 | 234 | | strap_ss_otp_fc_base_addr | 64 | Input Strap | Synchronous to clk | Used in Subsystem mode only. In Passive mode, integrators shall tie this input to 0. | | |
| 232 | 235 | | strap_ss_uds_seed_base_addr | 64 | Input Strap | Synchronous to clk | Used in Subsystem mode only. In Passive mode, integrators shall tie this input to 0. | | |
| 236 | +| strap_ss_key_release_base_addr | 64 | Input Strap | Synchronous to clk | Used in Subsystem mode only. This is the full destination address for MEK generated via OCP LOCK flow. In Passive mode, integrators shall tie this input to 0. | | ||
| 237 | +| strap_ss_key_release_key_size | 64 | Input Strap | Synchronous to clk | Used in Subsystem mode only. This is the size of MEK generated via OCP LOCK flow. In Passive mode, integrators shall tie this input to 0. | | ||
| 233 | 238 | | strap_ss_prod_debug_unlock_auth_pk_hash_reg_bank_offset | 32 | Input Strap | Synchronous to clk | Used in Subsystem mode only. In Passive mode, integrators shall tie this input to 0. | | |
| 234 | 239 | | strap_ss_num_of_prod_debug_unlock_auth_pk_hashes | 32 | Input Strap | Synchronous to clk | Used in Subsystem mode only. In Passive mode, integrators shall tie this input to 0. | | |
| 235 | 240 | | strap_ss_caliptra_dma_axi_user | 32 | Input Strap | Synchronous to clk | Used in Subsystem mode only. In Passive mode, integrators shall tie this input to 0. | | |
| 236 | 241 | | strap_ss_strap_generic_0 | 32 | Input Strap | Synchronous to clk | Used in Subsystem mode only. In Passive mode, integrators shall tie this input to 0. | | |
| 237 | 242 | | strap_ss_strap_generic_1 | 32 | Input Strap | Synchronous to clk | Used in Subsystem mode only. In Passive mode, integrators shall tie this input to 0. | | |
| 238 | -| strap_ss_strap_generic_2 | 32 | Input Strap | Synchronous to clk | Used in Subsystem mode only. In Passive mode, integrators shall tie this input to 0. | | ||
| 243 | +| strap_ss_strap_generic_2 | 32 | Input Strap | Synchronous to clk | Formerly provided the Caliptra ROM with entropy source (CSRNG) configuration. That configuration has moved to the `CPTRA_iTRNG_ENTROPY_CONFIG_*` (ES0) and `CPTRA_iTRNG1_ENTROPY_CONFIG_*` (ES1) architectural registers and this strap is **no longer used for entropy-source configuration**. It remains available as a general-purpose late-binding strap; integrators shall tie this input to 0 if unused. | | ||
| 239 | 244 | | strap_ss_strap_generic_3 | 32 | Input Strap | Synchronous to clk | Used in Subsystem mode only. In Passive mode, integrators shall tie this input to 0. | | |
| 240 | -| ss_debug_intent | 1 | Input | Synchronous to clk | Sample on cold reset. Used in Subsystem mode only. Indicates that the SoC is in debug mode and a user intends to request unlock of debug mode through the TAP mailbox. In Passive mode, integrators shall tie this input to 0. | | ||
| 245 | +| ss_debug_intent | 1 | Input | Synchronous to clk | Sampled on cold reset. Used in Subsystem mode only. Indicates that the SoC is in debug mode and a user intends to request unlock of debug mode through the TAP mailbox. In Passive mode, integrators shall tie this input to 0. | | ||
| 246 | +| ss_ocp_lock_en | 1 | Input | Synchronous to clk | Sampled on cold reset. Used in Subsystem mode only. Indicates that the SoC enables OCP LOCK features of Caliptra. Must be tied to a constant value. For example, driving this input from a programmable register or from a package pin is not permitted. | | ||
| 241 | 247 | | ss_dbg_manuf_enable | 1 | Output | Synchronous to clk | Enables unlock of the debug interface in the Manufacturing security state, for Subsystem mode only. | | |
| 242 | 248 | | ss_soc_dbg_unlock_level | 64 | Output | Synchronous to clk | Enables unlock of the debug interface in the Production security state, for Subsystem mode only. | | |
| 243 | 249 | | ss_generic_fw_exec_ctrl | 128 | Output | Synchronous to clk | Enables SoC processors to execute firmware once authenticated by Caliptra. | | |
| @@ -250,22 +256,79 @@ | |||
| 250 | 256 | | Signal name | Width | Driver | Synchronous (as viewed from Caliptra’s boundary) | Description | | |
| 251 | 257 | | :--------- | :--------- | :--------- | :--------- | :--------- | | |
| 252 | 258 | | cptra_obf_key | 256 | Input Strap | Asynchronous | Obfuscation key is driven by SoC at integration time. Ideally this occurs just before tape-in and the knowledge of this key must be protected unless PUF is driving this. The key is latched by Caliptra upon first deassertion of the warm reset following caliptra powergood assertion. It is not resampled during subsequent warm resets, therefore the value is only captured upon a cold boot. It is cleared after its use and can only re-latched on a power cycle (powergood deassertion to assertion). | | |
| 253 | -| cptra_csr_hmac_key | 512 | Input Strap | Asynchronous | CSR HMAC key is driven by SoC at integration time. Ideally this occurs just before tape-in and the knowledge of this key must be protected. The key is latched by Caliptra on caliptra powergood assertion during DEVICE_MANUFACTURING lifecycle state. | | ||
| 259 | +| cptra_csr_hmac_key | 512 | Input Strap | Asynchronous | CSR HMAC key is driven by SoC at integration time. Ideally this occurs just before tape-in and the knowledge of this key must be protected. The key is latched by Caliptra following deassertion of the noncore warm reset during DEVICE_MANUFACTURING lifecycle state. This key input is ignored in all other lifecycle states. | | ||
| 254 | 260 | | cptra_obf_field_entropy_vld | 1 | Input | Synchronous to clk | Used in Subsystem mode only. In Passive mode, integrators shall tie this input to 0. Valid signal used to sample cptra_obf_field_entropy if it is driven by wires from the fuse controller. | | |
| 255 | 261 | | cptra_obf_field_entropy | 256 | Input | Synchronous to clk | Used in Subsystem mode only. In Passive mode, integrators shall tie this input to 0. Fuse controller can optionally drive the field entropy value over wires through this interface. The value is sampled after warm reset if the valid cptra_obf_field_entropy_vld is asserted. | | |
| 256 | 262 | | cptra_obf_uds_seed_vld | 1 | Input | Synchronous to clk | Used in Subsystem mode only. In Passive mode, integrators shall tie this input to 0. Valid signal used to sample cptra_obf_uds_seed if it is driven by wires from the fuse controller. | | |
| 257 | 263 | | cptra_obf_uds_seed | 512 | Input | Synchronous to clk | Used in Subsystem mode only. In Passive mode, integrators shall tie this input to 0. Fuse controller can optionally drive the uds seed value over wires through this interface. The value is sampled after warm reset if the valid cptra_obf_uds_seed_vld is asserted. | | |
| 258 | -| security_state | 3 | Input Strap | Synchronous to clk | Security state that Caliptra should take (for example, manufacturing, secure, unsecure, etc.). The key is latched by Caliptra on cptra_noncore_rst_b deassertion. Any time the state changes to debug mode, all keys, assets, and secrets stored in fuses or key vault are cleared. Cryptography core states are also flushed if they were being used. | | ||
| 264 | +| security_state | 6 | Input Strap | Synchronous to clk | Security state that Caliptra should take (for example, manufacturing, secure, unsecure, etc.). The strap is latched by Caliptra on cptra_noncore_rst_b deassertion. Any time the state changes to debug mode, all keys, assets, and secrets stored in fuses or key vault are cleared. Cryptography core states are also flushed if they were being used. <br>The strap is encoded as `{debug_locked[3:0], device_lifecycle[1:0]}`: <br>• Bits [5:2] `debug_locked` are a multi-bit (MuBi4) glitch-hardened encoding: `4'h6` (MuBi4True) = debug **locked**, `4'h9` (MuBi4False) = debug **unlocked**. The two legal values are bitwise complements for fault-injection resistance. Any other (invalid) encoding is interpreted as **locked** (fail-secure). Integrators must drive one of the two legal MuBi4 values; a single-bit strap is no longer sufficient. <br>• Bits [1:0] `device_lifecycle`: `2'b00` = DEVICE_UNPROVISIONED, `2'b01` = DEVICE_MANUFACTURING, `2'b11` = DEVICE_PRODUCTION. | | ||
| 259 | 265 | | scan_mode | 1 | Input Strap | Synchronous to clk | Must be set before entering scan mode. This is a separate signal than the scan chain enable signal that goes into scan cells. This allows Caliptra to flush any assets or secrets present in key vault and flops if the transition is happening from a secure state. | | |
| 260 | 266 | | generic_input_wires | 64 | Input | Synchronous to clk | Placeholder of input wires for late binding features. These values are reflected into registers that are exposed to firmware. | | |
| 261 | 267 | | generic_output_wires | 64 | Output | Synchronous to clk | Placeholder of output wires for late binding features. Firmware can set the wires appropriately via register writes. | | |
| 262 | 268 | | cptra_error_fatal | 1 | Output | Synchronous to clk | Indicates a fatal error from Caliptra. | | |
| 263 | 269 | | cptra_error_non_fatal | 1 | Output | Synchronous to clk | Indicates a non fatal error from Caliptra. | | |
| 264 | 270 | | BootFSM_BrkPoint | 1 | Input Strap | Asynchronous | Stops the BootFSM to allow TAP writes set up behavior. Examples of these behaviors are skipping or running ROM flows, or stepping through BootFSM. | | |
| 265 | -| etrng_req | 1 | Output | Synchronous to clk | External source mode: TRNG_REQ to SoC. SoC writes to TRNG architectural registers with a NIST-compliant entropy.<br> Internal source mode: TRNG_REQ to SoC. SoC enables external RNG digital bitstream input into itrng_data/itrng_valid. | | ||
| 266 | -| itrng_data | 4 | Input | Synchronous to clk | External source mode: Not used.<br> Internal source mode only: Physical True Random Noise Source (PTRNG for "Number Generator") digital bit stream from SoC, which is sampled when itrng_valid is high. See the [Hardware Specification](https://github.com/chipsalliance/caliptra-rtl/blob/main/docs/CaliptraHardwareSpecification.md#integrated-trng) for details on PTRNG expectations and iTRNG entropy capabilities. | | ||
| 267 | -| itrng_valid | 1 | Input | Synchronous to clk | External source mode: Not used.<br> Internal source mode only: RNG bit valid. This is valid per transaction. itrng_data can be sampled whenever this bit is high. The expected itrng_valid output rate is dependent on the process node technology. For 40nm, it is expected to be at least 50kHz. For latest industry standard, moderately advanced technology, it is expected to be greater than 400kHz. | | ||
| 268 | - | ||
| 271 | +| etrng0_req | 1 | Output | Synchronous to clk | External source mode: TRNG_REQ to SoC. SoC writes to TRNG architectural registers with a NIST-compliant entropy.<br> Internal source mode: request for the primary internal entropy source (ES0). SoC enables external RNG digital bitstream input into itrng0_data/itrng0_valid. | | ||
| 272 | +| etrng1_req | 1 | Output | Synchronous to clk | Internal source, dual-iTRNG mode only: request for the secondary internal entropy source (ES1). Only meaningful when the dual iTRNG entropy combiner is enabled (see itrng1_en); held 0 in External source mode and when dual iTRNG is disabled. | | ||
| 273 | +| itrng0_data | 4 | Input | Synchronous to clk | External source mode: Not used. Internal source mode only: primary Physical True Random Noise Source (PTRNG) digital bit stream from SoC, which is sampled when itrng0_valid is high. See the [Hardware Specification](https://github.com/chipsalliance/caliptra-rtl/blob/main/docs/CaliptraHardwareSpecification.md#integrated-trng) for details on PTRNG expectations and iTRNG entropy capabilities. | | ||
| 274 | +| itrng0_valid | 1 | Input | Synchronous to clk | External source mode: Not used.<br> Internal source mode only: primary RNG bit valid. This is valid per transaction. itrng0_data can be sampled whenever this bit is high. The expected valid output rate is dependent on the process node technology. For 40nm, it is expected to be at least 50kHz. For latest industry standard, moderately advanced technology, it is expected to be greater than 400kHz. | | ||
| 275 | +| itrng1_data | 4 | Input | Synchronous to clk | Secondary PTRNG digital bit stream (ES1), used only when the dual iTRNG entropy combiner is enabled. Integrators using a single iTRNG shall tie this input to 0. See the [Hardware Specification](https://github.com/chipsalliance/caliptra-rtl/blob/main/docs/CaliptraHardwareSpecification.md#dual-itrng-entropy-combiner). | | ||
| 276 | +| itrng1_valid | 1 | Input | Synchronous to clk | Secondary RNG bit valid (ES1). itrng1_data is sampled whenever this bit is high. Used only in dual-iTRNG mode; tie to 0 if the secondary source is not present. | | ||
| 277 | +| itrng1_en | 1 | Input Strap | Synchronous to clk | Dual iTRNG enable strap. When set, enables the secondary entropy source (ES1) and the SHA3-384 entropy combiner (combine mode); when 0, the combiner is bypassed (ES0 only). Only takes effect in Subsystem mode with CALIPTRA_INTERNAL_TRNG. Must be tied to a constant value. For example, driving this input from a programmable register, a package pin, or any other source that can change while Caliptra is out of reset is not permitted. Integrators using a single iTRNG shall tie this input to 0. Reflected in CPTRA_HW_CONFIG.dual_iTRNG_en. | | ||
| 278 | + | ||
| 279 | + | ||
| 280 | +## Dual iTRNG (secondary entropy source) | ||
| 281 | + | ||
| 282 | +Integrators that need a second physical noise source (for example, a different | ||
| 283 | +noise-generation technology) can enable Caliptra's dual iTRNG feature, which adds | ||
| 284 | +a secondary entropy source (ES1) and a SHA3-384 entropy combiner ahead of the | ||
| 285 | +single CSRNG. See the [Hardware Specification](https://github.com/chipsalliance/caliptra-rtl/blob/main/docs/CaliptraHardwareSpecification.md#dual-itrng-entropy-combiner) | ||
| 286 | +for the architecture. When the feature is disabled the combiner is bypassed and | ||
| 287 | +behavior is identical to a single iTRNG, so single-source integrations need only | ||
| 288 | +tie off the unused inputs. | ||
| 289 | + | ||
| 290 | +To use the dual iTRNG feature correctly, an integrator must: | ||
| 291 | + | ||
| 292 | +1. Instantiate the internal TRNG (`CALIPTRA_INTERNAL_TRNG`) in Subsystem mode. The | ||
| 293 | + feature only takes effect in Subsystem mode with the internal TRNG present. | ||
| 294 | +2. Connect the primary physical noise source to `itrng0_data` / `itrng0_valid` and | ||
| 295 | + the secondary source to `itrng1_data` / `itrng1_valid`. Each source has its own | ||
| 296 | + external request output (`etrng0_req`, `etrng1_req`). | ||
| 297 | +3. Tie the `itrng1_en` strap to a constant 1 to enable combine mode. This is | ||
| 298 | + reflected in the software-readable `CPTRA_HW_CONFIG.dual_iTRNG_en` bit, which | ||
| 299 | + the hardware uses to enable ES1 and the combiner. Tying `itrng1_en` to a | ||
| 300 | + constant 0 keeps the combiner in bypass (ES0 only). This strap must not be | ||
| 301 | + driven dynamically or changed while Caliptra is out of reset. | ||
| 302 | +4. Provide the ROM-time entropy-source configuration through the architectural | ||
| 303 | + registers described below (rather than a strap). | ||
| 304 | +5. Configure **each** entropy source independently for the noise source connected | ||
| 305 | + to it. The combiner uses two `entropy_src` instances (ES0 and ES1), and each | ||
| 306 | + has its own health-test thresholds, window size, and mode controls. Because | ||
| 307 | + the two physical noise sources may use different noise-generation technologies | ||
| 308 | + with different statistical behavior (bit rate, bias, correlation), their | ||
| 309 | + health-test parameters may differ and must each be derived from the | ||
| 310 | + corresponding source's characterization. | ||
| 311 | + | ||
| 312 | +Single-iTRNG integrations shall tie `itrng1_en`, `itrng1_data`, and `itrng1_valid` | ||
| 313 | +to 0; the secondary entropy source and combiner then remain inactive. | ||
| 314 | + | ||
| 315 | +### Entropy source configuration registers | ||
| 316 | + | ||
| 317 | +Earlier revisions delivered the ROM-time entropy-source (CSRNG) configuration | ||
| 318 | +through the `strap_ss_strap_generic_2` late-binding strap. That strap is **no | ||
| 319 | +longer used for entropy-source configuration**; the configuration is now provided | ||
| 320 | +through dedicated architectural registers so that each entropy source can be | ||
| 321 | +configured independently and so the values are software-readable: | ||
| 322 | + | ||
| 323 | +* `CPTRA_iTRNG_ENTROPY_CONFIG_0/1/2` — primary entropy source (ES0). | ||
| 324 | +* `CPTRA_iTRNG1_ENTROPY_CONFIG_0/1/2` — secondary entropy source (ES1). | ||
| 325 | + | ||
| 326 | +For each source, `..._CONFIG_0` carries the adaptive-proportion low/high | ||
| 327 | +thresholds, `..._CONFIG_1` carries the repetition-count threshold, and | ||
| 328 | +`..._CONFIG_2` carries the health-test window size, single-bit mode / | ||
| 329 | +`rng_bit_sel`, and entropy bypass (`es_type`) controls — the same fields | ||
| 330 | +previously encoded in the strap. Refer to the Caliptra ROM Specification for the | ||
| 331 | +programming sequence. | ||
| 269 | 332 | ||
| 270 | 333 | ## Architectural registers and fuses | |
| 271 | 334 | ||
| @@ -284,17 +347,31 @@ | |||
| 284 | 347 | ||
| 285 | 348 | **Note**: Starting in Caliptra 2.0 subsystem strap and other configuration registers have been added to the fuse region. Subsystem [straps](#straps) are expected to be programmed during the same time as fuses per [Caliptra spec](https://github.com/chipsalliance/Caliptra/blob/main/doc/Caliptra.md#subsystem-pre-fw-load-boot-flow). 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: | |
| 286 | 349 | ||
| 287 | -- `SS_DBG_MANUF_SERVICE_REG_RSP` | ||
| 350 | +- `SS_DBG_SERVICE_REG_RSP` | ||
| 288 | 351 | - `SS_SOC_DBG_UNLOCK_LEVEL` | |
| 289 | 352 | - `SS_GENERIC_FW_EXEC_CTRL` | |
| 290 | 353 | ||
| 291 | -The remaining register `SS_DBG_MANUF_SERVICE_REG_REQ` is initialized by the same SoC agent as fuses and is the only agent that can make subsystem debug service requests. | ||
| 354 | +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. | ||
| 355 | + | ||
| 356 | +### FUSE AXI USER attribute | ||
| 357 | + | ||
| 358 | +The CPTRA_FUSE_VALID_AXI_USER attribute is used to restrict access to the fuse registers via AXI to a single permitted SoC configuration agent. It is strongly recommended that the CPTRA_FUSE_VALID_AXI_USER value is either set at integration time through integration parameters or be programmed by the SoC ROM via register write before any mutable firmware or ROM patches are applied. | ||
| 359 | + | ||
| 360 | +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. | ||
| 361 | + | ||
| 362 | +#### FUSE AXI USER Programmable register | ||
| 363 | + | ||
| 364 | +Caliptra provides 1 programmable register that SoC can set at boot time to limit access to the fuse register set. If the CPTRA_FUSE_AXI_USER_LOCK.LOCK is set to ‘0, then access to the fuse registers by any agent is allowed. If the lock is set to ‘1, only an agent whose AXI USER matches the register CPTRA_FUSE_VALID_AXI_USER.AXI_USER can write to fuse registers. Any access by an unallowed AXI USER will return an AXI error response. CPTRA_FUSE_VALID_AXI_USER registers become valid once the corresponding lock bit CPTRA_FUSE_AXI_USER_LOCK.LOCK is set. | ||
| 365 | + | ||
| 366 | +#### FUSE AXI USER Parameter override | ||
| 367 | + | ||
| 368 | +Another option for limiting access to the fuse registers is the integration time parameter, which overrides the programmable AXI_USER register. At integration time, the CPTRA_SET_FUSE_AXI_USER_INTEG parameter can be set to 1 which enables the corresponding CPTRA_FUSE_VALID_AXI_USER parameter to override the programmable register. If CPTRA_SET_FUSE_AXI_USER_INTEG is set to ‘0, then access to the fuse registers by any agent is allowed. If this parameter is set to ‘1, only an agent whose AXI USER matches the parameter CPTRA_FUSE_VALID_AXI_USER can write to fuse registers. Any access by an unallowed AXI USER will return an AXI error response. | ||
| 292 | 369 | ||
| 293 | 370 | ## Interface rules | |
| 294 | 371 | ||
| 295 | 372 | The following figure shows the reset rules and timing for cold boot flows. | |
| 296 | 373 | ||
| 297 | -*Figure 2: Reset rules and timing diagram* | ||
| 374 | +*Figure: Reset rules and timing diagram* | ||
| 298 | 375 | ||
| 299 | 376 |  | |
| 300 | 377 | ||
| @@ -348,6 +425,7 @@ | |||
| 348 | 425 | * Access to mailbox memory region with invalid AXI_USER are dropped. | |
| 349 | 426 | * Access to a fuse with invalid AXI_USER are dropped. | |
| 350 | 427 | * Access to the trng with invalid AXI_USER are dropped. | |
| 428 | +* Access to the AXI DMA via the AXI interface are dropped. | ||
| 351 | 429 | * SLVERR is asserted for any of the above conditions. | |
| 352 | 430 | ||
| 353 | 431 | All accesses must be 32-bit aligned. Misaligned writes are dropped and reads return 0x0. | |
| @@ -371,7 +449,7 @@ | |||
| 371 | 449 | ||
| 372 | 450 | 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. | |
| 373 | 451 | ||
| 374 | -The key must follow the security rules defined in the[ Caliptra architectural specification](https://chipsalliance.github.io/Caliptra/doc/Caliptra.html). | ||
| 452 | +The key must follow the security rules defined in the [SOC integration requirements](#soc-integration-requirements). | ||
| 375 | 453 | ||
| 376 | 454 | SoC must ensure that there are no SCAN cells on the flops that latch this key internally to Caliptra. | |
| 377 | 455 | ||
| @@ -379,7 +457,7 @@ | |||
| 379 | 457 | ||
| 380 | 458 | 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. | |
| 381 | 459 | ||
| 382 | -The key must follow the security rules defined in the[ Caliptra architectural specification](https://chipsalliance.github.io/Caliptra/doc/Caliptra.html). | ||
| 460 | +The key must follow the security rules defined in the [SOC integration requirements](#soc-integration-requirements). | ||
| 383 | 461 | ||
| 384 | 462 | SoC must ensure that there are no SCAN cells on the flops that latch this key internally to Caliptra. | |
| 385 | 463 | ||
| @@ -411,8 +489,8 @@ | |||
| 411 | 489 | | :--------- | :--------- | :--------- | | |
| 412 | 490 | | 0 | strap_ss_strap_generic_0 | Provides the Caliptra ROM with a 32-bit pointer that encodes the location of the fuse controller's status register and the bit position of the idle indicator. Upper 16 bits: Bit index of the IDLE_BIT_STATUS within SOC_OTP_CTRL_STATUS. Lower 16 bits: Offset address of SOC_OTP_CTRL_STATUS within the SOC_IFC_REG space, relative to SOC_OTP_CTRL_BASE_ADDR. | | |
| 413 | 491 | | 1 | strap_ss_strap_generic_1 | Provides the Caliptra ROM with a 32-bit pointer to the fuse controller’s command register (CMD), enabling ROM-level control or triggering of fuse operations. | | |
| 414 | -| 2 | RESERVED | No allocated function. | | ||
| 415 | -| 3 | RESERVED | No allocated function. | | ||
| 492 | +| 2 | strap_ss_strap_generic_2 | Formerly provided the Caliptra ROM with entropy source (CSRNG) configuration during initialization. That configuration (health-test window size, single-bit mode / `rng_bit_sel`, and entropy bypass `es_type`) has moved to the `CPTRA_iTRNG_ENTROPY_CONFIG_2` (ES0) and `CPTRA_iTRNG1_ENTROPY_CONFIG_2` (ES1) architectural registers, with thresholds/repetition count in the `..._CONFIG_0`/`..._CONFIG_1` registers. This strap is **no longer used for entropy-source configuration** and is available as a general-purpose late-binding strap. Refer to the Caliptra ROM Specification for additional details. | | ||
| 493 | +| 3 | strap_ss_strap_generic_3 | Provides the Caliptra ROM with Stable Owner Key controls. Bit [0]: Stable Owner Key enable. When set to 1, ROM derives the Stable Owner Root Key from the HEK seed and allows `CM_DERIVE_STABLE_KEY` with `key_type = OwnerKey` when the other availability requirements are met (subsystem mode active and OCP LOCK disabled). When clear, Stable Owner Key derivation is disabled. Bits [31:1]: RESERVED/unused, must be tied to 0. Refer to the Caliptra ROM Specification for additional details. | | ||
| 416 | 494 | ||
| 417 | 495 | ||
| 418 | 496 | # SoC interface operation | |
| @@ -425,11 +503,7 @@ | |||
| 425 | 503 | ||
| 426 | 504 | ## Boot FSM | |
| 427 | 505 | ||
| 428 | -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, Caliptra can wake up the rest of the IP by deasserting the internal reset. The following figure shows the boot FSM state. | ||
| 429 | - | ||
| 430 | -*Figure 3: Mailbox Boot FSM state diagram* | ||
| 431 | - | ||
| 432 | - | ||
| 506 | +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](./CaliptraHardwareSpecification.md#boot-fsm) for more details and diagrams. | ||
| 433 | 507 | ||
| 434 | 508 | 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. | |
| 435 | 509 | 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. | |
| @@ -442,9 +516,31 @@ | |||
| 442 | 516 | ||
| 443 | 517 | The AXI_USER bits are used by the SoC to identify which device is accessing the mailbox. | |
| 444 | 518 | ||
| 519 | +## External Staging Area | ||
| 520 | + | ||
| 521 | +To save SRAM area when Caliptra operates in Subsystem mode, the mailbox (MBOX) SRAM is reduced to **16 KiB**. | ||
| 522 | +Instead of passing images directly to Caliptra through the mailbox, the SoC can configure an external staging SRAM that Caliptra fetches from and processes. | ||
| 523 | + | ||
| 524 | +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. | ||
| 525 | + | ||
| 526 | +For hitless updates or other image-processing operations, the Caliptra mailbox should be used to: | ||
| 527 | + | ||
| 528 | +1. Notify Caliptra that an image is available for processing. | ||
| 529 | +2. Specify the command to run on the image. | ||
| 530 | +3. Indicate the size of the image in the staging area. | ||
| 531 | + | ||
| 532 | +References: | ||
| 533 | + | ||
| 534 | +- [Caliptra ROM MBOX Commands](https://github.com/chipsalliance/caliptra-sw/blob/main/rom/dev/README.md#handling-commands-from-mailbox) | ||
| 535 | +- [Caliptra Runtime FW MBOX Commands](https://github.com/chipsalliance/caliptra-sw/blob/main/runtime/README.md#mailbox-commands) | ||
| 536 | +- [Caliptra HW API](#mailbox) | ||
| 537 | + | ||
| 538 | + | ||
| 539 | +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. | ||
| 540 | + | ||
| 445 | 541 | ## Mailbox | |
| 446 | 542 | ||
| 447 | -The Caliptra mailbox is a 256 KiB buffer used for exchanging data between the SoC and the Caliptra microcontroller. | ||
| 543 | +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](#external-staging-area) why the MBOX SRAM size is smaller in subsystem mode. | ||
| 448 | 544 | ||
| 449 | 545 | 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. | |
| 450 | 546 | ||
| @@ -473,9 +569,17 @@ | |||
| 473 | 569 | ||
| 474 | 570 | **Notes on behavior:** | |
| 475 | 571 | ||
| 476 | -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. | ||
| 477 | - | ||
| 478 | -*Figure 4: Sender protocol flow chart* | ||
| 572 | +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. If used, the force unlock mechanism has several effects: | ||
| 573 | +* Returns the mailbox FSM (indicated in the mbox_status register) to the IDLE state. | ||
| 574 | +* Resets the status field of the mbox_status register to CMD_BUSY. | ||
| 575 | +* Resets the soc_has_lock field of the mbox_status register to 0. | ||
| 576 | +* If the mailbox was in the ERROR state, internal hardware would continuously assert the error interrupt signals as described in [Caliptra mailbox errors](#Caliptra-mailbox-errors). The force unlock mechanism causes hardware to stop asserting these conditions, though any interrupts that are already asserted remain asserted and require firmware intervention to be cleared. | ||
| 577 | + | ||
| 578 | +To address these conditions, integrators may wish to add timeout handling logic to their implementation of the mailbox protocol. This timeout handling logic may determine that a pending mailbox request has been terminated by observing the deassertion of mbox_status.soc_has_lock, or by observing that mbox_status.mbox_fsm_ps indicates the IDLE state. Upon observing these conditions, SoC logic may check for any error conditions reported in [CPTRA_HW_ERROR_FATAL](https://chipsalliance.github.io/caliptra-rtl/main/external-regs/?p=clp.soc_ifc_reg.CPTRA_HW_ERROR_FATAL) or [CPTRA_HW_ERROR_NON_FATAL](https://chipsalliance.github.io/caliptra-rtl/main/external-regs/?p=clp.soc_ifc_reg.CPTRA_HW_ERROR_NON_FATAL), and may attempt a retry of the command depending on any SoC retry policies. | ||
| 579 | + | ||
| 580 | +The following figure shows the sender protocol flow. | ||
| 581 | + | ||
| 582 | +*Figure: Sender protocol flow chart* | ||
| 479 | 583 | ||
| 480 | 584 |  | |
| 481 | 585 | ||
| @@ -499,7 +603,7 @@ | |||
| 499 | 603 | ||
| 500 | 604 | The following figure shows the receiver protocol flow. | |
| 501 | 605 | ||
| 502 | -*Figure 5: Receiver protocol flowchart* | ||
| 606 | +*Figure: Receiver protocol flowchart* | ||
| 503 | 607 | ||
| 504 | 608 |  | |
| 505 | 609 | ||
| @@ -508,7 +612,7 @@ | |||
| 508 | 612 | When Caliptra sets the tap_mode register, the mailbox will transition from RDY_FOR_DATA to EXECUTE_TAP instead of EXECUTE_SOC. | |
| 509 | 613 | This will pass control of the mailbox to the TAP. TAP will follow the **Receiving data from the mailbox** protocol detailed above. | |
| 510 | 614 | ||
| 511 | -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. | ||
| 615 | +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. | ||
| 512 | 616 | This will pass control of the mailbox to the UC. UC will follow the **Receiving data from the mailbox** protocol detailed above. | |
| 513 | 617 | ||
| 514 | 618 | ## Mailbox arbitration | |
| @@ -535,8 +639,8 @@ | |||
| 535 | 639 | ||
| 536 | 640 | | Register | Description | | |
| 537 | 641 | | :--------- | :--------- | | |
| 538 | -| CPTRA_MBOX_VALID_AXI_USER\[4:0\]\[31:0\] | 5 registers for programming AXI_USER values that are considered valid for accessing the mailbox protocol. Requests with AXI_USER attributes that are not in this list will be ignored. | | ||
| 539 | -| CPTRA_MBOX_AXI_USER_LOCK\[4:0\] | 5 registers, bit 0 of each will lock and mark VALID for the corresponding VALID_AXI_USER register. | | ||
| 642 | +| CPTRA_MBOX_VALID_AXI_USER\[4:0\]\[31:0\] | 5 registers for programming AXI_USER values that are considered valid for accessing the mailbox protocol. Requests with AXI_USER attributes that are not in this list will return an AXI error response. | | ||
| 643 | +| CPTRA_MBOX_AXI_USER_LOCK\[4:0\] | 5 registers, bit 0 of each locks the corresponding VALID_AXI_USER register and marks it VALID. | | ||
| 540 | 644 | ||
| 541 | 645 | ||
| 542 | 646 | ### Parameter override | |
| @@ -639,11 +743,11 @@ | |||
| 639 | 743 | ||
| 640 | 744 | # TRNG REQ HW API | |
| 641 | 745 | ||
| 642 | -For SoCs that choose to not instantiate Caliptra’s internal TRNG, we provide a TRNQ REQ HW API. | ||
| 746 | +For SoCs integrating Caliptra core without Subsystem (i.e., passive mode) that choose not to instantiate Caliptra’s internal TRNG, Caliptra provides a TRNG REQ HW API. | ||
| 643 | 747 | ||
| 644 | 748 | **While the use of this API is convenient for early enablement, the current | |
| 645 | 749 | Caliptra hardware is unable to provide the same security guarantees with an | |
| 646 | -external TRNG. In particular, it is highly advisable to instantiate an internal | ||
| 750 | +external TRNG. The internal TRNG is recommended at a minimum, and required in Subsystem mode. In particular, it is highly advisable to instantiate an internal | ||
| 647 | 751 | TRNG if ROM glitch protection is important.** | |
| 648 | 752 | ||
| 649 | 753 | 1. Caliptra asserts TRNG\_REQ wire (this may be because Caliptra’s internal hardware or firmware made the request for a TRNG). | |
| @@ -651,9 +755,9 @@ | |||
| 651 | 755 | 3. SoC write a done bit in the TRNG architectural registers. | |
| 652 | 756 | 4. Caliptra deasserts TRNG\_REQ. | |
| 653 | 757 | ||
| 654 | -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). | ||
| 655 | - | ||
| 656 | -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. | ||
| 758 | +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). SoC implementations of this gasket logic must guarantee that only one AXI agent has access to the Caliptra TRNG REQ HW API. | ||
| 759 | + | ||
| 760 | +Access to TRNG DATA register is controlled by 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\_TRNG\_AXI\_USER\_LOCK.LOCK is set to ‘0, then any agent can write to the TRNG DATA register. If the lock is set to ‘1, only an agent whose AXI USER matches TRNG\_VALID\_AXI\_USER can write to TRNG DATA. 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 FW or ROM patches are absorbed. If integrators do not use these registers to filter agent access to the TRNG REQ HW API, then the SoC implementation must allow no more than one AXI agent in total to access Caliptra's SoC interface. | ||
| 657 | 761 | ||
| 658 | 762 | The ROM and firmware currently time out on the TRNG interface after 250,000 | |
| 659 | 763 | attempts to read a DONE bit. This bit is set in the architectural registers, as | |
| @@ -670,7 +774,8 @@ | |||
| 670 | 774 | entropy output is sufficient for ROM operation. | |
| 671 | 775 | ||
| 672 | 776 | The default self-test parameters are provided to the ROM via the | |
| 673 | -`CPTRA_iTRNG_ENTROPY_CONFIG0` and `CPTRA_iTRNG_ENTROPY_CONFIG1` registers. | ||
| 777 | +`SS_STRAP_GENERIC[2]`, `CPTRA_iTRNG_ENTROPY_CONFIG0`, and | ||
| 778 | +`CPTRA_iTRNG_ENTROPY_CONFIG1` registers. | ||
| 674 | 779 | ||
| 675 | 780 | The ROM configures self tests with the following parameters. | |
| 676 | 781 | ||
| @@ -680,12 +785,12 @@ | |||
| 680 | 785 | thresholds provided in the `CPTRA_iTRNG_ENTROPY_CONFIG0` are non-zero. | |
| 681 | 786 | ||
| 682 | 787 | `entropy_src.ADAPTP_HI_THRESHOLDS.FIPS_THRESH` = `CPTRA_iTRNG_ENTROPY_CONFIG0.HIGH_THRESHOLD`\ | |
| 683 | -`entropy_src.ADAPTP_LO_THRESHOLDS.FIPS_THRESH` = `CPTRA_iTRNG_ENTROPY_CONFIG0.HIGH_THRESHOLD` | ||
| 788 | +`entropy_src.ADAPTP_LO_THRESHOLDS.FIPS_THRESH` = `CPTRA_iTRNG_ENTROPY_CONFIG0.LOW_THRESHOLD` | ||
| 684 | 789 | ||
| 685 | 790 | Otherwise, the ROM will use 75% and 25% of the FIPS window size for the default | |
| 686 | 791 | high and low thresholds. | |
| 687 | 792 | ||
| 688 | -`W` = 2048 (bits)\ | ||
| 793 | +For example, when `W` = 2048 bits:\ | ||
| 689 | 794 | `entropy_src.ADAPTP_HI_THRESHOLDS.FIPS_THRESH` = \\(3 * (W / 4)\\) = 1536 \ | |
| 690 | 795 | `entropy_src.ADAPTP_LO_THRESHOLDS.FIPS_THRESH` = \\(W / 4\\) = 512 | |
| 691 | 796 | ||
| @@ -737,13 +842,13 @@ | |||
| 737 | 842 | ||
| 738 | 843 | \\(α = 2^{-40}\\) (recommended)\ | |
| 739 | 844 | \\(H = 0.5\\) (example, implementation specific)\ | |
| 740 | -\\(W = 2048\\) (constant in ROM/hw) | ||
| 845 | +\\(W = 2048\\) (example health-test window in bits) | ||
| 741 | 846 | ||
| 742 | 847 | ### Adaptive proportion test | |
| 743 | 848 | ||
| 744 | -The test is configured with to sum all the bits per symbol, due to | ||
| 745 | -`entropy_src.CONF.THRESHOLD_SCOPE` being enabled. The test essentially treats | ||
| 746 | -the combined input as a single binary stream, counting the occurrences of '1's. | ||
| 849 | +The ROM clears `entropy_src.CONF.THRESHOLD_SCOPE`, so the adaptive proportion | ||
| 850 | +test scores the RNG lanes individually. The following example treats one lane | ||
| 851 | +as a binary stream, counting the occurrences of '1's over the selected window. | ||
| 747 | 852 | ||
| 748 | 853 | > Note: The `critbinom` function (critical binomial distribution function) is | |
| 749 | 854 | > implemented by most spreadsheet applications. | |
| @@ -809,7 +914,7 @@ | |||
| 809 | 914 | ||
| 810 | 915 | The following figure shows the SRAM interface timing. | |
| 811 | 916 | ||
| 812 | -*Figure 6: SRAM interface timing* | ||
| 917 | +*Figure: SRAM interface timing* | ||
| 813 | 918 | ||
| 814 | 919 |  | |
| 815 | 920 | ||
| @@ -837,9 +942,9 @@ | |||
| 837 | 942 | ||
| 838 | 943 | 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. | |
| 839 | 944 | ||
| 840 | -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(calitpra\_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. | ||
| 841 | - | ||
| 842 | -*Figure 7: Example machine check reliability implementation* | ||
| 945 | +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. | ||
| 946 | + | ||
| 947 | +*Figure: Example machine check reliability implementation* | ||
| 843 | 948 | ||
| 844 | 949 |  | |
| 845 | 950 | ||
| @@ -883,80 +988,73 @@ | |||
| 883 | 988 | ||
| 884 | 989 | *Table 19: SoC integration requirements* | |
| 885 | 990 | ||
| 886 | -| Category | Requirement | Definition of done | Rationale | | ||
| 887 | -| :--------- | :--------- | :--------- | :--------- | | ||
| 888 | -| Obfuscation Key | SoC backend flows shall generate obfuscation key with appropriate NIST compliance as dictated in the Caliptra RoT specification. | Statement of conformance | Required by UDS and Field Entropy threat model | | ||
| 889 | -| Obfuscation Key | If not driven through PUF, SoC backend flows shall ECO the obfuscation key before tapeout. | Statement of conformance | Required by UDS and Field Entropy threat model | | ||
| 890 | -| Obfuscation Key | Rotation of the obfuscation key (if not driven through PUF) between silicon steppings of a given product (for example, A0 vs. B0 vs. PRQ stepping) is dependent on company-specific policies. | Statement of conformance | Required by UDS and Field Entropy threat model | | ||
| 891 | -| Obfuscation Key | SoC backend flows should not insert obfuscation key flops into the scan chain. | Synthesis report | Required by UDS and Field Entropy threat model | | ||
| 892 | -| Obfuscation Key | For defense in depth, it is strongly recommended that debofuscation key flops are not on the scan chain. <br> Remove the following signals from the scan chain: <br> cptra\_scan\_mode\_Latched\_d <br> cptra\_scan\_mode\_Latched\_f <br> field\_storage.internal\_obf\_key | Statement of conformance | Caliptra HW threat model | | ||
| 893 | -| Obfuscation Key | SoC shall ensure that obfuscation key is available (and wires are stable) before Caliptra reset is de-asserted. | Statement of conformance | Functionality and security | | ||
| 894 | -| Obfuscation Key | SoC shall implement protections for obfuscation key generation logic and protect against debug/sw/scandump visibility.<br>1. Any flops outside of Caliptra that store obfuscation key or parts of the key should be excluded from scandump.<br>2. SoC shall ensure that the obfuscation key is sent only to Caliptra through HW wires, and it is not visible anywhere outside of Caliptra. | Statement of conformance | Required for Caliptra threat model | | ||
| 895 | -| CSR HMAC Key | SoC backend flows shall generate CSR signing key with appropriate NIST compliance as dictated in the Caliptra ROT specification. | Statement of conformance | Required by Caliptra threat model | | ||
| 896 | -| CSR HMAC Key | SoC backend flows shall ECO the CSR signing key before tapeout. | Statement of conformance | Required by Caliptra threat model | | ||
| 897 | -| CSR HMAC Key | SoC backend flows should rotate CSR signing key for each project. | Statement of conformance | Required by Caliptra threat model | | ||
| 898 | -| CSR HMAC Key | SoC backend flows should not insert CSR signing key flops into the scan chain. | Statement of conformance | Required by Caliptra threat model | | ||
| 899 | -| DFT | Before scan is enabled (separate signal that SoC implements on scan insertion), SoC shall set Caliptra's scan\_mode indication to '1 for 5,000 clocks to allow secrets/assets to be flushed. | Statement of conformance | Required by Caliptra threat model | | ||
| 900 | -| DFT | Caliptra’s TAP should be a TAP endpoint. | Statement of conformance | Functional requirement | | ||
| 901 | -| Mailbox | SoC shall provide an access path between the mailbox and the application CPU complex on SoCs with such complexes (for example, Host CPUs and Smart NICs). See the [Sender Protocol](#sender-protocol) section for details about error conditions. | Statement of conformance | Required for Project Kirkland and TDISP TSM | | ||
| 902 | -| Fuses | SoC shall burn non-field fuses during manufacturing. Required vs. optional fuses are listed in the architectural specification. | Test on silicon | Required for UDS threat model | | ||
| 903 | -| Fuses | SoC shall expose an interface for burning field fuses. Protection of this interface is the SoC vendor’s responsibility. | Test on silicon | Required for Field Entropy | | ||
| 904 | -| Fuses | SoC shall write fuse registers and fuse done via immutable logic or ROM code. | Statement of conformance | Required for Caliptra threat model | | ||
| 905 | -| Fuses | SoC shall expose an API for programming Field Entropy as described in the architecture documentation. SoC shall ensure that Field Entropy can only be programmed via this API and shall explicitly prohibit burning of discrete Field Entropy bits and re-burning of already burned Field Entropy entries. | Test on silicon | Required for Field Entropy | | ||
| 906 | -| Fuses | SoC shall ensure that any debug read paths for fuses are disabled in PRODUCTION lifecycle state. | Test on silicon | Required for Field Entropy | | ||
| 907 | -| Fuses | SoC shall ensure that UDS\_SEED and Field Entropy supplied to Caliptra come directly from OTP fuses and there are no debug paths to inject new values. | Statement of conformance | Required for Caliptra threat model | | ||
| 908 | -| Fuses | SoC shall add integrity checks for Caliptra fuses as per SoC policy. | Statement of conformance | Reliability | | ||
| 909 | -| Fuses | SoC should apply shielding/obfuscation measures to protect fuse macro. | Statement of conformance | Required for Caliptra threat model | | ||
| 910 | -| Fuses | SoCs that intend to undergo FIPS 140-3 zeroization shall expose zeroization API as described in zeroization requirements in architecture specification. SoC shall apply appropriate authentication for this API to protect against denial of service and side channel attacks. | Test on silicon | FIPS 140-3 certification | | ||
| 911 | -| Security State | SoC shall drive security state wires in accordance with the SoC's security state. | Statement of conformance | Required for Caliptra threat model | | ||
| 912 | -| Security State | If SoC is under debug, then SoC shall drive debug security state to Caliptra. | Statement of conformance | Required for Caliptra threat model | | ||
| 913 | -| Resets and Clocks | SoC shall start input clock before cptra\_pwrgood assertion. The clock must operate for a minimum of 10 clock cycles before SoC asserts cptra\_pwrgood. | Statement of conformance | Functional | | ||
| 914 | -| Resets and Clocks | After asserting cptra\_pwrgood, SoC shall wait for a minimum of 10 clock cycles before deasserting cptra\_rst\_b. | Statement of conformance | Functional | | ||
| 915 | -| Resets and Clocks | SoC reset logic shall assume reset assertions are asynchronous and deassertions are synchronous. | Statement of conformance | Functional | | ||
| 916 | -| Resets and Clocks | SoC shall ensure Caliptra's powergood is tied to SoC’s own powergood or any other reset that triggers SoC’s cold boot flow. | Statement of conformance | Required for Caliptra threat model | | ||
| 917 | -| Resets and Clocks | SoC shall ensure Caliptra clock is derived from an on-die oscillator circuit. | Statement of conformance | Required for Caliptra threat model | | ||
| 918 | -| Resets and Clocks | SoC shall ensure that any programmable Caliptra clock controls are restricted to the SoC Manager. | Statement of conformance | Required for Caliptra threat model | | ||
| 919 | -| Resets and Clocks | SoC should defend against external clock stop attacks. | Statement of conformance | Required for Caliptra threat model | | ||
| 920 | -| Resets and Clocks | SoC should defend against external clock glitching attacks. | Statement of conformance | Required for Caliptra threat model | | ||
| 921 | -| Resets and Clocks | SoC should defend against external clock overclocking attacks. | Statement of conformance | Required for Caliptra threat model | | ||
| 922 | -| TRNG | SoC shall either provision Caliptra with a dedicated TRNG or shared TRNG. It is highly recommended to use dedicated ITRNG | Statement of conformance | Required for Caliptra threat model and Functional | | ||
| 923 | -| TRNG | SoC shall provision the Caliptra embedded TRNG with an entropy source if that is used (vs. SoC-shared TRNG API support). | Statement of conformance | Functional | | ||
| 924 | -| TRNG | If the TRNG is shared, then upon TRNG\_REQ, SoC shall use immutable logic or code to program Caliptra's TRNG registers. | Statement of conformance | Required for Caliptra threat model and Functional | | ||
| 925 | -| SRAMs | SoC shall ensure timing convergence with 1-cycle read path for SRAMs. | Synthesis report | Functional | | ||
| 926 | -| SRAMs | SoC shall size SRAMs to account for SECDED. Exception for Adams-Bridge SRAMs that do not utilize SECDED. | Statement of conformance | Functional | | ||
| 927 | -| SRAMs | SoC shall write-protect fuses that characterize the SRAM. | Statement of conformance | Required for Caliptra threat model | | ||
| 928 | -| SRAMs | SoC shall ensure SRAM content is only destroyed on powergood cycling. | Statement of conformance | Functional (Warm Reset, Hitless Update) | | ||
| 929 | -| SRAMs | SoC shall only perform SRAM repair on powergood events and prior to caliptra\_rst\_b deassertion. SoC shall also ensure that SRAMs are initialized with all 0 data during powergood events, and prior to caliptra\_rst\_b deassertion. | Statement of conformance | Functional (Warm Reset, Hitless Update) | | ||
| 930 | -| Backend convergence | Caliptra supports frequencies up to 400MHz using an industry standard, moderately advanced technology node as of 2023 September. | Statement of conformance | Functional | | ||
| 931 | -| Power saving | Caliptra clock gating shall be controlled by Caliptra firmware alone. SoC is provided a global clock gating enable signal (and a register) to control. | Statement of conformance | Required for Caliptra threat model | | ||
| 932 | -| Power saving | SoC shall not power-gate Caliptra independently of the entire SoC. | Statement of conformance | Required for Caliptra threat model | | ||
| 933 | -| AXI USER | SoC shall drive AXI USER input for all AXI requests that have a route to Caliptra (e.g. through the AXI interconnect). CANNOT use value 0xFFFFFFFF. This is reserved for Caliptra-internal usage. | Statement of conformance | Required for Caliptra threat model | | ||
| 934 | -| AXI USER | Assigned AXI USER values must be unique for each agent on the interconnect. All SoC AXI agents that have an access path to Caliptra AXI subordinate (or any Caliptra Subsystem components, when using the Subsystem mode) via AXI must either (a) generate AXI transactions using an AXI_USER value that is unique from that used by all other AXI agents on the interconnect or (b) generate AXI transactions using an AXI_USER value that will never overlap with the configured valid AXI users, if the agent is not a valid mailbox user, valid fuse user, or valid trng user. For example, if any AXI agents utilize the AxUSER field for any type of dynamic metadata and are on the same AXI interconnect as Caliptra, all possible AxUSER values from those agents should be avoided for assigning Caliptra VALID AXI USER values. Because AXI AxUSER signals are used to identify accessing agents and enforce access rules, this rule ensures that no single agent may ever generate an AXI transaction that identifies it as originating from a different agent. | Statement of conformance | Required for Caliptra threat model | | ||
| 935 | -| Error reporting | SoC shall report Caliptra error outputs. | Statement of conformance | Telemetry and monitoring | | ||
| 936 | -| Error reporting | SoC shall only recover Caliptra fatal errors via SoC power-good reset. | Statement of conformance | Required for Caliptra threat model | | ||
| 937 | -| TRNG AXI USER Programming rules | If SoC doesn’t program the CPTRA\_TRNG\_AXI\_USER\_LOCK\[LOCK\] and Caliptra is configured in external TRNG mode, then Caliptra HW will accept TRNG data from any SoC entity. | Security | Required for Caliptra threat model | | ||
| 938 | -| TRNG AXI USER Programming rules | If SoC programs CPTRA\_TRNG\_VALID\_AXI\_USER and sets CPTRA\_TRNG\_AXI\_USER\_LOCK\[LOCK\] and Caliptra is configured in external TRNG mode, then Caliptra HW will accept TRNG data only from the entity that is programmed into the AXI USER register. | Security | Required for Caliptra threat model | | ||
| 939 | -| TRNG AXI USER Programming rules | 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 FW or ROM patches are absorbed. | Security | Required for Caliptra threat model | | ||
| 940 | -| TRNG AXI USER Programming rules | It is strongly recommended that integrators set the TRNG valid AXI_USER to a non-zero value, due to the above uniqueness requirement. | Security | Required for Caliptra threat model | | ||
| 941 | -| MAILBOX AXI USER programming rules | 5 AXI USER attribute registers are implemented at SoC interface. | Security | Required for Caliptra threat model | | ||
| 942 | -| MAILBOX AXI USER programming rules | At boot time, a default SoC or AXI USER can access the mailbox. The value of this AXI USER is an integration parameter, CPTRA\_DEF\_MBOX\_VALID\_AXI\_USER. | Security | Required for Caliptra threat model | | ||
| 943 | -| MAILBOX AXI USER programming rules | The value of CPTRA\_MBOX\_VALID\_AXI\_USER\[4:0\] register can be programmed by SoC. After it is locked, it becomes a valid AXI USER for accessing the mailbox. | Security | Required for Caliptra threat model | | ||
| 944 | -| MAILBOX AXI USER programming rules | CPTRA\_SET\_MBOX\_AXI\_USER\_INTEG parameter can be set along with the corresponding CPTRA\_MBOX\_VALID\_AXI\_USER parameter at integration time. If set, these integration parameters take precedence over the CPTRA\_MBOX\_VALID\_AXI\_USER\[4:0\] register. | Security | Required for Caliptra threat model | | ||
| 945 | -| MAILBOX AXI USER programming rules | SoC logic (ROM, HW) that is using the Caliptra mailbox right out of cold reset, without first configuring the programmable mailbox AXI USER registers, must send the mailbox accesses with the default AXI USER, CPTRA\_DEF\_MBOX\_VALID\_AXI\_USER. | Security | Required for Caliptra threat model | | ||
| 946 | -| MAILBOX AXI USER programming rules | For CPTRA\_MBOX\_VALID\_AXI\_USER\[4:0\], the corresponding lock bits MUST be programmed to ‘1. This enables the mailbox to accept transactions from non-default AXI USERS. | Security | Required for Caliptra threat model | | ||
| 947 | -| MAILBOX AXI USER programming rules | It is strongly recommended that mailbox AXI USER registers are either set at integration time through integration parameters or are programmed by the SoC ROM before any mutable FW or ROM patches are applied. | Security | Required for Caliptra threat model | | ||
| 948 | -| MAILBOX AXI USER Programming rules | It is strongly recommended that integrators set the MAILBOX valid AXI_USER to non-zero values, due to the above uniqueness requirement. | Security | Required for Caliptra threat model | | ||
| 949 | -| FUSE AXI USER programming rules | 1 AXI USER attribute register is implemented at SoC interface: CPTRA\_FUSE\_VALID\_AXI\_USER. | Security | Required for Caliptra threat model | | ||
| 950 | -| FUSE AXI USER programming rules | CPTRA\_FUSE\_AXI\_USER\_LOCK locks the programmable valid axi user register, and marks the programmed value as valid. | Security | Required for Caliptra threat model | | ||
| 951 | -| FUSE AXI USER programming rules | Integrators can choose to harden the valid axi user for fuse access by setting the integration parameter, CPTRA\_FUSE\_VALID\_AXI\_USER, to the desired value in RTL, and by setting CPTRA\_SET\_FUSE\_AXI\_USER\_INTEG to 1. If set, these integration parameters take precedence over the CPTRA\_FUSE\_VALID\_AXI\_USER register. | Security | Required for Caliptra threat model | | ||
| 952 | -| FUSE AXI USER Programming rules | It is strongly recommended that integrators set the FUSE valid AXI_USER to a non-zero value, due to the above uniqueness requirement. | Security | Required for Caliptra threat model | | ||
| 953 | -| Manufacturing | SoC shall provision an IDevID certificate with fields that conform to the requirements described in [Provisioning IDevID during manufacturing](https://github.com/chipsalliance/Caliptra/blob/main/doc/Caliptra.md#provisioning-idevid-during-manufacturing). | Statement of conformance | Functionality | | ||
| 954 | -| Manufacturing | Caliptra relies on obfuscation for confidentiality of UDS\_SEED. It is strongly advised to implement manufacturing policies to protect UDS\_SEED as defense in depth measures. <br>1, Prevent leakage of UDS\_SEED on manufacturing floor.<br>2. Implement policies to prevent cloning (programming same UDS\_SEED into multiple devices).<br>3. Implement policies to prevent signing of spurious IDEVID certs. | Statement of conformance | Required for Caliptra threat model | | ||
| 955 | -| Chain of trust | SoC shall ensure all mutable code and configuration measurements are stashed into Caliptra. A statement of conformance lists what is considered mutable code and configuration vs. what is not. The statement also describes the start of the boot sequence of the SoC and how Caliptra is incorporated into it. | Statement of conformance | Required for Caliptra threat model | | ||
| 956 | -| Chain of trust | SoC shall limit the mutable code and configuration that persists across the Caliptra powergood reset. A statement of conformance lists what persists and why this persistence is necessary. | Statement of conformance | Required for Caliptra threat model | | ||
| 957 | -| Implementation | SoC shall apply size-only constraints on cells tagged with the "u\_\_size\_only\_\_" string and shall ensure that these are not optimized in synthesis and PNR | Statement of conformance | Required for Caliptra threat model | | ||
| 958 | -| GLS FEV | GLS FEV must be run to make sure netlist and RTL match and none of the countermeasures are optimized away. See the following table for example warnings from synthesis runs to resolve through FEV | GLS simulations pass | Functional requirement | | ||
| 959 | - | ||
| 991 | +| Category | Requirement | Rationale | | ||
| 992 | +| :--------- | :--------- | :--------- | | ||
| 993 | +| Dev-Keys-1 | SoC backend flows shall generate obfuscation and CSR HMAC key with appropriate NIST compliance as dictated in the Caliptra RoT specification. | Required by Caliptra threat model | | ||
| 994 | +| Dev-Keys-2 | SoC backend flows shall ECO the CSR HMAC signing key before tapeout. If not driven through PUF, SoC backend flows shall ECO the obfuscation key before tapeout. | Required by Caliptra threat model | | ||
| 995 | +| Dev-Keys-3* | SoC backend flows should rotate obfuscation and CSR HMAC signing keys for each project. | Required by Caliptra threat model | | ||
| 996 | +| Dev-Keys-4 | The obfuscation and CSR HMAC keys shall not be accessible (readable or modifiable) to firmware or any on-chip non-Caliptra entities, including preventing oracle attacks. The keys shall not be on any scannable path. | Required by Caliptra threat model | | ||
| 997 | +| Dev-Keys-5* | SoC backend flows shall not insert obfuscation and CSR HMAC key flops into the scan chain. | Required by Caliptra threat model | | ||
| 998 | +| Dev-Keys-6* | For defense in depth, obfuscation and CSR HMAC key flops must not be on the scan chain. <br> Remove the following signals from the scan chain: <br> cptra\_scan\_mode\_Latched\_d <br> cptra\_scan\_mode\_Latched\_f <br> field\_storage.internal\_obf\_key <br> cptra_csr_hmac_key_reg | Required by Caliptra threat model | | ||
| 999 | +| Dev-Keys-7 | SoC shall implement protections for obfuscation and CSR HMAC key generation logic and protect against debug/sw/scandump visibility.<br>1. Any flops outside of Caliptra that store keys or parts of the keys must be excluded from scandump.<br>2. SoC shall ensure that the obfuscation key is sent only to Caliptra through HW wires, and it is not visible anywhere outside of Caliptra. | Required by Caliptra threat model | | ||
| 1000 | +| Obf-Key-1 | The obfuscation key shall be generated using a method that ensures 256 bits of entropy, such as an ESV certified entropy source or an on-die Physically Unclonable Function (PUF) that is compliant with industry standards. | Required by Caliptra threat model | | ||
| 1001 | +| Obf-Key-2 | SoC shall ensure that obfuscation key is available (and wires are stable) before Caliptra reset is de-asserted. | Required by Caliptra threat model and Functional Requirement | | ||
| 1002 | +| Obf-Key-3 | Rotation of the obfuscation key (if not driven through PUF) between silicon steppings of a given product (for example, A0 vs. B0 vs. PRQ stepping) is dependent on company-specific policies. | Required by Caliptra threat model | | ||
| 1003 | +| DFT-1 | Before scan is enabled (separate signal that SoC implements on scan insertion), SoC shall set Caliptra's scan\_mode indication to '1 for 5,000 clocks to allow secrets/assets to be flushed. | Required by Caliptra threat model | | ||
| 1004 | +| DFT-2* | If connected, Caliptra’s TAP should be a TAP endpoint. | Functional Requirement | | ||
| 1005 | +| DFD-1 | Integrators shall not connect Caliptra's exposed RISC-V trace ports to any SoC logic. These ports are unvalidated and any implications to the SoC logic due to connecting these signals have not been analyzed. | Required by Caliptra threat model | | ||
| 1006 | +| Mbox-1 | SoC should provide an access path between the mailbox and the application CPU complex on SoCs with such complexes (for example, Host CPUs and Smart NICs). | Required for Project Kirkland and TDISP TSM | | ||
| 1007 | +| Fuses-1 | SoC shall burn non-field fuses during manufacturing. All *Caliptra Core* fuses must be implemented as described in the [fuse map table](https://github.com/chipsalliance/Caliptra/blob/main/doc/Caliptra.md#fuse-map). Fuses used for *Subsystem* are optional outside of the subsystem context. | Required by Caliptra threat model | | ||
| 1008 | +| Fuses-2 | SoC shall expose an interface for burning field fuses. Protection of this interface is the SoC vendor’s responsibility. | Required by Caliptra threat model | | ||
| 1009 | +| Fuses-3 | SoC shall write fuse registers and fuse done via immutable logic or ROM code. | Required by Caliptra threat model | | ||
| 1010 | +| Fuses-4 | SoC shall expose an API for programming Field Entropy as described in the architecture documentation. SoC shall ensure that Field Entropy can only be programmed via this API and shall explicitly prohibit burning of discrete Field Entropy bits and re-burning of already burned Field Entropy entries. | Required by Caliptra threat model | | ||
| 1011 | +| Fuses-5 | SoC shall ensure that any debug read paths for fuses are disabled in PRODUCTION lifecycle state. | Required by Caliptra threat model | | ||
| 1012 | +| Fuses-6 | SoC shall ensure that UDS\_SEED and Field Entropy supplied to Caliptra come directly from OTP fuses and there are no debug paths to inject new values. | Required by Caliptra threat model | | ||
| 1013 | +| Fuses-7 | SoC shall add integrity checks for Caliptra fuses as per SoC policy. | Functional Requirement | | ||
| 1014 | +| Fuses-8 | SoCs that intend to undergo FIPS 140-3 zeroization shall expose zeroization API as described in zeroization requirements in architecture specification. SoC shall apply appropriate authentication for this API to protect against denial of service and side channel attacks. | FIPS 140-3 certification | | ||
| 1015 | +| Sec-State-1 | SoC shall drive security state wires in accordance with the SoC's security state. | Required by Caliptra threat model | | ||
| 1016 | +| Sec-State-2 | If SoC is under debug, then SoC shall drive debug security state to Caliptra. | Required by Caliptra threat model | | ||
| 1017 | +| Rst-and-clk-1 | SoC shall start input clock before cptra\_pwrgood assertion. The clock must operate for a minimum of 10 clock cycles before SoC asserts cptra\_pwrgood. | Functional Requirement | | ||
| 1018 | +| Rst-and-clk-2 | After asserting cptra\_pwrgood, SoC shall wait for a minimum of 10 clock cycles before deasserting cptra\_rst\_b. | Functional Requirement | | ||
| 1019 | +| Rst-and-clk-3 | SoC reset logic shall assume reset assertions are asynchronous and deassertions are synchronous. | Functional Requirement | | ||
| 1020 | +| Rst-and-clk-4 | SoC shall ensure Caliptra's powergood is tied to SoC’s own powergood or any other reset that triggers SoC’s cold boot flow. | Required by Caliptra threat model | | ||
| 1021 | +| Rst-and-clk-5 | SoC shall ensure Caliptra's clock is driven by an on-die source such as an internal oscillator, PLL, or other clock generation circuit. This is to protect against clock fault injection or clock stretching attacks. | Required by Caliptra threat model | | ||
| 1022 | +| Rst-and-clk-6 | SoC shall ensure that any programmable Caliptra clock controls are restricted to the SoC Manager. | Required by Caliptra threat model | | ||
| 1023 | +| Rst-and-clk-7 | SoC should employ reasonable countermeasures to defend against advanced physical attacks like clock glitching. These countermeasures may be guided by common best practices as well as specific customer requirements. | Required by Caliptra threat model | | ||
| 1024 | +| TRNG-1 | SoC shall provision the Caliptra embedded TRNG with an entropy source if that is used (vs. SoC-shared TRNG API support). | Functional Requirement | | ||
| 1025 | +| TRNG-2 | If the TRNG is shared, then upon TRNG\_REQ, SoC shall use immutable logic or code to program Caliptra's TRNG registers. | Required by Caliptra threat model and Functional Requirement | | ||
| 1026 | +| TRNG-3* | SoC shall either provision Caliptra with a dedicated TRNG or shared TRNG. It is highly recommended to use dedicated ITRNG. When using Caliptra Subsystem, dedicated internal TRNG is required for Caliptra. | Required by Caliptra threat model and Functional Requirement | | ||
| 1027 | +| SRAMs-1 | SoC shall ensure timing convergence with 1-cycle read path for SRAMs. | Functional Requirement | | ||
| 1028 | +| SRAMs-2 | SoC shall size SRAMs to account for SECDED. Exception for Adams-Bridge SRAMs that do not utilize SECDED. | Functional Requirement | | ||
| 1029 | +| SRAMs-3 | SoC shall write-protect fuses that characterize the SRAM. | Required by Caliptra threat model | | ||
| 1030 | +| SRAMs-4 | SoC shall ensure SRAM content is only destroyed on powergood cycling to accommodate warm resets and hitless updates. | Functional Requirement | | ||
| 1031 | +| SRAMs-5 | SoC shall only perform SRAM repair on powergood events and prior to caliptra\_rst\_b deassertion. SoC shall also ensure that SRAMs are initialized with all 0 data during powergood events, and prior to caliptra\_rst\_b deassertion. Necessary for warm resets and hitless updates. | Functional Requirement | | ||
| 1032 | +| Backend-convergence-1 | Caliptra supports frequencies up to 400MHz 0.72V using an industry standard, advanced technology node as of 2025 April. Integrator designs must also achieve backend convergence. | Functional Requirement | | ||
| 1033 | +| Power-saving-1 | Caliptra clock gating shall be controlled by Caliptra firmware alone. SoC is provided a global clock gating enable signal (and a register) to control. | Required by Caliptra threat model | | ||
| 1034 | +| Power-saving-2 | SoC shall not power-gate Caliptra independently of the entire SoC. | Required by Caliptra threat model | | ||
| 1035 | +| AXI-USER-1 | SoC shall drive AXI USER input for all AXI requests that have a route to Caliptra (e.g. through the AXI interconnect). CANNOT use value 0xFFFFFFFF. This is reserved for Caliptra-internal usage. | Required by Caliptra threat model | | ||
| 1036 | +| AXI-USER-2 | Assigned AXI USER values must be unique for each agent on the interconnect. All SoC AXI agents that have an access path to Caliptra AXI subordinate (or any Caliptra Subsystem components, when using the Subsystem mode) via AXI must either (a) generate AXI transactions using an AXI_USER value that is unique from that used by all other AXI agents on the interconnect or (b) generate AXI transactions using an AXI_USER value that will never overlap with the configured valid AXI users, if the agent is not a valid mailbox user, valid fuse user, or valid trng user. For example, if any AXI agents utilize the AxUSER field for any type of dynamic metadata and are on the same AXI interconnect as Caliptra, all possible AxUSER values from those agents should be avoided for assigning Caliptra VALID AXI USER values. Because AXI AxUSER signals are used to identify accessing agents and enforce access rules, this rule ensures that no single agent may ever generate an AXI transaction that identifies it as originating from a different agent. | Required by Caliptra threat model | | ||
| 1037 | +| Error-rpt-1 | SoC shall report Caliptra error outputs. | Functional Requirement | | ||
| 1038 | +| Error-rpt-2 | SoC shall only recover Caliptra fatal errors via SoC power-good reset. | Required by Caliptra threat model | | ||
| 1039 | +| TRNG-AXI-USER-1 | If integrating Caliptra in passive mode with an external TRNG, SoC integrators must assign an SoC agent that is permitted to access Caliptra's TRNG REQ HW API via AXI. All other AXI agents must be excluded from such access. SoC integrators must enforce this exclusivity either by using the access restriction features described in [TRNG REQ HW API](#TRNG-REQ-HW-API) or by implementing an alternative mechanism. For example, restricting the hardware paths to Caliptra through an AXI interconnect to only the agent that is allowed access also satisfies this requirement. | Required by Caliptra threat model | | ||
| 1040 | +| TRNG-AXI-USER-2* | It is strongly recommended that the TRNG AXI USER register be programmed by the SoC ROM before any mutable FW or ROM patches are absorbed. | Required by Caliptra threat model | | ||
| 1041 | +| TRNG-AXI-USER-3* | It is strongly recommended that integrators set the TRNG valid AXI_USER to a non-zero value, due to the AXI USER uniqueness requirement. | Required by Caliptra threat model | | ||
| 1042 | +| MBOX-AXI-USER-1 | SoC logic (ROM, HW) that uses the Caliptra mailbox right out of cold reset, without first configuring the programmable mailbox AXI USER registers, must send the mailbox accesses with the default AXI USER, CPTRA\_DEF\_MBOX\_VALID\_AXI\_USER. | Required by Caliptra threat model | | ||
| 1043 | +| MBOX-AXI-USER-2 | SoC integrators must assign a subset of SoC agents that are permitted to access Caliptra's mailbox via AXI. All other AXI agents must be excluded from such access. SoC integrators must enforce this exclusivity either by using the access restriction features described in [MAILBOX AXI USER attribute register](#MAILBOX-AXI-USER-attribute-register) or by implementing an alternative mechanism. For example, restricting the hardware paths to Caliptra through an AXI interconnect to only those agents that are allowed access also satisfies this requirement. | Required by Caliptra threat model | | ||
| 1044 | +| MBOX-AXI-USER-3* | It is strongly recommended that mailbox AXI USER registers are either set at integration time through integration parameters or are programmed by the SoC ROM before any mutable FW or ROM patches are applied. | Required by Caliptra threat model | | ||
| 1045 | +| MBOX-AXI-USER-4* | It is strongly recommended that integrators set the MAILBOX valid AXI_USER to non-zero values, due to the AXI USER uniqueness requirement. | Required by Caliptra threat model | | ||
| 1046 | +| FUSE-AXI-USER-1 | SoC integrators must assign a single SoC agent that is permitted to access Caliptra's fuse registers via AXI. All other AXI agents must be excluded from such access. SoC integrators must enforce this exclusivity either by using the access restriction features described in [FUSE AXI USER attribute](#FUSE-AXI-USER-attribute) or by implementing an alternative mechanism. For example, restricting the hardware paths to Caliptra through an AXI interconnect to only the agent that is allowed access to fuse registers also satisfies this requirement. | Required by Caliptra threat model | | ||
| 1047 | +| FUSE-AXI-USER-2* | It is strongly recommended that fuse AXI USER register is either set at integration time through the integration parameter or is programmed by the SoC ROM before any mutable FW or ROM patches are applied. | Required by Caliptra threat model | | ||
| 1048 | +| FUSE-AXI-USER-3* | It is strongly recommended that integrators set the FUSE valid AXI_USER to a non-zero value, due to the AXI USER uniqueness requirement. | Required by Caliptra threat model | | ||
| 1049 | +| Mfg-1 | SoC shall provision an IDevID certificate with fields that conform to the requirements described in [Provisioning IDevID during manufacturing](https://github.com/chipsalliance/Caliptra/blob/main/doc/Caliptra.md#provisioning-idevid-during-manufacturing). | Functional Requirement | | ||
| 1050 | +| Mfg-2 | Caliptra relies on obfuscation for confidentiality of UDS\_SEED. It is strongly advised to implement manufacturing policies to protect UDS\_SEED as defense in depth measures. <br>1. Prevent leakage of UDS\_SEED on manufacturing floor.<br>2. Implement policies to prevent cloning (programming same UDS\_SEED into multiple devices).<br>3. Implement policies to prevent signing of spurious IDEVID certs. | Required by Caliptra threat model | | ||
| 1051 | +| Chain-of-trust-1 | SoC shall ensure all mutable code and configuration measurements are stashed into Caliptra. A statement of conformance lists what is considered mutable code and configuration vs. what is not. The statement also describes the start of the boot sequence of the SoC and how Caliptra is incorporated into it. | Required by Caliptra threat model | | ||
| 1052 | +| Chain-of-trust-2 | SoC shall limit the mutable code and configuration that persists across the Caliptra powergood reset. A statement of conformance lists what persists and why this persistence is necessary. | Required by Caliptra threat model | | ||
| 1053 | +| Implementation-1 | Integrators shall follow the [Primitive Instantiation Process](#primitive-instantiation) to ensure that process-specific library cells are used and appropriately named. Integrators shall apply size-only constraints on the resulting cells tagged with the "u\_\_size\_only\_\_" string. Integrators shall review results from synthesis and PNR to ensure that these are not optimized away. | Required by Caliptra threat model | | ||
| 1054 | +| GLS-FEV-1 | GLS FEV must be run to make sure netlist and RTL match. See the following table for example warnings from synthesis runs to resolve through FEV. | Functional Requirement | | ||
| 1055 | + | ||
| 1056 | + | ||
| 1057 | +\* **Note: Deviation or exemption from requirements marked with * may be permitted if documented justification is provided and approved by the SRP and TAC.** | ||
| 960 | 1058 | ||
| 961 | 1059 | *Table 20: Caliptra synthesis warnings for FEV evaluation* | |
| 962 | 1060 | ||
| @@ -968,6 +1066,39 @@ | |||
| 968 | 1066 | | ecc_montgomerymultiplier | Netlist for always_ff block does not contain flip flop | 274, 326 | Output width is smaller than internal signals, synthesis optimizes away the extra internal flops with no loads | | |
| 969 | 1067 | | Multiple modules | Signed to unsigned conversion occurs ||| | |
| 970 | 1068 | ||
| 1069 | + | ||
| 1070 | +## OCP LOCK Caliptra ROM & Firmware Requirements | ||
| 1071 | + | ||
| 1072 | +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. | ||
| 1073 | +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. | ||
| 1074 | + | ||
| 1075 | +- **DOE error status (KV write failure):** | ||
| 1076 | + Introduce a new status bit; ROM must check it after any DOE flow to ensure the KV write succeeded. | ||
| 1077 | +- **HEK DOE flow**: | ||
| 1078 | + 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. | ||
| 1079 | +- **Derivations & locking**: | ||
| 1080 | + - Derive the MDK to **KV16**, then set the **lock_wr** control bit of KV16. | ||
| 1081 | + - If OCP LOCK is enabled, derive **HEK** to **KV22**, then set the **lock_wr** control bit of KV23. | ||
| 1082 | + - Perform this **before** setting `OCP_LOCK_IN_PROGRESS` since HEK derivation depends on the **HEK seed** and **standard CDI derivatives** (from standard KV slots). | ||
| 1083 | +- **Setting lock state:** | ||
| 1084 | + If OCP LOCK is enabled, ROM **MUST** set `OCP_LOCK_IN_PROGRESS` before transitioning to the First Mutable Code (FMC) image. | ||
| 1085 | +- **KV23 usage constraints:** | ||
| 1086 | + Never attempt to write anything to **KV23** except **MEK** (produced by AES). | ||
| 1087 | + - 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. | ||
| 1088 | +- **DMA programming with KV:** | ||
| 1089 | + 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. | ||
| 1090 | +- **KV filtering rules:** | ||
| 1091 | + 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. | ||
| 1092 | +- **AES API updates:** | ||
| 1093 | + - 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. | ||
| 1094 | + - 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. | ||
| 1095 | + - AES operations used to decrypt Key Content into KV23 must be performed using automatic mode; manual operation is not supported for this process. | ||
| 1096 | + - Firmware shall execute the clear operation after any AES operation used to generate or load the MEK. | ||
| 1097 | +- **Strap validation:** | ||
| 1098 | + Read and confirm valid values for: | ||
| 1099 | + - [SS_KEY_RELEASE_BASE_ADDR](https://chipsalliance.github.io/caliptra-rtl/main/internal-regs/?p=clp.soc_ifc_reg.SS_KEY_RELEASE_BASE_ADDR_L) | ||
| 1100 | + - [KEY_RELEASE_KEY_SIZE](https://chipsalliance.github.io/caliptra-rtl/main/internal-regs/?p=clp.soc_ifc_reg.SS_KEY_RELEASE_SIZE) | ||
| 1101 | +- **Firmware must clear any obfuscated MEK from memory immediately after use.** | ||
| 971 | 1102 | ||
| 972 | 1103 | ## Integrator RTL modification requirements | |
| 973 | 1104 | ||
| @@ -1047,14 +1178,14 @@ | |||
| 1047 | 1178 | 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. | |
| 1048 | 1179 | ||
| 1049 | 1180 | ## Analysis of missing synchronizers | |
| 1050 | -* All of the signals, whether single-bit or multi-bit, originate from the CalitpraClockDomain clock and their endpoint is the JTAG clock domain. | ||
| 1181 | +* All of the signals, whether single-bit or multi-bit, originate from the CaliptraClockDomain clock and their endpoint is the JTAG clock domain. | ||
| 1051 | 1182 | * The violations occur on the read path to the JTAG. | |
| 1052 | 1183 | * We only need to synchronize the controlling signal for this interface. | |
| 1053 | 1184 | * 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. | |
| 1054 | 1185 | ||
| 1055 | 1186 | The following code snippets and schematic diagrams illustrate the CDC violations that end at the JTAG interface. | |
| 1056 | 1187 | ||
| 1057 | -*Figure 8: Schematic diagram and code snippet showing JTAG-originating CDC violations* | ||
| 1188 | +*Figure: Schematic diagram and code snippet showing JTAG-originating CDC violations* | ||
| 1058 | 1189 | ||
| 1059 | 1190 |  | |
| 1060 | 1191 | ||
| @@ -1111,7 +1242,7 @@ | |||
| 1111 | 1242 | ||
| 1112 | 1243 | The reset definitions can be visually represented as shown in the following diagram. | |
| 1113 | 1244 | ||
| 1114 | -*Figure 9: Reset tree for Caliptra* | ||
| 1245 | +*Figure: Reset tree for Caliptra* | ||
| 1115 | 1246 | ||
| 1116 | 1247 |  | |
| 1117 | 1248 | ||
| @@ -1138,7 +1269,7 @@ | |||
| 1138 | 1269 | ||
| 1139 | 1270 | The reset sequencing is illustrated in the following waveform. | |
| 1140 | 1271 | ||
| 1141 | -*Figure 10: Reset sequencing waveform for Caliptra* | ||
| 1272 | +*Figure: Reset sequencing waveform for Caliptra* | ||
| 1142 | 1273 | ||
| 1143 | 1274 |  | |
| 1144 | 1275 | ||
| @@ -1205,7 +1336,7 @@ | |||
| 1205 | 1336 | ||
| 1206 | 1337 | For violations in Sl No 1 and 2, the schematic for the crossing is shown in the following figure. | |
| 1207 | 1338 | ||
| 1208 | -*Figure 11: Schematic for RDC violations #1 and #2* | ||
| 1339 | +*Figure: Schematic for RDC violations #1 and #2* | ||
| 1209 | 1340 | ||
| 1210 | 1341 |  | |
| 1211 | 1342 | ||
| @@ -1213,11 +1344,11 @@ | |||
| 1213 | 1344 | ||
| 1214 | 1345 | For violations in Sl No 3 and 4, the schematic for the crossing is shown in the following figure. | |
| 1215 | 1346 | ||
| 1216 | -*Figure 12: Schematic for RDC violations #3 and #4* | ||
| 1347 | +*Figure: Schematic for RDC violations #3 and #4* | ||
| 1217 | 1348 | ||
| 1218 | 1349 |  | |
| 1219 | 1350 | ||
| 1220 | -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*. | ||
| 1351 | +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_precon*. | ||
| 1221 | 1352 | ||
| 1222 | 1353 | The fifo load and wr_data equations are as follows: | |
| 1223 | 1354 | ||
Image not present in this version
