Changes to Integration Specification

Comparing version 2.1 to 2.0
+86 additions -28 deletions
@@ -1,12 +1,12 @@
11 <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/76a7d85c90bd88840834513979cddc90c60fe238/docs/CaliptraIntegrationSpecification.md" target="_blank">chipsalliance/caliptra-rtl/docs/CaliptraIntegrationSpecification.md</a> @ <code>76a7d85</code>
33 </div>
44
55 ![OCP Logo](../images/caliptra-rtl/docs/images/OCP_logo.png)
66
77 <p style="text-align: center;">Caliptra Integration Specification</p>
88
9-<p style="text-align: center;">Version 2.0.3</p>
9+<p style="text-align: center;">Version 2.1</p>
1010
1111 <div style="page-break-after: always"></div>
1212
@@ -31,7 +31,7 @@
3131 | IP/Block | GitHub URL | Documentation | Link |
3232 | :--------- | :--------- | :--------- | :--------- |
3333 | 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) |
3535 | SHA 256 | [secworks/sha256: Hardware implementation of the SHA-256 cryptographic hash function (github.com)](https://github.com/secworks/sha256) |||
3636 | SHA 512 ||||
3737 | SPI Controller | <https://github.com/pulp-platform/axi_spi_master> |||
@@ -45,7 +45,7 @@
4545
4646 The following figure shows the SoC interface definition.
4747
48-*Figure 1: SoC Interface Block Diagram*
48+*Figure: SoC Interface Block Diagram*
4949
5050 ![](../images/caliptra-rtl/docs/images/Caliptra_soc_interface_block.png)
5151
@@ -68,6 +68,7 @@
6868
6969 | **Defines** | **Defines file** | **Description** |
7070 | :--------- | :--------- | :--------- |
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. |
7172 | CALIPTRA_INTERNAL_TRNG | config_defines.svh | Defining this enables the internal TRNG source. This must be set to 1 in Subsystem mode. |
7273 | 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 |
7374 | 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. |
@@ -183,7 +184,7 @@
183184 Strobe width describes the number of bits enabled by each strobe. All strobed memories are byte enabled in the design.
184185 See [ABR Memory requirement](https://github.com/chipsalliance/adams-bridge/blob/main/docs/AdamsBridgeHardwareSpecification.md#memory-requirement) for more details.
185186
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.
187188
188189 The table below details the interface required for each SRAM. Driver direction is from the perspective of Caliptra.
189190
@@ -210,6 +211,7 @@
210211
211212
212213 *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.
213215 | Signal name | Width | Driver | Synchronous (as viewed from Caliptra’s boundary) | Description |
214216 | :--------- | :--------- | :--------- | :--------- | :--------- |
215217 | trace_rv_i_insn_ip | 32 | Output | Synchronous to clk | Trace signals from Caliptra RV core instance. Refer to VeeR documentation for more details. |
@@ -228,8 +230,11 @@
228230 | 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. |
229231 | 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. |
230232 | 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. |
231234 | 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. |
232235 | 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. |
233238 | 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. |
234239 | 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. |
235240 | 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. |
@@ -237,7 +242,8 @@
237242 | 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. |
238243 | 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. |
239244 | 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. |
241247 | ss_dbg_manuf_enable | 1 | Output | Synchronous to clk | Enables unlock of the debug interface in the Manufacturing security state, for Subsystem mode only. |
242248 | 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. |
243249 | ss_generic_fw_exec_ctrl | 128 | Output | Synchronous to clk | Enables SoC processors to execute firmware once authenticated by Caliptra. |
@@ -284,17 +290,17 @@
284290
285291 **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:
286292
287-- `SS_DBG_MANUF_SERVICE_REG_RSP`
293+- `SS_DBG_SERVICE_REG_RSP`
288294 - `SS_SOC_DBG_UNLOCK_LEVEL`
289295 - `SS_GENERIC_FW_EXEC_CTRL`
290296
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.
297+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.
292298
293299 ## Interface rules
294300
295301 The following figure shows the reset rules and timing for cold boot flows.
296302
297-*Figure 2: Reset rules and timing diagram*
303+*Figure: Reset rules and timing diagram*
298304
299305 ![](../images/caliptra-rtl/docs/images/Caliptra_reset_timing.png)
300306
@@ -425,11 +431,7 @@
425431
426432 ## Boot FSM
427433
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-![](../images/caliptra-rtl/docs/images/Caliptra_mbox_boot_FSM.png)
434+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.
433435
434436 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.
435437 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 +444,31 @@
442444
443445 The AXI_USER bits are used by the SoC to identify which device is accessing the mailbox.
444446
447+## External Staging Area
448+
449+To save SRAM area when Caliptra operates in Subsystem mode, the mailbox (MBOX) SRAM is reduced to **16 KiB**.
450+Instead of passing images directly to Caliptra through the mailbox, the SoC can configure an external staging SRAM that Caliptra fetches from and processes.
451+
452+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.
453+
454+For hitless updates or other image-processing operations, the Caliptra mailbox should be used to:
455+
456+1. Notify Caliptra that an image is available for processing.
457+2. Specify the command to run on the image.
458+3. Indicate the size of the image in the staging area.
459+
460+References:
461+
462+- [Caliptra ROM MBOX Commands](https://github.com/chipsalliance/caliptra-sw/blob/main/rom/dev/README.md#handling-commands-from-mailbox)
463+- [Caliptra Runtime FW MBOX Commands](https://github.com/chipsalliance/caliptra-sw/blob/main/runtime/README.md#mailbox-commands)
464+- [Caliptra HW API](#mailbox)
465+
466+
467+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.
468+
445469 ## Mailbox
446470
447-The Caliptra mailbox is a 256 KiB buffer used for exchanging data between the SoC and the Caliptra microcontroller.
471+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.
448472
449473 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.
450474
@@ -475,7 +499,7 @@
475499
476500 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.
477501
478-*Figure 4: Sender protocol flow chart*
502+*Figure: Sender protocol flow chart*
479503
480504 ![](../images/caliptra-rtl/docs/images/Caliptra_mbox-sender.png)
481505
@@ -499,7 +523,7 @@
499523
500524 The following figure shows the receiver protocol flow.
501525
502-*Figure 5: Receiver protocol flowchart*
526+*Figure: Receiver protocol flowchart*
503527
504528 ![](../images/caliptra-rtl/docs/images/Caliptra_mbox_receiver.png)
505529
@@ -809,7 +833,7 @@
809833
810834 The following figure shows the SRAM interface timing.
811835
812-*Figure 6: SRAM interface timing*
836+*Figure: SRAM interface timing*
813837
814838 ![](../images/caliptra-rtl/docs/images/Caliptra_SRAM_interface_timing.png)
815839
@@ -837,9 +861,9 @@
837861
838862 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.
839863
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*
864+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.
865+
866+*Figure: Example machine check reliability implementation*
843867
844868 ![](../images/caliptra-rtl/docs/images/Caliptra_machine_reliability.png)
845869
@@ -898,6 +922,7 @@
898922 | 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 |
899923 | 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 |
900924 | DFT | Caliptra’s TAP should be a TAP endpoint. | Statement of conformance | Functional requirement |
925+| DFD | 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. | Synthesis report | Required for Caliptra threat model |
901926 | 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 |
902927 | 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 |
903928 | 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 |
@@ -914,7 +939,7 @@
914939 | 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 |
915940 | Resets and Clocks | SoC reset logic shall assume reset assertions are asynchronous and deassertions are synchronous. | Statement of conformance | Functional |
916941 | 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 |
942+| Resets and Clocks | SoC shall ensure Caliptra clock is derived from an on-die oscillator circuit. This is to protect against clock fault injection or clock stretching attacks. | Statement of conformance | Required for Caliptra threat model |
918943 | 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 |
919944 | Resets and Clocks | SoC should defend against external clock stop attacks. | Statement of conformance | Required for Caliptra threat model |
920945 | Resets and Clocks | SoC should defend against external clock glitching attacks. | Statement of conformance | Required for Caliptra threat model |
@@ -969,6 +994,39 @@
969994 | Multiple modules | Signed to unsigned conversion occurs |||
970995
971996
997+## OCP LOCK Caliptra ROM & Firmware Requirements
998+
999+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.
1000+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.
1001+
1002+- **DOE error status (KV write failure):**
1003+ Introduce a new status bit; ROM must check it after any DOE flow to ensure the KV write succeeded.
1004+- **HEK DOE flow**:
1005+ 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.
1006+- **Derivations & locking**:
1007+ - Derive the MDK to **KV16**, then set the **lock_wr** control bit of KV16.
1008+ - If OCP LOCK is enabled, derive **HEK** to **KV22**, then set the **lock_wr** control bit of KV23.
1009+ - Perform this **before** setting `OCP_LOCK_IN_PROGRESS` since HEK derivation depends on the **HEK seed** and **standard CDI derivatives** (from standard KV slots).
1010+- **Setting lock state:**
1011+ If OCP LOCK is enabled, ROM **MUST** set `OCP_LOCK_IN_PROGRESS` before transitioning to the First Mutable Code (FMC) image.
1012+- **KV23 usage constraints:**
1013+ Never attempt to write anything to **KV23** except **MEK** (produced by AES).
1014+ - 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.
1015+- **DMA programming with KV:**
1016+ 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.
1017+- **KV filtering rules:**
1018+ 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.
1019+- **AES API updates:**
1020+ - 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.
1021+ - 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.
1022+ - AES operations used to decrypt Key Content into KV23 must be performed using automatic mode; manual operation is not supported for this process.
1023+ - Firmware shall execute the clear operation after any AES operation used to generate or load the MEK.
1024+- **Strap validation:**
1025+ Read and confirm valid values for:
1026+ - [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)
1027+ - [KEY_RELEASE_KEY_SIZE](https://chipsalliance.github.io/caliptra-rtl/main/internal-regs/?p=clp.soc_ifc_reg.SS_KEY_RELEASE_SIZE)
1028+- **Firmware must clear any obfuscated MEK from memory immediately after use.**
1029+
9721030 ## Integrator RTL modification requirements
9731031
9741032 Several files contain code that may be specific to an integrator's implementation and should be overridden. This overridable code is either configuration parameters with integrator-specific values or modules that implement process-specific functionality. Code in these files should be modified or replaced by integrators using components from the cell library of their fabrication vendor. The following table describes recommended modifications for each file.
@@ -1047,14 +1105,14 @@
10471105 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.
10481106
10491107 ## 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.
1108+* All of the signals, whether single-bit or multi-bit, originate from the CaliptraClockDomain clock and their endpoint is the JTAG clock domain.
10511109 * The violations occur on the read path to the JTAG.
10521110 * We only need to synchronize the controlling signal for this interface.
10531111 * 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.
10541112
10551113 The following code snippets and schematic diagrams illustrate the CDC violations that end at the JTAG interface.
10561114
1057-*Figure 8: Schematic diagram and code snippet showing JTAG-originating CDC violations*
1115+*Figure: Schematic diagram and code snippet showing JTAG-originating CDC violations*
10581116
10591117 ![](../images/caliptra-rtl/docs/images/caliptra2.0_riscv_code_snippet.png)
10601118
@@ -1111,7 +1169,7 @@
11111169
11121170 The reset definitions can be visually represented as shown in the following diagram.
11131171
1114-*Figure 9: Reset tree for Caliptra*
1172+*Figure: Reset tree for Caliptra*
11151173
11161174 ![](../images/caliptra-rtl/docs/images/Reset_structure.png)
11171175
@@ -1138,7 +1196,7 @@
11381196
11391197 The reset sequencing is illustrated in the following waveform.
11401198
1141-*Figure 10: Reset sequencing waveform for Caliptra*
1199+*Figure: Reset sequencing waveform for Caliptra*
11421200
11431201 ![](../images/caliptra-rtl/docs/images/reset_sequencing.png)
11441202
@@ -1205,7 +1263,7 @@
12051263
12061264 For violations in Sl No 1 and 2, the schematic for the crossing is shown in the following figure.
12071265
1208-*Figure 11: Schematic for RDC violations #1 and #2*
1266+*Figure: Schematic for RDC violations #1 and #2*
12091267
12101268 ![](../images/caliptra-rtl/docs/images/halt_status_rdc.png)
12111269
@@ -1213,7 +1271,7 @@
12131271
12141272 For violations in Sl No 3 and 4, the schematic for the crossing is shown in the following figure.
12151273
1216-*Figure 12: Schematic for RDC violations #3 and #4*
1274+*Figure: Schematic for RDC violations #3 and #4*
12171275
12181276 ![](../images/caliptra-rtl/docs/images/entropy_RDC.png)
12191277

Image Changes

v2.0: Caliptra_mbox_boot_FSM.png

Old version

v2.1: Caliptra_mbox_boot_FSM.png

Image not present in this version

v2.0: Caliptra_soc_interface_block.png

Old version

v2.1: Caliptra_soc_interface_block.png

New version