The question

The interviewer powers off a block and asks what happens to the signals it drives into always-on logic. It is testing isolation, sequencing, and the restore order.

Complex SoCs split logic into power domains so always-on logic survives while optional domains power down. Every signal leaving a switchable domain needs a defined value while that domain is off.

Model answer

Clamp outputs of the off domain before they reach live logic. Clamp to the safe idle value, usually 0, so no floating net or unknown propagates into the controller.

Sequence matters on both ends. Quiesce and account for accepted work before shutdown. In the canonical always-on controller, external context capture happens before isolating its capture path, then power-off is permitted. Internal retention may have a different save/isolation order. Both must finish save before supply collapse. On wake keep isolation asserted through qualified power-good, restore completion, safe reset release and clock/domain readiness; release isolation before traffic resumes.

Retention covers state that must survive collapse, such as context pointers and protocol epochs. Mark retained and reconstructable state early in the architecture.

Follow the arrows from ON. The iso value in each state is the isolation enable while the controller sits there.

• Isolation goes to 1 before power goes off and stays 1 through four states on the way back.

• The only exit to ON is from WAIT_READY, and it needs all three statuses, not power_good alone.

• The table below adds the delayed-acknowledgement rows: WAIT_READY can sit with restore_done = 1 and domain_ready = 0.

Temporal checker contract: from OFF until the qualified WAIT_READY-to-ON edge, require isolation=1 and traffic admission=0. In WAIT_READY require power_good && restore_done && domain_ready before transition to ON; count one restore pulse per wake. A bounded watchdog may report a stuck status, but must keep isolation asserted. These are digital sequencing obligations; the linked controller assumes stable power-good and fresh held acknowledgements, not arbitrary brownouts.

Follow-ups

• Clamp to 0, 1, or hold last value? Clamp to the value the receiver treats as idle, usually 0. Holding the last value needs a state element in the live domain and a reason for it.

• Who generates the isolation enable? The always-on controller, sequenced with the power switch. RTL provides the boundary intent and the handshake; the tools insert the cells.

• What breaks without isolation? Unknowns fan into live control logic and corrupt state machines. The failure shows up far from its cause, often as a dangling transaction.

Common wrong answers

• A plain RTL mux as the isolation. A mux sits in whatever power domain its hierarchy belongs to, so inside the switchable domain it powers off with the source. Tools do not recognise it as an isolation strategy, so power-aware checks report missing isolation and UPF may add a second clamp. Ordinary cells are also not characterised for a floating input.

• Assuming ON-to-OFF is electrically safe. Review both directions against library power-off tolerance and supplies. Level conversion alone does not prove protection or prevent back-powering;

• Switching off a live interface. Powering down mid-transaction strands the protocol. Quiesce first, then switch.

Testbench

A logical clamp model and tests for pass-through and both clamp values with unknown inputs. iso_clamp is a simulation stand-in for the UPF-inserted cell; in a real flow the clamp comes from set_isolation, not from RTL. Use the linked controller bench for delayed restore and readiness sequencing, and power-aware and physical checks for implementation.

1
2
3
4
5
6
7
8
9
10
11
12

`timescale 1ns/1ps
module iso_clamp (
  input  logic data_i,      // from the switchable domain
  input  logic iso_en,      // 1 while that domain is off
  input  logic clamp_val,   // the safe idle value for this signal
  output logic data_o
);
  always_comb begin
    if (iso_en) data_o = clamp_val;
    else data_o = data_i;
  end
endmodule