Power Switches

Every strategy in this section has quietly assumed something: that a domain's supply can actually be cut and restored. The power switch is that assumption made real — the element that connects an always-on input supply to a domain's switched output supply, gated by real control logic.

create_power_switch

create_power_switch sw_controller \
  -domain PD_CONTROLLER \
  -input_supply_port  {VDDT VDDL_o} \
  -output_supply_port {VDDc VDDL_2} \
  -control_port {EN PSE} \
  -on_state  {on_state VDDT EN} \
  -off_state {off_state {!EN}}

• -input_supply_port — the always-on supply feeding the switch, named as {port net}. Repeatable: a real switch can draw from more than one input supply (useful for domains that need to select between two different upstream sources).
• -output_supply_port — the switched supply the domain itself actually connects to. What the domain sees is entirely this port; it never references the input supply directly.
• -control_port — the signal(s) that actually gate the switch. Also repeatable — EN and PSE above are two independent control inputs, both able to influence whether the switch conducts.
• -on_state/-off_state — the actual boolean condition on the control ports that puts the switch in each state. on_state VDDT EN says: when EN is asserted, the output is driven from the VDDT input. off_state {!EN} says: when EN is de-asserted, the output isn't driven from anything — the domain loses power.

Header vs. footer, and why real switches turn on staggered

Physically, create_power_switch is an abstract model of one of two switch styles: a header switch sits between the always-on supply and VDD, gating power on the high side (typically PMOS); a footer switch sits between the domain and ground, gating on the low side (typically NMOS). Neither choice is visible in the UPF above — that's a physical-design decision layered underneath this same abstract switch description.

A single switch turning on abruptly across a whole domain would pull a huge, instantaneous inrush current as every capacitance in the domain charges at once — enough to droop the shared supply rail for neighboring, still-running logic. Real designs avoid this by daisy-chaining many small switch cells, each enabling the next in sequence rather than all at once, so the domain's capacitance charges gradually instead of in one spike. This is exactly why the timing relationship the next page (the power-up sequence) covers isn't just about this switch versus other strategies' control signals — it's also about how this switch's own network powers up internally.

Coarse-grain vs. fine-grain: how many switches, controlling how much

The daisy-chained network above is really an implementation of one of two granularities a design commits to. Coarse-grain power gating uses relatively few, large switch cells to power an entire block or domain as one unit — simple to control, but everything behind those switches goes on or off together. Fine-grain power gating instead distributes many smaller switch cells throughout the domain (often one per standard cell row, or even per cell), letting sub-portions of the same domain be independently power-gated. Fine-grain costs more control complexity and switch-cell area overhead, but gives finer power-saving granularity than a domain built from a handful of coarse switches ever could. Real technology libraries mark which is which — a switch cell's Liberty attribute names it coarse_grain or fine_grain — and map_power_switch's -lib_cells choice is what actually commits a design to one granularity or the other for a given strategy.

Sizing the switch: on-resistance and IR drop

Once a real library cell backs the switch (below), its on-resistance — how much the conducting switch itself resists current flow while "on" — becomes a real physical constraint, not just an abstract on/off condition. Every switch cell has some non-zero on-resistance, and the current the whole domain draws has to pass through it; that resistance, combined with the domain's actual switching current, produces an IR drop (V_drop = I × R) between the always-on input supply and what the domain actually receives at its output supply port. Too much IR drop and the domain effectively runs at a lower voltage than intended, risking timing failures or functional errors even though nothing in the UPF description looks wrong. This is exactly why a single switch instance is never enough for anything but the smallest domain: real designs parallel many identical switch cells — the same daisy-chained network already described above — both to spread the domain's total switching current across enough parallel low-resistance paths to keep IR drop acceptable, and to stagger the inrush current each cell contributes as it turns on.

map_power_switch: connecting the abstract switch to a real library cell

create_power_switch only ever describes an abstract switch — ports, control signals, on/off conditions — with no statement yet about which actual physical cell in the technology library implements it. map_power_switch is the command that closes that gap, the same successive-refinement idea Hierarchical UPF names explicitly: abstract intent first, physical detail filled in later, once it's actually known.

map_power_switch sw_controller \
  -domain PD_CONTROLLER \
  -lib_cells {HEADER_SWITCH_X4} \
  -port_map {{vin VDDT} {vout VDDL_2} {sleep_in EN}}

-lib_cells names the real library cell (or a candidate list, letting the tool pick among them); -port_map connects that cell's own physical pin names (vin/vout/sleep_in here) to the abstract switch's already-declared ports and nets. The library cell itself has to be marked as a genuine power-switch cell for the mapping to be legal — either because the liberty file already carries that attribute, or via a dedicated UPF library command that adds it. Without map_power_switch, create_power_switch's abstract description has nothing physical backing it at all; this is the step that turns the intent into an actual implementable switch.

Multiple control ports: real, not just a syntax curiosity

A real power switch is very often gated by more than one condition ANDed together — a software-visible enable bit and a hardware-level power-sequencing signal both have to agree before a domain actually powers up. -control_port being repeatable, and -on_state referencing more than one of them together, is exactly what lets a switch's declared behavior match that real, multi-condition gating instead of a single oversimplified enable.

What every earlier strategy was actually built around

Tracing back through this section with the switch now in view: isolation exists because this switch's off_state really does remove power, leaving real outputs undefined; retention exists because this switch cutting the domain's primary supply doesn't have to cut its retention supply too — the two are independent supply sets, and only one of them answers to this switch's -output_supply_port; the power-up sequence still ahead in the next section is fundamentally about the timing relationship between this switch's own control port and every other strategy's control signal.

What's next

Every individual construct in this topic now exists — domains, supplies, power states, and all four control strategies. The next section assembles them into an actual power-up sequence, covers composing UPF across a design hierarchy, and closes with a capstone writing real power intent for the PWM register block.