Power-Aware Verification
Every technique so far assumed the whole design is powered, all the time. A real chip with multiple power domains — parts of it deliberately switched off or run at reduced voltage to save power — introduces an entire dimension neither ordinary functional simulation nor CDC/RDC/GLS verify at all: whether the design behaves correctly while power itself is changing. This page covers what gets checked and how — not the UPF syntax used to author the power intent itself, which belongs to that not-yet-written topic.
The power-up sequence, and the one rule that matters most
VDDenabled — ramping to its stable level.- (gap) —
VDDconfirmed stable, reset still held. reset_nreleased.isolation_endisabled — only now do real signals pass.
The sequence has one correct order, and violating it is the single most-cited power-verification mistake: power enabled → wait for VDD stable → release reset → only then disable isolation. Disabling isolation any earlier lets the domain's outputs — still X/Z or otherwise undefined while power is unstable or reset hasn't run — glitch straight onto the still-powered logic reading them, exactly the corruption isolation cells exist to prevent.
Static checks: power intent structure, no simulation needed
Before any power-aware simulation runs at all, static analysis checks the UPF-described power architecture directly against the design's structure: does every net crossing a power domain boundary have exactly one correct isolation or level-shifter cell (not zero, not a duplicate); is a clock or reset net ever accidentally routed through a level shifter (it shouldn't be — clock and reset nets crossing a voltage boundary need different handling entirely); is every domain's power-up/power-down ordering internally consistent with the sequence above. These are structural questions with a yes/no answer, answerable from the power intent and netlist alone — the same static-vs-dynamic split CDC verification already introduced, applied here to power architecture instead of clock crossings.
A fourth structural question belongs on this same list: does a domain that's meant to retain its state across power-down actually have a retention strategy backed by a genuine always-on supply — not just a retention cell with nothing actually keeping it powered? A retention register is worthless if the rail supposedly keeping it alive during power-down isn't actually an always-on domain; static checking catches this exact mismatch (a common, real UPF authoring mistake) directly from the power intent, the same way it catches a missing isolation cell.
What the static checks are actually checking against: the power state table
The static checks above don't just infer legal power combinations on the fly — UPF authors a power state table (PST), an explicit list of every legal combination of power-domain states the chip is allowed to be in (e.g. "domain A on at full voltage while domain B is off," "both domains on at reduced voltage"). Static tools use the PST, not guesswork, to determine exactly where isolation and level-shifter cells are structurally required: a boundary between two domains only needs a level shifter, for instance, if the PST actually contains a legal state where the two sides run at genuinely different voltages. A domain-boundary combination the PST never allows doesn't need the same structural protection a legally reachable one does — which is why getting the PST itself right, before any static or dynamic check runs, is foundational to power-aware verification rather than a formality.
Dynamic checks: power-aware simulation
Static checks confirm the architecture is structurally sound; they can't confirm the sequencing logic itself — the actual control FSM that asserts isolation, waits for power, releases reset — behaves correctly across every real power-mode transition the chip supports. Power-aware (voltage-aware) simulation models the UPF-described power network directly in the simulator: domains genuinely go to X/Z when powered down, isolation clamps take effect, level shifters translate voltage domains — letting a real testbench exercise actual power-mode transitions (power up, power down, retention entry/exit) and catch a sequencing bug in the control logic itself, not just in the static architecture around it.
What's next
Power intent verification checks whether the design behaves correctly as power changes. The final page in this section covers a dimension that applies whether power ever changes or not: timing — and where a front-end team's responsibility for it actually ends.