UPF-vs-RTL isolation & level-shifter consistency

A low-power SoC carries two parallel descriptions: the RTL, which says how the logic is wired, and a UPF (IEEE-1801) power-intent spec, which says how the design is partitioned into power domains and how the boundaries between them are protected. Those two descriptions have to agree. When they do not — a crossing the UPF leaves unprotected, or an isolation clamp the UPF promises but the RTL cannot drive — you get a power bug that functional simulation does not model. This guide explains power-domain crossings, isolation and level shifting, and how a structural cross-check finds the gaps between intent and connectivity.

Power domains, isolation, and level shifters

A power domain is a region of the chip that shares a supply and can be switched on or off (or run at its own voltage) independently. A power-domain crossing is a net that leaves one domain and enters another. Two protections matter at a crossing. An isolation cell clamps the crossing to a known value while the source domain is powered down, so a floating, leaking output never reaches the live destination — it is driven by an isolation control signal. A level shifter translates signal levels when the two domains run at different voltages, so a low-voltage output is read correctly by a high-voltage input. The UPF declares which strategy covers which crossing; the foundation concepts are in low-power RTL & UPF basics.

Two complementary gaps

For every power-domain crossing, the consistency check asks two opposite questions:

• UPF gap — a net crossing out of a switchable domain with no isolation strategy covering it (when the source powers down, the unisolated output floats and leaks an unknown into the live domain), or a crossing between domains at different voltages with no level-shifter strategy. Labelled unprotected_crossing / missing_level_shifter.
• RTL gap — an isolation strategy declared in the UPF whose isolation control signal is absent from the RTL: no signal of that name exists, so nothing can actually assert the clamp the UPF promises. Labelled missing_isolation_control.

# UPF (IEEE-1801) power intent. The aon domain is always-on; the cpu domain
# is switchable. A net crossing from cpu (which can power down) into aon needs
# an isolation strategy, and its control must EXIST in the RTL.
create_power_domain PD_aon
create_power_domain PD_cpu -elements {u_cpu}

# Isolation strategy: clamp cpu->aon outputs to 0 while cpu is off.
set_isolation iso_cpu \
  -domain      PD_cpu \
  -isolation_power_net VDD_aon \
  -clamp_value 0 \
  -isolation_signal cpu_iso_en   # <-- this signal MUST exist in the RTL

# If 'cpu_iso_en' is absent from the design, the UPF promises a clamp that
# nothing can assert -> an RTL gap (missing_isolation_control).

Why simulation misses these

A standard functional simulation does not model power domains: every flop is always powered, every net always driven. A domain that powers down in silicon stays alive in the sim, so an unisolated crossing that would float in the lab carries a clean value in the simulation and the bug never appears. Power-aware simulation can model some of this, but it needs the UPF wired in correctly — and if the isolation control the UPF names does not exist in the RTL, the power-aware run itself is built on a contradiction. A structural cross-check of intent against connectivity catches the gap before either simulation can.

The honesty contract

This is the structural connectivity slice only. The labels are unprotected_crossing, missing_isolation_control, missing_level_shifter, and unchecked — never “UPF-compliant”, “low-power verified”, or “signoff”. It does not check the voltage or timing of any shifter. Retention (save/restore correctness) is explicitly out of scope. With no UPF the check is not_run, never reported as clean. A degraded RTL parse never reads as a confident clean. Crossing inference traces only named port connections between parsed modules; positional or wildcard connections, black-box instances, and any unresolved domain mapping are surfaced as unchecked — the check defaults to flagging on ambiguity, never to a silent pass.

How ChipVerify AI helps

ChipVerify AI (a pre-signoff RTL evidence tool, currently in closed beta, not a foundry signoff tool) cross-checks an uploaded UPF against the RTL it constrains and names every unprotected crossing, missing level shifter, and isolation control the UPF promises but the RTL lacks — structural power-intent evidence to review, surfaced before a power-aware simulation or signoff flow would catch it.

Related reading

• Low-power RTL & UPF basics — power domains, isolation, level shifters, and retention.
• Macro & wrapper contract checking — the other intent-vs-connectivity cross-check, for PG pins.
• Reset & X-convergence — the unknown an unisolated crossing leaks is the same X.
• Tapeout readiness — low-power intent closure as a signoff line item.

Try the public scanner at /tinytapeout or request access.

FAQ