The interviewer asks where RTL stops and UPF begins, or who owns isolation and retention. Distinguish structural power intent in UPF from executable sequencing in the always-on RTL controller.
UPF externalizes power intent: domains, switches, isolation, retention, and state tables. RTL stays clean while UPF captures the implementation policy.
RTL owns behaviour and exposes control: enables, idle signals, quiesce handshakes, and save and restore triggers. UPF owns the power structure built from those signals.
Read solid lines as RTL you write and dashed accent lines as structure UPF creates. Every dashed box is driven by a solid wire.
The controller and its four control wires are ordinary RTL, simulated like any other logic.
The switch, retention and isolation cell do not appear in RTL at all. UPF places them and connects them to those wires.
The isolation cell sits on the core output, on its way into the always-on side.
Concern | RTL provides | UPF defines |
|---|---|---|
Clock gating | Intent-driven enables and test control | Clock-gating mapping is normally a synthesis/clock-flow concern; use target resources |
Power domains | Hierarchy the domains follow | Domain membership and supply nets |
Isolation | Boundary signals and idle values | Isolation strategy, clamp values, control signals |
Retention | Save and restore triggers | Which flops retain, with which supplies |
Sequencing | Executable AON controller, quiesce, save/restore and readiness handshakes | Allowed power states/transitions and their structural power intent |
The domain names, the isolation signals and the clamp values are the contract between the two sides. A few lines of UPF show the shape: each command names an RTL signal, never an RTL cell.
# UPF sketch (illustrative): supplies and the switch omitted; exact options vary by UPF version and tool
create_power_domain PD_CORE -elements {u_core}
set_isolation iso_core -domain PD_CORE -applies_to outputs \
-clamp_value 0 -isolation_signal u_aon/iso_en -isolation_sense high
set_retention ret_core -domain PD_CORE -elements {u_core/ctx_q} \
-save_signal {u_aon/save high} -restore_signal {u_aon/restore high}Read it against the picture: PD_CORE is the dashed domain, iso_en drives the isolation cell, and save and restore drive retention. The RTL only has to provide those signals, plus sw_req for the switch the sketch leaves out.
What breaks if RTL hard-codes an isolation mux? Simulation passes while the real flow inserts its own cell. The two can disagree on clamp value or placement, and power-aware static checks report the RTL mux as unrecognised isolation, or report the crossing as missing isolation.
What does the always-on controller own? The sequencing: quiesce requests, isolation enables, switch controls, and save and restore triggers. It is the only logic alive to run the order.
How is the split verified? Structural checks resolve domain membership, crossing strategies, live supplies and mapped cells. Temporal assertions check executable sequencing and fresh acknowledgements. Ordinary RTL simulation checks controller/mux logic but does not model supply corruption; power-aware simulation exercises supply loss, isolation and retention under UPF. State/transition coverage records visits, not correctness: a covered transition may still violate an assertion, while an unvisited state is a stimulus gap rather than proof of a missing cell. See the AON controller.
Putting power switches in RTL. Switches are physical cells chosen by the flow. RTL naming a switch is overreach that the tools ignore.
Writing UPF pragmas as comments and stopping. Comments carry no intent. The contract needs real control signals on one side and real power constructs on the other.
Treating UPF as a backend-only detail. The RTL side must still provide clean boundaries and handshake behaviour, or the intent has nothing to attach to.
The intent lives in the wrong place. RTL should expose the boundary signal and handshake while UPF defines the isolation cells and clamp values, so the tools and equivalence checks see one contract.