eFuse Shadow Register Scan Protection

DFT scan test and debug scandump share the scan chain infrastructure. Any flop placed on a scan chain can be shifted out, and any flop on a dumpable chain can be observed by a debug user. The SMC eFuse shadow registers hold the LOCKS field, which is the sole enforcement point for read and write access control over the entire SMC fuse map. If those flops were scannable, an attacker could shift a cleared LOCKS value into the shadow array and defeat the access controls without touching the fuse macro itself. This section describes how the LOCKS shadow words are excluded from every scan chain.

The asset classes referenced here (Class 1 / Class 2 / Class 3) are defined authoritatively in the SEP Lifecycle Controller chapter, Asset and Scan-Chain Protection. This section records how they apply to the SMC eFuse controller.

1. SMC eFuse Asset Classification

Table 1 relates the SMC fuse contents to their security class and scan policy.

Table 1. SMC eFuse shadow register classification
Class SMC content Scan policy

Class 1a (confidentiality)

none

The SMC fuse map holds no device secrets — it carries identifiers (JTAG_PUBLIC_IDENTITY, I2C_I3C_ID), boot configuration (SMC_CONFIG, OCCP_TRANSPORT_TIMEOUT), and spare regions. There are no keys, no UIDs used as key material, and no token registers. Consequently no confidentiality masking is required.

Class 1b (integrity)

LOCKS

Excluded from every scan chain. Never scannable, never dumpable, for any LC state or debug grant.

Class 2 (secret-bearing)

none

The SMC eFuse controller instantiates no cryptographic engine and no key vault, so it contributes no Class 2 scan roots and needs no dedicated secret-bearing chain.

Class 3 (general)

All remaining fuse-map words

Normal scan and scandump handling, subject to the SMC debug policy.

Because SMC has no Class 1a asset, secure_tm is not used for secret disconnection in the SMC eFuse controller: secure_tm_i is tied to 1’b0 and SECRET_SHADOW_RANGES is left at '0. This differs from SEP, where secure_tm disconnects the UID / CLASS_KEY sources from their Class 2 consumers.

2. Implementation

efuse_shadow_regs keeps its shadow storage in two separately named arrays and reconstructs the public register view from both. The array holding Class 1 words is named with an _n0_scan suffix, which is the reserved naming handle the synthesis scan-insertion flow uses to identify the flops it must leave off all scan chains:

  • shadow_efuse_values_n0_scan — Class 1 words, excluded from scan.

  • shadow_efuse_values — Class 3 words, normal scan handling.

Which words land in the Class 1 array is set by the CLASS1_SHADOW_RANGES parameter. smc_efuse_wrapper drives it from smc_efuse_pkg::Class1ShadowRanges, which derives the range from the generated RDL metadata rather than hard-coding word indices, so the exclusion follows the register map if the map is regenerated:

localparam efuse_pkg::shadow_word_range_map_t Class1ShadowRanges = '{
    0: efuse_pkg::make_shadow_word_range(
        LOCKS_REG_OFFSET, $bits(smc_efuse_map_locks_reg_t), NumFuseWordWidth),
    default: '0
};

LOCKS sits at fuse-map offset 0x0 and is 64 bits wide, so this resolves to shadow words 0 and 1.

Table 2 maps fuse fields to their shadow-register word ranges.

Table 2. SMC shadow word allocation
Quantity Value

Fuse map size

1 KB (8192 bits, 256 x 32-bit words)

Class 1 words (shadow_efuse_values_n0_scan)

2 (words 0-1, LOCKS)

Class 3 words (shadow_efuse_values)

254

Three ASSERT_INIT checks in efuse_shadow_regs verify at elaboration that the configured ranges are well formed, non-overlapping, and inside the shadow array, so a bad range map is a build failure rather than a silent loss of protection.

3. Downstream Lock Path

Excluding the LOCKS shadow flops is only sufficient if no scannable flop downstream of them re-derives the lock decision. In the SMC eFuse controller this holds by construction: efuse_shadow_reg_access_control, which compares the incoming APB address against the field map and produces the write_locked / read_locked decisions, is purely combinational. There is no intermediate state element between the Class 1 shadow words and the APB write-enable and read-data paths that they gate.

The one sequential consumer of that logic is locked_field_access_interrupt_o, which reports that a locked-field access was attempted. It carries an access-violation event, not lock state, so observing it does not reveal or alter the LOCKS value.

4. Notes for DFT

  • The _n0_scan suffix is a Class 1 marker and takes precedence over any enclosing scan hierarchy. Do not rename it; the exclusion is carried entirely by the signal name, as there is no separate constraint list in this repository.

  • efuse_shadow_regs also declares chiplet_state_change_completed_n0_scan and sop_state_change_completed_n0_scan. These serve the SEP RMA token / LC state transition path. In the SMC instance HAS_LC_STATE is 1’b0 and both are driven to a constant 1’b1, so they hold no SMC state; they are expected to be constant-propagated away.

  • Adding a secret or a new integrity-critical field to the SMC fuse map requires extending Class1ShadowRanges (and, for a confidentiality asset, SECRET_SHADOW_RANGES plus a real secure_tm_i source). Adding the register to the RDL alone does not confer scan protection.

5. Verification

smc_efuse_shadow_lock_matrix_test exercises reads and writes across the LOCKS matrix and therefore covers the relocated words functionally, confirming that moving LOCKS into the Class 1 array does not change access-control behaviour.