Life Cycle Controller (LCC)

The LCC decodes the OTP controller’s LC_STATE shadow output; it does not sequence lifecycle transitions itself. Before fuse sensing completes, that output holds INVALID (4’b1111). The LCC then follows the sensed state and its feature-control profile.

The raw four-bit OTP value is carried as a complementary code in the shadow path. A failed integrity check sets lc_sigint_err and forces the base feature vector to zero. SEC_DIS is applied afterward and can override that result; see Overrides and Final Gates (SEC_DIS).

Hardware orders the RMA token transitions: RMA_SIP_TOKEN first admits RMA_SIP, then RMA_CHIPLET_TOKEN admits RMA_CHIPLET. Volatile demotion is separate from those transitions and does not change the OTP state.

Key Manager includes DEMOTE_1/2 with CHIPLET_UID, SIP_UID, SYS_UID and LC_STATE in key derivation, separating demoted-state keys from non-demoted production keys.

SEP lifecycle state machine shows the lifecycle states and transition paths.

Each rounded box in SEP lifecycle state machine is a lifecycle state with its raw OTP encoding, where X marks a bit that does not change the state. LC_STATE bits can only be set, so each arrow names the bit that it sets. Setting LC_STATE[1] requires an RMA_SIP token match. Setting LC_STATE[2] requires an RMA_CHIPLET token match and a state that already has LC_STATE[1] set. Every other encoding is INVALID and permanent: for example, setting LC_STATE[3] in any state other than TEST_DEV, or setting any further bit in PROD_END. Before fuse sensing completes, the shadow output holds the INVALID encoding 4’b1111. The dashed box is the volatile demotion overlay, which acts in TEST_DEV and PROD without changing the encoding.

SEP lifecycle state encodings lists the raw OTP encodings. The complementary shadow encoding is a transport integrity check, not an additional lifecycle state.

The SiP owner controls the debug-access network between chiplets. Each chiplet owner controls access to its own local assets. A system has one shared SiP-owner domain and a local domain for each chiplet with independently protected assets.

SIP_DBG admits and forwards external debug traffic at each chiplet with a local SEP/LCC. Access to local resources additionally requires CHIPLET_DBG; SEP resources also require SEP_DBG. Opening another chiplet’s local debug gate is unnecessary when traffic only passes through it.

A chiplet without a local SEP/LCC contributes no local disable vector. The preceding LCC-bearing chiplet controls forwarding to it, as described in Non-Primary Chiplets.

In SEP security domains, each chiplet with a SEP gates the debug path from its PTAP downwards: SIP_DBG opens the Case 1 targets, CHIPLET_DBG adds the Case 2 targets and SEP_DBG adds the Case 3 targets, each listed to the right of its gate. The targets are the debug paths that sep_lifecycle_ctrl disables through dbg_disable_o and the two fuse DFT disables, as given in Debug and Test Port Path Gating; the fuse DFT paths also need their own SEP_FUSE_DBG or SMC_FUSE_DBG bit. The green gate belongs to the SiP-owner domain and is a DBG_2 bit, opened in the field by Demotion 2. The cream gates belong to the chiplet-owner domain and are DBG_1 bits, opened by Demotion 1. The I/O STAP forwards the chain to the next chiplet’s PTAP.

In SEP security domains, chiplet 1 is primary, chiplet 2 has no SEP, and chiplet 3 has its own LCC:

The per-path conjunctions are listed in Debug and Test Port Path Gating.

feat_ctrl_o uses positive logic: 1 enables a feature. The 64-bit SIP_DIS and SYS_DIS shadows use negative logic: 1 restricts a feature. The applicable masks depend on lifecycle state and demotion. Where both apply, the enable is ~(SIP_DIS | SYS_DIS).

Per-LC-state feature control profile gives the complete state-dependent formulas. The final SEC_DIS override is described in Overrides and Final Gates (SEC_DIS).

DEMOTE_1 and DEMOTE_2 each contain a demote bit and a lock bit. They are two registers, not separate demotion and lock register banks. Cold reset clears both and removes the volatile debug profile.

The controls are independent: either may be set first or used alone. In TEST_DEV, demotion forces its group open; in PROD, it enables the group subject to the disable vectors. Other lifecycle profiles and function bits are unchanged. The complete formulas are in Per-LC-state feature control profile.

Opening local debug does not open the external access path. For example, a Case 3 SEP debug path requires both groups; see Debug and Test Port Path Gating. The LCC applies register values without authenticating the writer or a manifest. Firmware authorization is discussed under Firmware Authorization.

Two distinct DFT operations use the scan chains, and the protection model treats them differently:

The integration must preserve test coverage without exposing live secrets. The rules below define the required scan partitioning and command gates; feature-vector generation alone does not implement or verify DFT insertion.

Primary chiplets always include a local SEP and LCC; the asset partitioning described in Asset and Scan-Chain Protection applies directly. Non-primary chiplets may not include a local SEP, in which case debug access is governed by the SiP-owner domain. The primary chiplet’s SiP-owner feature control gates the DFT traffic before forwarding it to the non-primary chiplet (see Multiple Security Domains).

For non-primary chiplets, the adopter is responsible for:

The SIP_DBG mechanism documented in Disable Vector Format (SIP_DIS / SYS_DIS) gates the DTP path on the primary chiplet. The primary LCC therefore governs debug access to a non-primary chiplet by controlling whether DFT traffic is forwarded to it.

If an adopter integrates SEP into a chiplet with assets that require their own scan-chain protection — assets not covered by the chiplet-scope SEP scan chain or the general-logic scan chain in Asset and Scan-Chain Protection — the LCC architecture accommodates this via the reserved bits in feat_ctrl_o (and the matching positions in SIP_DIS / SYS_DIS):

OCAH assigns no standard function to these reserved bits. An adopter may allocate a DBG_2 bit to an additional inter-chiplet DFT forwarding path; the bit is consumed on the LCC-bearing chiplet to gate the corresponding traffic before it is forwarded downstream.

Each new scan chain or forwarding path is gated by exactly one reserved bit. The corresponding bit position in SIP_DIS or SYS_DIS (chosen by which predecessor owner sets the default policy — see DIS Vector Ownership: Predecessor-Programs-Disables) determines the default OTP-programmed restriction.

Constraints any adopter extension must satisfy:

The LCC does not inspect manifests or signatures. It supplies the lifecycle state, and the OTP Fuse Controller chapter defines the fuse fields that govern firmware authorization: SBOOT_DIS, the SIP_DIS and SYS_DIS debug vectors, the public-key digests, CHIPLET_PUBK_REVOKE, and the REQUIRED_SIGNERS and REQUIRED_ALGS fields reserved for a deferred multi-owner signing model. Firmware, not the LCC, interprets them. The SEP Boot ROM reads CHIPLET_DBG from the SIP_DIS and SYS_DIS fuse shadows rather than from FEAT_CTRL, because SEC_DIS and demotion can force FEAT_CTRL open on a part whose fuses disable debug.

The Secure Boot Decision section of the SEP Boot ROM appendix in the Programmer’s Guide specifies when the ROM requires a verified manifest, including the rule that a debug-locked TEST_DEV or RMA_SiP part is treated as PROD. The SiP Secure Boot application note summarizes that decision and describes the multi-owner model, which the current ROM does not implement, under deferred multi-owner signing model there.