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
    • Clock Sources and PLLs
    • Dividers, Muxes and Glitch-Free Switching
    • Clock Gating Architecture
    • Clock Domain Planning
    • Top-Level Crossings
    • Always-On Domain, Wake Policy and a Timer Extension
    • Reset Sources and Reset Tree
      • Reset Sources
      • The Reset Tree per Domain
      • Reset Controller Registers and Software View
    • Reset Sequencing and Release
  • Power Architecture21
  • Interrupts, DMA and Peripherals15
  • Memories, Boot and Security21
  • 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

←Reset Sources and Reset Tree
  1. Topics
  2. SoC Design
  3. Clock and Reset Architecture
  4. Reset Sources and Reset Tree
  5. Reset Controller Registers and Software View
On this page

    Part 5 of 14, lesson 21 of 24Part 5 of 14/Clock and Reset Architecture/Lesson 21 of 24All levels

    Reset Controller Registers and Software View

    The RSTPWR register file as software sees it: cause first, software reset with key, lock, power, enables and events.

    Why it matters

    After every reset the boot ROM reads one register before all others: RST_CAUSE. A driver that reprograms the DMA without checking whether the reset was a wake, losing its buffers, or that clears the cause before logging it, turns recoverable events into mysteries. This lesson walks the RSTPWR file in the order software uses it and gives the decoder every boot image shares. Its one job is the software view; the source details belong to the first lesson.

    The core idea

    The file sits in a secure-only 4 KB slot at 0x4000_6000, so only secure software resets, gates or repowers the chip. RST_CAUSE at 0x00 carries POR, PAD, SW and WAKE as write-1-to-clear bits, reset only by POR so that no later reset destroys the evidence. SWRST at 0x04 is write-only with the 0xA5 key in bits 15 down to 8: without the key the write is ignored, which keeps stray pointer writes from resetting the chip. PLL_CTRL and PLL_STATUS hold the enable and the lock flag; PWR_CTRL and PWR_STATUS hold the power-down request and the switch state; CLK_EN holds the two block enables, reset to both on; PWR_IRQ collects lock and power-up events behind a single level interrupt at the highest controller priority.

    example.py
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    # Boot decoder shared by ROM and firmware: cause bits to boot action.
    # RST_CAUSE is W1C and POR-sticky: read it first, log it, then clear.
    CAUSE_ACTION = {0: "POR: full boot, reload image over SPI",
                    1: "PAD: full boot, SRAM0 may hold a stale image, reload",
                    2: "SW: sys+cpu reset only, peripherals live, reprogram DMA",
                    3: "WAKE: resume retained SRAM0 image, skip the SPI load"}
    
    def boot_action(cause):
        hits = [CAUSE_ACTION[b] for b in range(4) if cause & (1 << b)]
        assert len(hits) >= 1, hex(cause)  # a reset always leaves a cause
        return hits
    
    assert boot_action(0x1) == [CAUSE_ACTION[0]]
    assert boot_action(0x8) == [CAUSE_ACTION[3]]
    assert boot_action(0x4) == [CAUSE_ACTION[2]]
    # SWRST key check: bits [15:8] must read 0xA5 or the write is ignored.
    SWRST_KEY = 0xA5
    assert (0xA500 | 0x1) >> 8 == SWRST_KEY
    assert 0x0001 >> 8 != SWRST_KEY  # the stray write that must not reset
    print("PASS: 4 causes decode to boot actions; SWRST key gate holds")

    What the review looks for

    • The boot image reads RST_CAUSE before any clear, and the log proves it: field returns carry the cause.

    • Every SWRST write carries the key; the test suite includes the missing-key write that must not reset.

    • Secure-only access is tested from both states: non-secure writes refused, secure writes honoured.

    Verify and debug

    Walk every register from both security states and confirm the access rules, then fire each reset source and confirm the cause bit before clearing it. A cause that never sets points at the W1C wiring or at a POR-scoped clear on the wrong path; a software reset that fires without the key points at a decoder that dropped the key check. For the power registers see the power architecture section, described in words; the reset-relevant halves are covered here.

    Register spec out of sync with RTL: headers from an old spec disagree on offsets or reset values, so drivers write the wrong bits. Caught by a register-model-versus-RTL check and a reset-value test. Fixed by generating RTL, model, header and docs from one machine-readable source.

    If asked what software does first after reset, answer with the address and the reason: read 0x4000_6000 RST_CAUSE, because the next reset may clear the evidence and the boot path depends on it.

    Check yourself Why is RST_CAUSE reset only by POR?

    So every later reset adds its bit without destroying earlier evidence: a pad reset after a wake still shows both. Only the supply loss that truly restarts history clears the record.

    Related topics

    • The Reset Tree per Domain

    • Next: Release Order and Timing

    • RTL: Reset Tree Planning

    Previous

    114 / 289

    Next: Isolation and Retention Integration

    Up next

    Up nextIsolation and Retention Integration

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error

    See also

    • Reset Sources