Low Power Verification · All levels
Low Power Verification Foundations: Tricky Q&A
Senior interview and review questions for Low Power Verification Foundations.
Section Q&A bank
Use these drills after completing all topics in Low Power Verification Foundations. Answer with context, mechanism proof, artifact, owner, and release decision.
Why is passing functional regression in full-power mode not strong evidence for low-power readiness?
[INT][LPV][LPV-FOUNDATIONS]
Q: Why is passing functional regression in full-power mode not strong evidence for low-power readiness?
A:
Because full-power regressions do not exercise the power-state transitions where LPV bugs live. Many LPV failures arise only when domains shut off, wake up, or interact in mixed-power states, such as X leakage from an unisolated boundary, lost context from broken retention restore, or sequencing races between reset and power-good controls.
FOLLOW-UP TRAP: Assuming low-power correctness is implied once logic behavior is correct in always-on conditions.What is the most common verification mistake when reviewing UPF isolation definitions?
[INT][LPV][LPV-FOUNDATIONS]
Q: What is the most common verification mistake when reviewing UPF isolation definitions?
A:
Checking only whether isolation cells exist, instead of proving temporal correctness of control and clamp behavior during transitions. Cells may be present but still fail system behavior if isolation enable timing is late, clamp values are wrong for downstream protocols, or de-isolation occurs before the source domain is valid.
FOLLOW-UP TRAP: Treating structural insertion reports as sufficient proof of isolation correctness.How does LPV coverage differ from conventional functional coverage closure?
[INT][LPV][LPV-FOUNDATIONS]
Q: How does LPV coverage differ from conventional functional coverage closure?
A:
LPV coverage must target power-state transitions and cross-power interactions, not just transaction features. Useful LPV closure tracks entry/exit of each legal state, sequencing combinations, isolation/retention events, and post-wake recovery behavior under traffic so gaps expose real low-power risk rather than missing feature bins.
FOLLOW-UP TRAP: Using only feature-level functional bins and ignoring power transition scenarios.When static low-power checks are clean, why do teams still run extensive power-aware simulation?
[INT][LPV][LPV-FOUNDATIONS]
Q: When static low-power checks are clean, why do teams still run extensive power-aware simulation?
A:
Static checks prove structural and rule-based consistency, but they cannot fully validate dynamic timing relationships between controls, resets, clocks, and protocol activity. Power-aware simulation validates behavior under realistic event ordering, catching race conditions and transient corruption that structural checks alone cannot expose.
FOLLOW-UP TRAP: Believing static LP checks remove the need for dynamic low-power verification.Q&A drill guide
SYMPTOM -> LPV FAILURE CLASS -> EVIDENCE -> OWNER ACTION -> VALIDATIONSketch while answering
LPV FOUNDATION LOOP
intent definition -> setup and modeling -> scenario execution -> evidence-based closure
^ |
+------------------------ owner feedback ----------------------+Common traps
Prove setup correctness before chasing downstream symptoms.
Record domain ownership for each control and checker.
Distinguish intent mismatch from RTL implementation bugs.
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.