Functional Coverage Does Not Prove Your Power Intent
A low-power SoC can achieve high functional coverage without powering down a single domain.
Traditional coverage answers whether the RTL logic was exercised. It does not automatically verify the behaviour introduced by the UPF power intent.
A low-power verification plan must answer additional questions:
- Did every power domain enter its required states?
- Were isolation controls applied and released?
- Was retained state saved and restored?
- Were legal power transitions exercised?
- Were illegal transitions detected?
- Did the domain recover correctly after wake-up?
- Were unsafe DVFS sequences prevented?
These are separate verification goals and should not be hidden inside an overall functional-coverage percentage.
Intent defines the target
Power-aware coverage requires two inputs:
UPF-derived inventory → What should be covered
Runtime event stream → What actually happened
The UPF-derived inventory provides the denominator. It identifies the power domains, states, transitions, isolation strategies, retention groups and other power-related points expected from the design.
The simulator’s runtime events provide the hits.
Each power parameter remains an independent coverage collector with its own result.
A point is covered only when the corresponding power behaviour is observed during execution.
Power states and transitions are different questions
Entering every power state does not prove that every required transition between those states occurred.
The coverage model therefore keeps state and transition coverage separate.
State coverage → Was OFF, ON or RETENTION entered?
Transition coverage → Was OFF → ON or ON → RETENTION exercised?
Legal edges are covered when taken. Illegal edges require negative-control semantics.
An illegal transition should not be counted like a normal coverage hit. It should count only when the test attempts it and the design correctly detects or blocks it.
If the illegal transition occurs without detection, the result is a defect—not additional coverage.
Detecting the false green
A test may be named “power-down scenario” while never driving the design into a power-down state.
If the functional test passes, a conventional dashboard may still appear green.
Power-aware scenario correlation compares the requested scenario with the power activity actually observed.
The requested scenario is checked against the states and transitions that really occurred.
If no domain turned off, no retention sequence ran and no recovery occurred, the test did not validate low-power behaviour—regardless of its name.
Keep power closure separate
Power-aware coverage should have its own gate and verdict:
PASS_POWER_AWARE_FUNCTIONAL
POWER_COVERAGE_INCOMPLETE
POWER_COVERAGE_DEFECT
It should not be averaged into code or functional coverage. Otherwise, frequently exercised logic may hide incomplete power sequencing.
The takeaway
Functional coverage asks:
Did the logic execute?
Power-aware coverage asks:
Did the design enter, survive and recover from its power states exactly as the intent required?
A low-power signoff needs both answers.
👉 Explore the complete UPF-driven power-aware coverage model on WIOWIZ
#verification #semiconductor #vlsi #lowpower
Top comments (0)