How LPV Differs from Functional Verification: Theory Deep Dive

Foundational theory

How LPV Differs from Functional Verification is core to Low Power Verification Foundations. Treat each power behavior change as a correctness and signoff risk decision.

Core concepts explained

• Functional verification asks whether logic behavior matches the architectural spec under valid operating assumptions, while LPV asks whether logic remains safe and correct as operating assumptions themselves change with power state. LPV introduces failure modes that functional-only regressions often miss: unknown propagation after shutoff, incorrect isolation sequencing, lost state without retention, protocol violations across partially powered systems, and invalid resets around domain wake-up. Effective teams integrate LPV scenarios into existing testbenches but add power-state-aware stimulus, checkers, and coverage models that explicitly measure state transitions, low-power handshakes, and recovery correctness.

• Primary metric: illegal transition count, corruption incidence, and reproducibility of low-power regressions across fixed seeds

• Primary artifact: LPV evidence packet: transition timeline, assertion outcomes, and before-after replay summary

• Owners: LPV owner, PMU or firmware owner, verification signoff owner

• Power intent and RTL behavior must stay aligned through transitions

• Proof quality beats broad waive strategies in low-power closure

Why this matters in low-power signoff

LPV foundations succeed when teams treat power intent as executable spec, not static documentation. Teams that enforce this reduce false alarms and real escapes.

Mental model

POWER DOMAIN DIAGRAM

            +--------------------------- CHIP TOP ---------------------------+
            |                                                               |
VDD_AON --->|  [AON DOMAIN]  PMU / RTC / wake logic                         |
            |       |                                                       |
            |       +---- isolation controls ----+                          |
VDD_CORE -->|  [CORE DOMAIN] CPU / interconnect  |--> retention handshake   |
            |                                     |                          |
VDD_GPU  -->|  [GPU DOMAIN]  shader + cache -----+                          |
            |                                                               |
            +---------------------------------------------------------------+

Key checks:
- legal on/off sequencing between domains
- control ownership of iso/retention signals
- no illegal crossings when a sink domain is OFF

Worked intuition

1. Classify symptom first: illegal transition, corruption, isolation break, retention drift, or X-prop ambiguity.

2. Pinpoint first phase boundary where expected low-power behavior diverges.

3. Quantify movement in illegal transition count, corruption incidence, and reproducibility of low-power regressions across fixed seeds before broad refactors.

4. Collect LPV evidence packet: transition timeline, assertion outcomes, and before-after replay summary with fixed run metadata and mode sequencing.

5. Apply one bounded fix and replay both targeted and broader scenarios.

6. Publish owner-signed closure note with rollback trigger.

Common misconceptions

• Passing nominal ON/OFF smoke proves transition correctness.

• UPF compile clean means all intent semantics are correct.

• All X-prop failures indicate real product escapes.

• Retention behavior can be trusted without multi-cycle restore stress.

Low-power verification deep dive

LPV foundations are strongest when power intent, simulation semantics, and ownership boundaries are explicit from day one.

Concept diagram

LPV FOUNDATION LOOP

intent definition -> setup and modeling -> scenario execution -> evidence-based closure
       ^                                                              |
       +------------------------ owner feedback ----------------------+

Metric graph

FOUNDATION HEALTH

setup escapes             █████
intent mismatch defects   ██████
stable regressions        █████████

Metrics and artifacts to collect

• intent-to-RTL alignment checklist

• power-mode onboarding packet

• ownership map for controls and checks

• first-failure boundary report

Mini case study

A project reduced LPV bring-up churn after requiring explicit domain-control ownership and transition evidence in every review.

Debug branches

• Prove setup correctness before chasing downstream symptoms.

• Record domain ownership for each control and checker.

• Distinguish intent mismatch from RTL implementation bugs.

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.

Theory reinforcement

Theory matters when it predicts concrete failure signatures and closure boundaries.

Translate LPV semantics into reproducible verification outcomes.