Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutRoadmapCareersInternshipsFAQContactPrivacyTerms
Skip to lesson

Course contents

  • How to Use This Course
  • The NanoSoC Tour
  • Reading Path
  • SoC Glossary10
  • SoC Metrics Reference
  • SoC Cheatsheet
  • What SoC Integration Is12
  • Architecture and Budgets21
  • Memory Maps and Address Decode26
  • Interconnect and Bus Fabrics26
  • Clock and Reset Architecture24
  • Power Architecture21
  • Interrupts, DMA and Peripherals15
  • Memories, Boot and Security21
    • Memory Subsystem Integration
    • ECC and Error Handling
    • External Memory Controller Integration
    • Boot ROM and Boot Modes
    • eFuse and OTP
      • What Lives in the Fuse Array
      • Read-Out Timing and Distribution
      • Repair, Lifecycle and Locking
    • Secure Boot and Root of Trust
    • Security Architecture
  • IP Integration and Handoff21
  • Top-Level Verification and Bring-up21
  • Package, Pads and I/O18
  • Chip Signoff and Tapeout18
  • SoC Interview Prep16
  • Capstone: Integrate NanoSoC14
Loading lesson

←eFuse and OTP
  1. Topics
  2. SoC Design
  3. Memories, Boot and Security
  4. eFuse and OTP
  5. Repair, Lifecycle and Locking
On this page

    Part 8 of 14, lesson 15 of 21Part 8 of 14/Memories, Boot and Security/Lesson 15 of 21All levels

    Repair, Lifecycle and Locking

    From tester discovery to wrapper pins: repair routing, monotonic lifecycle states, and locking test paths.

    Why it matters

    This lesson has one job: make the fuse values stick where they matter across the die's whole life. Repair fuses must travel from the tester log to the SRAM wrapper pins at every reset; lifecycle state must advance from manufacture to field without ever retreating; and test modes that bypass security must lock as the lifecycle advances. A repair that applies only on the tester is a yield loss, and a debug port that stays open in the field is a security escape.

    The core idea

    Repair flows in three hops: the tester records failing addresses during MBIST, the fuse programmer blows the repair field, and at every reset the shadow registers drive the wrapper repair pins before the first access. The chain is checked end to end, never hop by hop, because each hop looks correct alone while the combination silently drops bits. Lifecycle is a monotonic ladder of NanoSoC teaching states: manufacture, test, OEM provisioning and field, each enabling less than the last. Return (a returned-material analysis state) is not a rung: it is a terminal state, reachable from field only by an authorised command, that never leads back to field, keeps the secrets locked, and opens debug only inside a scoped, logged window. Test mode and scan access live at the top of the ladder and lock below it; the debug infrastructure that remains in the field answers only through the authenticated path the security architecture defines.

    State

    Repair writable

    Test mode

    Debug

    Rule

    Manufacture

    Yes, on tester

    Open

    Open

    No secrets present yet

    Test

    Yes, on tester

    Open

    Open

    Repair fields still writable

    Provisioning

    No, blown

    Restricted

    Authenticated

    Secrets programmed here

    Field

    No

    Locked

    Authenticated only

    Only an authorised command can move on, and only to Return

    Return (terminal)

    No

    Scoped, authorised window

    Authorised, scoped

    Reached from Field only; never goes back to Field; secrets stay locked; every reopen is logged

    What the review looks for

    • The repair chain has one end-to-end test: planted fault, tester log, blown fuse model, reset, retest passes.

    • Lifecycle transitions are monotonic in the controller RTL with an assertion that fires on any retreat, and Return has no outgoing transition.

    • Every test and debug path names the lifecycle states where it is open, restricted and locked.

    Verify and debug

    Model the full repair chain in simulation with a stuck-at fault: run MBIST, capture the repair address, load it through the fuse model, reset, and confirm the retest passes with the wrapper repair pins showing the expected values. Then attempt each lifecycle retreat in a scratch build and confirm the assertion fires. If repair works on the tester model but not after reset, the shadow-to-wrapper path was never connected.

    Test mode left open in mission mode: a scan enable or test pin floats or shares a functional pin with the wrong pull. Symptom: the chip sticks in scan or shifts unexpectedly. Caught by DFT checks and a pin-state review at reset. Fix: tie and strap test pins with glitch-free control, and lock them by lifecycle state.

    If asked who can write a fuse, answer with the ladder: each fuse field is written by the owner of its lifecycle stage (tester at manufacture and test, the secure facility and OEM at provisioning) and never after field. Then explain the consequence: every post-silicon fix for fused values must live in patchable logic or software, never in the array.

    Check yourself A returned field unit needs failure analysis but its debug port is locked. What is the correct path?

    Authorised move to the terminal return state: authenticated, logged, and scoped to the analysis, with the secrets still locked and no path back to field. Silent unlocks, shared passwords and permanent reopening each convert a debug feature into an attack path.

    Related topics

    • Read-Out Timing and Distribution

    • Next: Secure Boot and Root of Trust

    Previous

    165 / 289

    Next: IP Integration and Handoff

    Up next

    Up nextIP Integration and Handoff

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error

    See also

    • What Lives in the Fuse Array