Low Power Verification · All levels
Power State Verification: Tricky Q&A
Senior interview and review questions for Power State Verification.
Section Q&A bank
Use these drills after completing all topics in Power State Verification. Answer with context, mechanism proof, artifact, owner, and release decision.
Why can a PST transition be logically legal yet still unsafe in silicon behavior?
diagram
[INT][LPV][POWER-STATE-VERIFICATION]
Q: Why can a PST transition be logically legal yet still unsafe in silicon behavior?
A:
Arc legality only encodes allowed endpoints; safety additionally depends on temporal guards such as quiesce completion, retention save acknowledgment, and isolation timing. If a controller reaches the legal destination while bypassing one of these guard conditions, data corruption or protocol breakage can occur despite matching a listed PST arc.
FOLLOW-UP TRAP: Equating legal source/destination states with complete transition correctness.What is the common verification mistake when checking illegal PST transitions under concurrent requests?
diagram
[INT][LPV][POWER-STATE-VERIFICATION]
Q: What is the common verification mistake when checking illegal PST transitions under concurrent requests?
A:
Teams often check only explicit direct jumps and miss compressed multi-step paths created by overlapping firmware commands or asynchronous wake events. Those overlaps can effectively realize forbidden arcs unless the checker tracks in-flight intent, guard satisfaction, and arbitration outcomes over time.
FOLLOW-UP TRAP: Assuming illegal transitions can only happen as single-step FSM jumps.How should power-mode handshake verification handle partial progress and timeout recovery?
diagram
[INT][LPV][POWER-STATE-VERIFICATION]
Q: How should power-mode handshake verification handle partial progress and timeout recovery?
A:
Verification should treat sequencing as a transaction with rollback or controlled-forward-recovery rules, then prove either path preserves isolation, reset containment, and retention coherence. Merely timing out and forcing a target state is insufficient if intermediate side effects (like partial restore) are not explicitly unwound or reconciled.
FOLLOW-UP TRAP: Validating only successful nominal handshakes without checking rollback semantics.Why is aggregate low-power coverage percentage a weak signoff indicator for multi-domain systems?
diagram
[INT][LPV][POWER-STATE-VERIFICATION]
Q: Why is aggregate low-power coverage percentage a weak signoff indicator for multi-domain systems?
A:
Aggregate coverage can look high while critical inter-domain combinations remain untested, especially rare but high-risk pairings like shared-memory producer collapse during consumer wake. Credible signoff requires risk-weighted cross-domain bins and evidence that correctness objectives are met for those specific interactions.
FOLLOW-UP TRAP: Approving signoff from total percentage without risk-ranked cross-domain closure.Q&A drill guide
diagram
SYMPTOM -> LPV FAILURE CLASS -> EVIDENCE -> OWNER ACTION -> VALIDATIONSketch while answering
diagram
PST CONTROL LOOP
state request -> legality check -> handshake sequencing -> mode entry -> monitored exitCommon traps
Validate legal state graph first.
Stress concurrent control events and asynchronous wakeups.
Bind fixes to explicit transition and owner contracts.
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.