Low Power Verification · All levels
Retention & Restore: Tricky Q&A
Senior interview and review questions for Retention & Restore.
Section Q&A bank
Use these drills after completing all topics in Retention & Restore. Answer with context, mechanism proof, artifact, owner, and release decision.
Why is matching the UPF retention list to RTL register intent not sufficient for signoff?
[INT][LPV][RETENTION-AND-RESTORE]
Q: Why is matching the UPF retention list to RTL register intent not sufficient for signoff?
A:
List alignment proves intent mapping, but it does not prove behavior under real transitions. Signoff also needs dynamic evidence that save/restore timing, rail stability, isolation control, and reset interactions preserve values under stress and corner conditions.
FOLLOW-UP TRAP: Assuming static retention declaration equivalence guarantees dynamic value preservation.What is a common sequencing mistake when verifying restore flow in complex SoCs?
[INT][LPV][RETENTION-AND-RESTORE]
Q: What is a common sequencing mistake when verifying restore flow in complex SoCs?
A:
A frequent mistake is allowing dependent logic to resume before retained values are guaranteed visible and stable. Even if restore toggles correctly, early functional activity can overwrite or consume stale state and create intermittent wake-up failures.
FOLLOW-UP TRAP: Checking only restore signal toggles without validating dependency and readiness ordering.How do you separate true retention-cell corruption from post-restore functional overwrite?
[INT][LPV][RETENTION-AND-RESTORE]
Q: How do you separate true retention-cell corruption from post-restore functional overwrite?
A:
Capture compare points at three stages: pre-save snapshot, immediate post-restore before functional enable, and post-enable steady state. If mismatch appears before functional enable, suspect capture/storage/restore; if it appears after enable, suspect downstream logic or sequencing overwrite.
FOLLOW-UP TRAP: Blaming retention cells immediately without staged divergence checkpoints.Why can unintended state loss pass block-level tests but fail in full-chip power regression?
[INT][LPV][RETENTION-AND-RESTORE]
Q: Why can unintended state loss pass block-level tests but fail in full-chip power regression?
A:
Block tests often miss cross-domain dependencies, firmware timing variability, and nested power mode interactions. Full-chip regressions expose coupled sequences where one domain's wake or reset policy invalidates another domain's retained assumptions.
FOLLOW-UP TRAP: Treating clean block-level retention tests as sufficient system-level proof.Q&A drill guide
SYMPTOM -> LPV FAILURE CLASS -> EVIDENCE -> OWNER ACTION -> VALIDATIONSketch while answering
RETENTION LIFECYCLE
save request -> state capture -> power off -> power on -> restore -> traffic resumeCommon traps
Track save acknowledgement against actual state capture.
Validate restore completion before functional traffic resumes.
Run repeated sleep/wake cycles to expose drift.
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.