Why does the isolation enable have timing requirements, even though it's "just a control signal"?
From PDVerse Low-Power Physical Design Mentor Guide · pdVerse Mentor Guide
Short Answer
The isolation enable decides the moment the always-on side stops trusting a domain, so it is a timed event, not a static setting. It must reach every isolation cell and settle before the switched rail starts to fall, and it may only release once the rail is back, the domain is restored and its outputs are valid. The whole path that carries it must stay powered while the domain is off.
Technical Explanation
- Assert window: the controller stops the domain clock, raises ISE, and only after the slowest isolation cell clamps does it save state and open the switch.
- Fanout delay: one ISE often drives hundreds of isolation cells through an always-on buffer tree, so the latest arrival sets the margin, not the controller edge.
- Release window: release after the switch acknowledge, a stable VVDD, a finished RESTORE and valid outputs; release early and X or glitches reach live logic.
- Always-on path: ISE starts in the always-on controller U_PC, and every buffer on the way must sit on an always-on supply, never the switched rail.
- Quiet data: clamp while the source clock is stopped, so the output is not mid-transition when the gate closes and no half-clamped pulse reaches a live flop.
- Blind spot in STA: teams often set the enable as a false path because it toggles rarely, so a slow buffer tree never appears in any report.
- What breaks: clamp late and loads briefly see a decaying, floating output; release early and values from a half-powered domain land in PD_MYCHIP registers.
Common Mistake
The Trap: Declaring ISE a false path because it only toggles on power transitions, then never looking at its delay again.
- The controller waits two cycles while the farthest isolation cell needs three at the slow corner, and the first power-down test on silicon corrupts PD_CPU state.
- Report the worst ISE arrival instead, and size the controller wait from that number plus margin.
Follow-up Question & Model Response
"How many cycles should the power controller wait between asserting ISE and opening the switch?"
Candidate Model Response: Enough to cover the worst ISE arrival at the last isolation cell plus the cell clamp time, with margin for the slow corner. Take that number from a timing report on the enable net rather than guessing. If the tree takes 1.2 ns and the controller clock is 10 ns, one cycle covers it and a second adds margin at almost no cost. The release side is usually the tighter one, because the wait must cover the rail ramp and the restore.
Practical Example
Design Scenario: (illustrative) U_PC in PD_MYCHIP drives ISE to 380 isolation cells on PD_COP outputs through a five-level always-on buffer tree with 1.2 ns worst insertion delay at the slow corner. The controller runs at 100 MHz, so it waits two cycles (20 ns) after ISE before asserting SAVE, and one more before opening the switch. On wake, VDD1p0_SW takes about 2 us to ramp. The controller waits for the switch acknowledge, runs RESTORE, waits two more cycles, and only then releases ISE and restarts the PD_COP clock. All timing numbers here are illustrative.
Low-Power & UPF Handbook
Master Low-Power VLSI & Multivoltage Design
Read the complete low-power guide library covering power domains, level shifters, isolation clamps, state retention, and UPF signoff verification.
Continue practising