Retention Flops & State Across Power-Down

Chapter 10 · Section 10.4 · Low-Power GLS

Project thread — a mini-SoC peripheral that powers down but must resume (a configured mode, a position) needs retention on that state. This lesson is how; 10.6 debugs a block that powers down and back up.

1. Why Should I Learn This?

Whether state survives a power cycle is decided by retention — and it's a judgement, not a blanket.

• Retention flops save/restore selected state; ordinary flops lose it (→ X on power-up).
• Only state that must persist is retained (area/leakage cost) — like "which flops need reset" (7.2).
• Save/restore sequencing must be right or state is lost/wrong.

This is the state-preservation half of power-aware GLS (isolation, 10.3, is the leak half).

2. Real Silicon Story — the mode register that forgot itself

A peripheral configured its mode, powered down to save energy, and powered back up — in the wrong mode, misbehaving until reconfigured.

The mode register was an ordinary flop, not a retention flop. On power-down its state was lost (power-aware GLS had shown it as X on power-up); on wake it came up uninitialized and defaulted wrong. The register needed retention — a shadow that saved the mode before power-down and restored it after. Adding retention to that register (not all of them) fixed it.

Lesson: state that must survive a power-down needs a retention flop; an ordinary flop loses it. Retention is selective — apply it to the state that must persist.

3. Concept — retention flops and their sequencing

The retention flop:

• A normal flop plus a shadow element (balloon latch / shadow register) on an always-on retention supply.
• Save: before power-down, the flop's value is copied into the shadow (which stays powered).
• Restore: after power-up, the shadow's value is copied back into the repowered flop.

Non-retention vs retention (power-aware GLS):

• Ordinary flops in the domain lose state on power-down → X on power-up (repower uninitialized).
• Retention flops keep their value across the cycle (via the shadow).

Save/restore sequencing (critical):

• Save before corruption — capture the value while the domain is still powered/valid.
• Restore after power is stable — repower the flop, then copy the shadow back.
• Mis-timed: save after corruption (saves X), or restore before power stable → wrong/lost state.

Which flops need retention (the judgement, like 7.2):

• Retain only state that must survive power-down (mode/config, resumable counters/pointers).
• Don't retain state that can be re-initialized on wake — retention costs area + leakage (shadow stays on).

Scope (accuracy):

• Retention models save/restore functionally; a lost-state X on power-up is real if that state needed retention. Functional check, not power integrity (10.1). GLS dynamic; STA signs off timing (0.3).

4. Mental Model — save your work before the power cut

A retention flop is saving your document to a battery-backed drive before a planned power cut.

• Save the file before the power goes (save before corruption) — onto the drive that stays powered (the retention shadow).
• When power returns, reopen the file (restore) — after the machine has booted (power stable).
• Ordinary flops are unsaved work — the power cut loses it (X on wake).
• You don't save every scratch file — only the documents that matter (selective retention; the rest you recreate).
• Save too late (after the cut) and you save garbage; reopen too early (before boot) and it fails.

Save what matters, before the cut; reopen after boot.

5. Working Example — retention strategy and a lost-state bug

The retention strategy (UPF) and its sequencing (representative):

# UPF retention strategy — REPRESENTATIVE (10.1). Retain ONLY the state that must survive.
set_retention ret_mode -domain PD_BLK \
  -retention_supply  VDD_RET \
  -save_signal    {save_n  low}  \
  -restore_signal {restore_n low} \
  -elements {u_blk/mode_reg}                 ;# retain the mode register (NOT every flop)

# Save/restore sequencing (tool-neutral) — the ORDER that matters:
#   power-DOWN:  ... assert save (flop -> shadow, BEFORE corruption) -> switch domain off
#   power-UP:    switch domain on (power stable) -> assert restore (shadow -> flop) -> resume
#   WRONG: save AFTER corruption (saves X) | restore BEFORE power stable -> wrong/lost state
# Ordinary (non-retained) flops in PD_BLK come up X on power-up (must be re-initialized).

Practical context (representative, tool-neutral):

# Retention checklist (tool-neutral):
#   [ ] which state MUST survive power-down? -> retain ONLY that (area/leakage cost, like 7.2)
#   [ ] SAVE asserted BEFORE corruption (captures a valid value, not X)
#   [ ] RESTORE asserted AFTER power is stable (repowered flop before copy-back)
#   [ ] non-retained flops re-initialized on wake (they come up X)
#   [ ] functional check -- not power integrity (10.1)

Retained vs non-retained state across a power cycle, as a real waveform:

6. Debugging Session — state lost after wake

7. Common Mistakes

• Not retaining state that must survive power-down — it comes up X/default.
• Retaining everything. Retention costs area/leakage — retain selectively (7.2-style).
• Saving after corruption. The shadow captures X — save before power-down.
• Restoring before power is stable. Copy-back fails — restore after power-up.
• Forgetting non-retained flops need re-initialization on wake.

8. Industry Best Practices

• Identify which state must survive power-down; retain only that.
• Sequence save before corruption, restore after power-up.
• Re-initialize non-retained state on wake.
• Justify retention (area/leakage) — a deliberate, documented choice.
• Verify in the power-aware log that retained state survives and non-retained is re-initialized.

Senior Engineer Thinking

• Beginner: "The block came up wrong after power-down — the logic is broken."
• Senior: "Did that state need to survive the power-down? If so, it needs retention — was it retained, and was save before corruption, restore after power-up? If not critical, it should be re-initialized on wake."

The senior asks which state must survive, retains selectively, and checks save/restore sequencing.

Silicon Impact

Retention decides whether a block can resume after a power-saving nap — and getting it wrong is a real, user-visible silicon failure: a peripheral that forgets its configuration across a power cycle (missing retention) or restores garbage (mis-timed save/restore) misbehaves after every power event, an intermittent, power-sequence-triggered bug (0.3). The judgement mirrors reset (7.2): retention is selective — retaining everything wastes area and leakage (the shadows stay powered), while retaining too little loses needed state. Power-aware GLS is the tool that verifies it — showing retained state surviving the cycle and non-retained state coming up X for re-initialization. Correct, selective retention with proper save/restore sequencing is what makes low-power state management actually work in silicon.

Engineering Checklist

• Identified state that must survive power-down; retained only that (area/leakage).
• Save before corruption, restore after power-up (sequencing).
• Re-initialized non-retained state on wake.
• Verified retained state survives and non-retained is re-initialized (power-aware log).
• Kept it a functional check (not power integrity, 10.1).

Try Yourself

1. Put a mode register in a switchable domain as an ordinary flop; power the domain down and up — the mode comes up X/default (lost).
2. Observe: ordinary flops don't survive power-down.
3. Change: add a retention strategy for the mode register (save before power-down, restore after power-up).
4. Expect: the mode survives the cycle. Then mis-time the save (after corruption) and watch it save X — proving sequencing matters.

Power-aware simulation with retention cells is an EDA-tool feature; save/restore behaviour is standardized and illustrated tool-neutrally here.

Interview Perspective

• Weak: "Flops keep their value through power-down."
• Good: "Ordinary flops lose state on power-down; retention flops save it to a shadow and restore it on power-up."
• Senior: "A retention flop has a shadow on an always-on supply — save copies the value before power-down (before corruption), restore copies it back after power-up (power stable). Retention is selective — only state that must survive, because of area/leakage — the rest is re-initialized on wake. Missing or mis-timed retention loses/corrupts state; power-aware GLS reveals it."

9. Interview / Review Questions

10. Key Takeaways

• Ordinary flops in a switchable domain lose state on power-down (power-aware GLS shows X on power-up); retention flops preserve selected state.
• A retention flop = normal flop + shadow element on an always-on retention supply; save copies the value in before power-down, restore copies it back after power-up.
• Save/restore sequencing is critical: save before corruption (else it saves X), restore after power is stable (else the copy-back fails).
• Retention is selective — retain only state that must survive (mode/config, resumable pointers); the rest is re-initialized on wake, because retention costs area + leakage (a 7.2-style judgement).
• Missing or mis-timed retention loses/corrupts state — a real bug power-aware GLS reveals; it's a functional check, not power integrity (10.1). Next: 10.5 — power switching, corruption & X-injection.

Quick Revision

Retention flop = normal flop + shadow (always-on retention supply): SAVE before power-down, RESTORE after power-up. Ordinary flops LOSE state (→ X on wake). Sequencing: save before corruption, restore after power stable (else save X / fail restore). Selective — retain only state that MUST survive (area/leakage, like 7.2); re-init the rest. Missing/mis-timed retention = lost/wrong state (real bug). Functional check. Next: 10.5 — power switching & corruption.