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
    • Power Domains and States
      • Always On Versus Switchable
      • RUN, IDLE and SLEEP
      • What Is Retained and What It Costs
    • Isolation and Retention Integration
    • PMU and Power Sequencer
    • Cold-Start Power-Up Sequence
    • Supply Sequencing and PMIC
    • Thermal and Power Envelope
    • DVFS Integration
  • 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

←Power Domains and States
  1. Topics
  2. SoC Design
  3. Power Architecture
  4. Power Domains and States
  5. What Is Retained and What It Costs
On this page

    Part 6 of 14, lesson 3 of 21Part 6 of 14/Power Architecture/Lesson 3 of 21All levels

    What Is Retained and What It Costs

    What survives SLEEP on NanoSoC, what retention leakage costs, and when to retain versus re-initialise.

    Why it matters

    SLEEP on NanoSoC is only worth entering because the wake does not redo the whole boot: the SRAM0 image is still there, so the ROM jumps straight to 0x2000_0000 instead of reloading 8 KB over a 6 Mb/s SPI link. That shortcut is retention, and it has a price in leakage every second the chip sleeps. This lesson prices it and draws its boundary.

    The core idea

    Exactly two things are kept across SLEEP. The SRAM0 arrays keep every bit, held by the always-on supply at 60 percent of normal leakage, 0.72 mW instead of 1.20 mW. Everything in PD_AON that never lost power simply continues: peripheral state, the power controller, and RST_CAUSE, whose bit 3 tells wake software this was a wake rather than a cold boot. Nothing in PD_SW survives: its flops go dark with the switch, the CPU and DMA register state is gone, and the PLL must relock from scratch at 256 peripheral clocks.

    Retention costs 0.72 mW for as long as the chip sleeps; reloading the 8 KB image costs about 904 µJ and 10.9 ms of extra wake time. Retention is cheaper for any sleep shorter than about 1.26 s (904.2 µJ / 0.72 mW), and gives the faster wake at any length, so it is the default for NanoSoC. A sleep of many seconds could in principle save energy by discarding the image, but only if SRAM0 could be switched off, which the NanoSoC partition does not allow. The script below prices it.

    example.py
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    # Retention versus reload pricing, NanoSoC teaching values.
    RET_SRAM0_MW = 0.72      # SRAM0 retention leakage (mW)
    NORM_SRAM0_MW = 1.20     # SRAM0 normal leakage (mW)
    SPI_RELOAD_US = 10928.0  # 8 KB image over 6 Mb/s SPI (boot table)
    RUN_MW = 82.74
    reload_nj = RUN_MW * SPI_RELOAD_US   # 1 mW * 1 us = 1 nJ
    reload_uj = reload_nj / 1000.0       # 904.2 uJ
    assert abs(reload_uj - 904.2) < 0.1, reload_uj
    breakeven_s = reload_nj / 1e9 / (RET_SRAM0_MW / 1e3)  # ~1.256 s
    assert 1.2 < breakeven_s < 1.3, breakeven_s
    def cheaper(sleep_s):
        ret_uj = RET_SRAM0_MW * 1e3 * sleep_s   # retention leakage over the sleep (uJ)
        return "retain" if ret_uj < reload_uj else "reload"
    assert cheaper(1.0) == "retain"     # a 1 s sleep: 720 uJ of leakage < 904 uJ
    assert cheaper(2.0) == "reload"     # a 2 s sleep would favour discarding the image
    assert RET_SRAM0_MW / NORM_SRAM0_MW == 0.6
    print("PASS: retention 0.72 mW; reload 904.2 uJ; break-even ~1.26 s")

    What the review looks for

    • The retention list is closed: SRAM0 arrays (by retention) and all PD_AON state (because it never lost power), nothing claimed for PD_SW flops.

    • The wake software reads RST_CAUSE before touching any retained state, and the cold path re-initialises what the warm path assumes.

    • The 0.6 retention factor is quoted as the NanoSoC teaching value it is, with its source named.

    Verify and debug

    Test retention with a state-compare run: fill SRAM0 with a known pattern, enter SLEEP, wake on a GPIO edge from the bench fixture, and compare every word before jumping to the image. The wake path does not checksum the retained image; if the product needs integrity, add a checksum over SRAM0 before the jump and treat a mismatch as a cold boot.

    Release order on wake: power good first, then release isolation while the resets are still held, then release the resets; interleaving them lets PD_AON sample powered-but-reset values or clamped junk. Retention flops, when present, are restored after power is stable and before the reset release that uses them. See Save/Restore Sequencing for the mechanism.

    If asked what retention costs, give the NanoSoC answer first, 0.72 mW against 1.20 mW normal, 60 percent, then generalise: retention trades a leakage floor for wake latency, and the break-even, about 1.26 s here, tells you which side of it you are on; on NanoSoC SRAM0 is always-on, so retention is the default regardless.

    Check yourself Why does the wake path read RST_CAUSE before using SRAM0?

    Because only bit 3 tells a wake from a cold boot. On a cold boot SRAM0 holds garbage and must be loaded over SPI; on a wake it holds the image. Reading the cause first selects the path; assuming retention is how images jump into garbage.

    Related topics

    • RUN, IDLE and SLEEP

    • Next: Isolation and Retention Integration

    • Low Power: Retention Register Design

    Previous

    111 / 289

    Next: Reset Sources and Reset Tree

    Up next

    Up nextReset Sources and Reset Tree

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error

    See also

    • Always On Versus Switchable