The Power-Up Sequence

Verification's own power-aware verification page already described the correct 4-step order from the checking side — enable power, wait for stability, release reset, only then disable isolation — and the one rule that matters most: never disable isolation early. This page shows the same sequence from the authoring side, with the real UPF commands and signals from every page in this section actually driving each labeled step.

The same four steps, now with real commands behind them

1. EN asserts — create_power_switch's -control_port, the domain receives power.
2. (gap) — supply confirmed stable, enforced by controller logic, not a UPF construct.
3. reset_n releases — the domain comes out of reset now that supply is stable.
4. vISO de-asserts — set_isolation_control's -isolation_signal, and only now do real signals pass.

Step 1 is create_power_switch's own -control_port — the same EN signal from that page's worked example. Step 4 is set_isolation_control's -isolation_signal — the same vISO. Step 2 is worth being precise about: UPF itself has no construct that directly encodes "wait for the supply to stabilize." That wait is enforced by whatever sequencing logic (a power controller state machine, or the testbench in a power-aware simulation) drives EN and reset_n — UPF describes the legal states and strategies, not the real-time control logic that sequences through them correctly. Getting that sequencing logic right is a design responsibility this topic's constructs support, not one they automate away.

Real power-management hardware gives step 2's gap an actual name: a power-good (PGOOD) signal, asserted by whatever regulates the supply once it has settled to a stable, safe level. Multi-rail systems commonly cascade one supply's PGOOD directly into the next supply's own enable pin, chaining the stabilization wait across an entire sequencing order without any digital logic having to "guess" how long to wait. PGOOD is deliberately not one of this topic's UPF constructs, for the same reason step 2 has no UPF construct at all — it's a property of the supply hardware itself, sitting one level below anything create_power_switch, set_isolation_control, or add_power_state describes.

PGOOD isn't a simple threshold comparator

A real PGOOD signal isn't just "voltage crossed X, assert now" — supply rails can wobble briefly on their way to settling, and a supervisor circuit that reacted to every momentary crossing would produce a PGOOD that chatters instead of cleanly transitioning once. Real power-supervisor ICs build in a glitch-rejection (debounce) period: the monitored voltage has to stay above (or below) its threshold continuously for a specified interval — commonly on the order of microseconds to tens of milliseconds — before PGOOD actually changes state. A brief dip that recovers before the debounce window elapses never registers at all.

This matters for step 2 of the sequence above precisely because it's the one step UPF has no construct for: the "wait for stability" logic that drives EN/reset_n correctly has to account for PGOOD's own debounce latency, not just treat PGOOD as instantaneous. In systems with more than one supply rail, dedicated power-sequencer ICs go a step further than a single per-rail supervisor — they coordinate relative ordering and timing between multiple rails' PGOOD/enable signals according to a configured sequence, the same cascading idea this page's step 2 discussion already introduces one level down, at the level of a single rail's own debounce behavior.

Where retention's save/restore actually fits

The four-step sequence above deliberately covers only isolation, the switch, and reset — but a domain with retained state has two more signals to place correctly. On power-up, restore belongs right after step 2 (supply confirmed stable) and before step 3 (reset_n releases): the retained value needs to be back in the domain's ordinary flops before the domain comes out of reset and starts operating on it. On power-down, save belongs before step 1 in reverse — before EN de-asserts and the switch actually cuts power — for the same reason Retention Strategies gives: a retention flop told to save after its source has already lost power has nothing left to capture. Slotted into the full sequence, power-up reads: isolation stays asserted -> switch enables -> supply stabilizes -> retention restores -> reset releases -> isolation de-asserts.

PGOOD isn't only for the initial ramp: brown-out detection

Everything above frames PGOOD as a one-time gate the sequence passes through once, on the way up from zero volts. Real supply hardware has to handle a second, related scenario: a supply that's already stable and running can still dip — a transient sag from a sudden current demand elsewhere on the board, say — without dropping all the way to zero. A power-on-reset and brown-out-detection (POR/BOR) circuit is the hardware that covers both cases with one mechanism: POR handles the initial power-up ramp (exactly PGOOD's job above), while BOR continuously monitors the already-running supply and re-asserts reset if it ever dips below a safe operating threshold, even briefly, mid-operation. The same debounce discipline from PGOOD applies here too — a BOR circuit that reset on every microsecond-scale glitch would be nearly as disruptive as the brown-out itself, so BOR trip points typically use their own delay/hysteresis window before declaring a real brown-out event. This is a distinct concern from the one-time power-up sequence this page otherwise describes: PGOOD/POR answers "has the supply ever become valid," while BOR keeps answering "is the supply still valid" for as long as the domain stays powered.

Where the clock fits, relative to everything else

The sequence above is silent about the domain's clock, but a real power-up/power-down sequence has to place it too, and the rule mirrors isolation's own asymmetry: on power-down, the clock is gated off before the switch actually cuts power — toggling logic into a domain that's about to lose power risks contention/crowbar current as the supply collapses mid-transition, the clock equivalent of isolation's own "don't leave things dangling while power changes" concern. On power-up, the clock only re-enables after reset releases and isolation de-asserts — the last step, not an early one, since there's no reason to clock a domain that's still in reset or whose outputs are still isolated. Like PGOOD/BOR, clock gating isn't itself a UPF construct this topic's commands describe — it's ordinary RTL/clock-tree logic — but the ordering constraint on it is real and belongs in the same mental sequence as the four UPF-driven steps.

Power-down is the same sequence, reversed — with one real asymmetry

Powering down runs the same four signals in the opposite order — but isolation asserts before power drops, not after, exactly mirroring the power-up rule from the other direction. If power dropped first, there would be a real window where the domain's outputs pass through undefined intermediate voltage on their way from valid logic levels to nothing at all — precisely the gap isolation exists to close. The ordering constraint isn't symmetric convenience; it's the same underlying hazard, approached from both directions.

What's next

Every construct so far has described one domain's own internal behavior. The next page covers what changes once a design has more than one power domain, defined by more than one team, at more than one level of hierarchy.