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
    • Secure Boot and Root of Trust
    • Security Architecture
      • The AxPROT Partition
      • Lifecycle States and Debug Locking
      • The Integrator Security Checklist
  • 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

←Security Architecture
  1. Topics
  2. SoC Design
  3. Memories, Boot and Security
  4. Security Architecture
  5. Lifecycle States and Debug Locking
On this page

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

    Lifecycle States and Debug Locking

    Monotonic states from manufacture to field: what each state opens, what it locks, and how debug closes.

    Why it matters

    This lesson has one job: keep yesterday's access from becoming today's attack. Manufacture needs open test and debug; the field needs both locked; provisioning sits between, writing secrets while still half open. Lifecycle states draw those lines, and debug locking enforces them. A debug path that ignores lifecycle is a second, unaudited privilege system bolted onto the first.

    The core idea

    The ladder is monotonic: manufacture, test, provisioning and field, each enabling less than the last, and it never steps back. Return is a fifth, terminal state: it is reached from field only by an authorised command, never leads back to field, keeps the secrets locked, and opens debug inside a scoped, logged window for failure analysis. Test mode and scan belong to the top of the ladder and lock below provisioning; field debug answers only through authentication, with the secure-boot recovery path as its model. The fuse topic owns the storage of the state; this lesson owns its enforcement: every debug and test enable is qualified by the current lifecycle state, and any retreat attempt raises a fault. The NanoSoC teaching values mirror the fuse table's five states so the two lessons share one vocabulary.

    Diagram
    # not-run: lifecycle transitions, NanoSoC teaching values
    manufacture -> test -> provisioning -> field -> return (terminal).
    Forward moves: tester or authorised provisioning command; field -> return by authorised command only.
    Backward moves: none exist; return has no outgoing transition and never reaches field again.
    Debug enable = (state in {manufacture, test}) |
      (authenticated AND state in {provisioning, field}) |
      (authenticated AND scoped, logged window AND state == return).
    Any enable asserted outside its states is a fault, not a request.

    What the review looks for

    • Every debug and test path names the states where it is open, authenticated and locked; no path is stateless.

    • Retreat is impossible in the RTL with an assertion to prove it, and return is terminal, authorised and logged.

    • Field units expose exactly one debug path, authenticated, with its failure behaviour matching the secure-boot fail state.

    Verify and debug

    Attempt every transition in both directions in simulation and confirm forward moves enable the documented paths while any retreat attempt faults. Then probe each debug interface in the field state without credentials and confirm uniform refusal that discloses nothing about the lock design. If a path answers, its lifecycle qualifier is missing or tied to the wrong state.

    Debug access lost in a low-power state, or debug left open into it: the debug path sits in a gated domain so it vanishes in sleep, or isolation around it is missing so sleep leaks through it. Symptom: debugger disconnects on sleep, or sleep never holds. Caught by a low-power debug test that sleeps with the debugger attached. Fix: keep the debug-access path always on or behind a power request, with isolation that matches the domain.

    If asked how you ship debug without shipping an attack, answer with the ladder: open early, authenticated late, locked by state with no retreat. Then name the one field path and its authentication.

    Check yourself A field failure needs scan access for diagnosis. What are the legitimate options?

    A move to the terminal return state with scoped, logged reopening (the unit never goes back to field), or authenticated debug through the field path. Permanent unlock, shared credentials, or a hidden strap each trade one diagnosis for an open fleet.

    Related topics

    • The AxPROT Partition

    • Next: The Integrator Security Checklist

    • Bring-up: Secure Boot Enablement and Fuse Bring-up

    Previous

    173 / 289

    Next: The Integrator Security Checklist

    Up next

    Up nextThe Integrator Security Checklist

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error