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
      • Macro Choice and Wrappers
      • Shared Test and Repair
      • Retention and Power Gating of SRAM
    • ECC and Error Handling
    • External Memory Controller Integration
    • Boot ROM and Boot Modes
    • eFuse and OTP
    • 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

←Memory Subsystem Integration
  1. Topics
  2. SoC Design
  3. Memories, Boot and Security
  4. Memory Subsystem Integration
  5. Retention and Power Gating of SRAM
On this page

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

    Retention and Power Gating of SRAM

    Keeping SRAM0 alive through sleep: retention rails, isolation, wake timing and the contents check.

    Why it matters

    This lesson has one job: bring the chip out of sleep with its memory intact. NanoSoC powers off the whole switchable domain in SLEEP yet wakes straight into the SRAM0 image instead of reloading over SPI. That trick works only because SRAM0's arrays sit on the always-on rail in retention while their wrapper logic sleeps, and every signal crossing between them is clamped. Get the order wrong and the wake image is corrupt; miss a clamp and the wake interrupt fires spuriously.

    The core idea

    Retention is a third power state for the memory: the array keeps its bits at a lowered leakage, here 60 percent of normal, while the periphery loses power. On NanoSoC the SRAM0 arrays live in PD_AON and the wrapper logic in PD_SW, so entering sleep isolates first, then resets, then opens the switch. Wake is not a plain reversal: it is the entry sequence with isolation released before the resets. The switch closes with a 64-cycle ramp, power-good is seen, the PLL relocks, the clocks open, isolation is released 4 system clocks later while the resets are still asserted, the system reset is released 18 system clocks after that, and the CPU reset is released last. The full sequences are 70 peripheral clocks down at 2.917 microseconds and 14.073 microseconds up. The isolation count is exact: 52 clamp cells on the SRAM0 macro port, part of the 114 total, and the two interrupt lines that were once missed are the warning that the count must be checked by a tool, not by eye.

    Diagram
    # not-run: NanoSoC sleep arithmetic, NanoSoC teaching values
    Power-down: 70 clk_per x 41.6667 ns = 2,916.7 ns = 2.917 us.
    Power-up: (64 + 8 + 256 + 2) x 41.6667 ns + (4 + 18 + 8) x 10.4167 ns + 2 x 5.2083 ns
      = 13,750 + 312.5 + 10.42 = 14,072.9 ns = 14.073 us.
    SRAM0 retention leakage: 0.72 mW against 1.20 mW normal (0.6x factor).
    Wake path: RST_CAUSE[3] set, ROM jumps to 0x2000_0000, no SPI reload.
    example.py
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    iso_sram0 = 14 + 32 + 4 + 2
    iso_apb = 12 + 32 + 3
    iso_rom = 12 + 1
    iso_irq = 2
    total = iso_sram0 + iso_apb + iso_rom + iso_irq
    assert iso_sram0 == 52, iso_sram0
    assert iso_apb == 47, iso_apb
    assert iso_rom == 13, iso_rom
    assert total == 114, total
    print(f"SRAM0 {iso_sram0}, APB {iso_apb}, ROM {iso_rom}, IRQ {iso_irq}")
    print("PASS: isolation adds to 114 clamp cells")

    What the review looks for

    • The power intent names SRAM0 retention explicitly, with the array rail, the wrapper rail and the save condition each stated.

    • The isolation list totals 114 with the SRAM0 52 shown, and the check runs from the power-intent description.

    • The wake test reads back a known SRAM0 pattern written before sleep; retention is proven by data, not by a status bit.

    • On wake the ROM reads RST_CAUSE first and skips the SRAM0 clear, so the retained image is not wiped before the jump.

    Verify and debug

    Write a checkerboard across all of SRAM0, enter and exit SLEEP in power-aware simulation, and read back every word: one mismatch means retention, isolation or sequencing failed, and the failing address says which. Check the interrupt lines first, because the missing-isolation failure shows up as a spurious wake before any data check runs. Confirm the ROM takes the retained-image branch by observing the jump to 0x2000_0000 with no SPI traffic.

    Missing or wrong isolation on a powered-down domain: the two interrupt lines float, INTC shows unknown values in gate-level power-aware simulation, and the chip wakes in a loop. Symptom: spurious wake the moment power is cut. Caught by a power-intent cross-domain check listing all 114 signals. Fix: clamp every signal from the switched domain, asserted before reset and power-off.

    If asked what survives sleep on NanoSoC, answer with the domain: everything in PD_AON survives, which is the SRAM0 contents, the reset-cause register and the configuration of the always-on peripherals (the GPIO interrupt enables and the interrupt controller enables that wake the chip, and the fuse shadow registers); nothing in PD_SW does. Then give the wake order: power, relock, clocks, isolation release, reset release (system first, CPU last), jump.

    Check yourself Why is SRAM0 in PD_AON while SRAM1 is in PD_SW?

    Because SRAM0 holds the retained image the wake path jumps to. SRAM1 holds working data that sleep is allowed to discard, so it sleeps with the switchable domain to save its leakage.

    Related topics

    • Shared Test and Repair

    • Boot ROM and Boot Modes

    • Repair, Lifecycle and Locking

    Previous

    153 / 289

    Next: ECC and Error Handling

    Up next

    Up nextECC and Error Handling

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error

    See also

    • Macro Choice and Wrappers