Isolation Strategies

A domain that's powered down doesn't just stop computing — its outputs go undefined, and anything still-powered downstream of it now has an undefined input. Isolation is the strategy that keeps that undefined-ness from propagating anywhere it matters. This is the authoring side of exactly the static check Verification already covered, and the exact scenario Gate-Level Simulation & X-Propagation described: an unisolated powered-down domain's X/Z outputs are precisely what isolation exists to clamp away before they reach anything else.

Two commands, not one

set_isolation V_PD_isolation \
  -domain V_PD \
  -applies_to outputs \
  -clamp_value 0

set_isolation_control V_PD_isolation \
  -domain V_PD \
  -isolation_signal vISO \
  -isolation_sense high \
  -location parent

set_isolation declares what the strategy does: -applies_to <inputs|outputs|both> picks which side of the domain boundary gets isolated, and -clamp_value <0|1|Z|latch|value> picks what the isolated signal reads as while active — 0 and 1 clamp to a fixed logic level, latch freezes at whatever value was last valid, Z for a genuinely undriven state. set_isolation_control declares how it's switched on: -isolation_signal names the real control signal, -isolation_sense <high|low> says which level of it activates isolation. Tutorials that show only one of these two commands are showing half the picture — a strategy with no control signal has nothing to actually assert it.

The clamp value isn't picked arbitrarily — it has to match how the downstream logic interprets the signal. An active-high enable should clamp to 0 (its disabled value); an active-low signal — a reset, say — should clamp to 1 (its inactive value), never to 0, which downstream logic would read as an asserted reset. Getting this backwards doesn't just silence a signal, it actively asserts the wrong thing into still-powered logic.

-location: a real, consequential choice

Signal passing through V_PD's boundary to always-on logic:

-location self places the isolation cell physically inside the domain being isolated, drawing its own power from that same domain's supply. -location parent places it outside, in the always-on domain, drawing power from there instead. This isn't cosmetic — an isolation cell placed self needs its own power to keep functioning even while the domain around it shuts down, which is a real constraint on how that cell itself gets powered; parent sidesteps that entirely by placing the cell somewhere power never drops in the first place.

Isolation clamping, concretely

The moment vISO asserts, the domain's real output goes undefined (hatched — the domain is losing power) — but the isolated output clamps to a clean 0, not X. The moment vISO de-asserts, the isolation cell goes transparent again and the isolated output resumes tracking the real signal.

While vISO is asserted, the isolated output holds at the declared clamp value regardless of what the domain's real, unpowered output is actually doing underneath — including while that real output is genuinely undefined. The moment vISO de-asserts, the isolation cell goes transparent and the real signal passes through again.

-diff_supply_only: skipping isolation where it wouldn't do anything

set_isolation's -applies_to names a broad category (inputs, outputs, or both) — but not every signal matching that category actually crosses a power boundary that matters. A -diff_supply_only argument narrows the strategy: when set, isolation is only actually inserted on ports where the source and sink genuinely sit on different supplies. A port whose driver and receiver both happen to be powered from the same supply set gets no isolation cell at all under this strategy, even if it otherwise matches -applies_to's selection, since there's no real power-domain boundary there for isolation to protect against. Without -diff_supply_only, a broadly-scoped strategy can end up inserting isolation cells on ports that never actually need one — real, unnecessary area and a gate the design didn't need — purely because the strategy's port selection was written more broadly than the domain structure actually requires.

-source/-sink narrow the strategy further still: rather than -diff_supply_only's blanket "any two different supplies," they name the specific supply set(s) a crossing must originate from (-source) or terminate at (-sink) to receive this particular isolation strategy — useful when a domain has several boundaries to different neighbors and each needs its own clamp value or control signal, not one strategy applied uniformly everywhere the domain touches another supply.

map_isolation_cell: binding the abstract strategy to a real cell

Just like level shifters (see Level Shifter Strategies) and power switches (see Power Switches), set_isolation only declares intent — it doesn't by itself choose a physical gate. That binding is map_isolation_cell:

map_isolation_cell V_PD_isolation \
  -domain V_PD \
  -lib_cells {ISOL_AND_0}

-lib_cells supplies the candidate library cell(s) synthesis may instantiate for this strategy — commonly an ISO_AND cell for a clamp-to-0 strategy, or an ISO_OR cell for a clamp-to-1 strategy, since an AND gate's output is forced low whenever either input is low, and an OR gate's output is forced high whenever either input is high — the clamp value chosen in set_isolation isn't just a UPF-level declaration, it directly determines which family of physical gate actually implements it. Without map_isolation_cell, a set_isolation/set_isolation_control pair describes a requirement synthesis has no way to actually realize in real gates.

What's next

Isolation handles signals whose value becomes meaningless when power drops. The next page covers a different boundary problem entirely — signals that stay meaningful throughout, but need translating because the two sides of the boundary run at different voltages.