Low Power Verification · All levels

Debugging Retention Corruption: Debug Playbook

Debug Playbook for Debugging Retention Corruption.

Debug playbook

Debug Playbook for Debugging Retention Corruption is anchored on Time-to-first-divergence localization and percentage of corruption bugs resolved with deterministic reproduction.. Convert observations into mechanism-backed and owner-bound actions.

Freeze seed, metadata, and boundary under investigation.
Locate first persistent low-power phase divergence.
Classify mechanism: setup, transition, boundary, retention, or X-prop class.
Apply one focused reproducer and one bounded fix.
Re-run determinism and broader regression matrix.

Review memo template

diagram

LPV REVIEW MEMO - Retention & Restore / Debugging Retention Corruption

1. Symptom
   - Failing metric: Time-to-first-divergence localization and percentage of corruption bugs resolved with deterministic reproduction.
   - Trigger context: <seed/mode/sequence>
   - First failing phase: <entry/off/exit/boundary>

2. Mechanism hypothesis
   - Candidate mechanism: Retention corruption debug requires isolating whether failure originates in retention capture, storage, restore delivery, or post-restore overwrite. Engineers should reconstruct a timeline from pre-save architectural state to first mismatched register after wake, then align this with power intent events, clock/reset activity, and isolation boundaries. Useful techniques include shadow-register snapshots, signature-based compare windows, and fault-injection campaigns that perturb retention controls, ramp times, and acknowledge timing one dimension at a time. Debug quality improves when traces include both logical values and physical context such as rail monitors, retention enable distribution, and X-propagation hotspots because corruption can be functional or analog-induced. Closure should require replayable repro tests plus guard assertions that prevent recurrence through future power controller or firmware changes.
   - Competing hypotheses: setup, transition race, boundary bug, retention drift, X-prop noise
   - Missing evidence: <trace/assertion/report>

3. Proposed action
   - Smallest reversible change: <intent/RTL/checker/flow>
   - Expected movement: <failure trend/replay stability>
   - Regression risk: compatibility, coverage, signoff delay

4. Signoff
   - Required artifact: Corruption triage packet with first-divergence trace, root-cause taxonomy, and regression guardrail checklist.
   - Required owners: low-power debug owner, silicon validation owner, power architecture owner, firmware owner
   - Final decision: ship, bounded rollout, rollback, or escalate

Low-power verification deep dive

Retention closure requires proving end-to-end state lifecycle through save, off, and restore windows.

Concept diagram

diagram

RETENTION LIFECYCLE

save request -> state capture -> power off -> power on -> restore -> traffic resume

Metric graph

diagram

RETENTION STABILITY

restore mismatch       █████
save timing defects    ████
stable wake cycles     ███████

Metrics and artifacts to collect

retention save/restore timing report
pre/post state diff matrix
multi-cycle retention stress summary
state-loss bug trend by mode

Mini case study

A corruption issue persisted until retention checks compared multi-cycle state snapshots rather than single wake events.

Debug branches

Track save acknowledgement against actual state capture.
Validate restore completion before functional traffic resumes.
Run repeated sleep/wake cycles to expose drift.

Senior review question

Ask: what exact low-power transition boundary failed first, and which artifact proves the closure claim reproducibly?

Key takeaways

Tie each LPV claim to a concrete transition boundary and one proving artifact.
Prefer minimal reversible fixes with explicit owner and rollback criteria.

Common pitfalls

Treating power-aware failures as random before boundary classification.
Waiving X-prop failures before proving impact and root cause.
Declaring closure without deterministic replay across key modes.

Debug ladder

Sequence: reproduce -> classify -> isolate boundary -> prove mechanism -> bounded fix.

Avoid mixed fixes before first-principles classification.

Practice this lesson