When a domain wakes up, why can always-on neighbours fail, and how do you check it?

Short Answer

A waking domain draws its in-rush current through the same straps, vias and bumps that feed the always-on logic around it, so neighbours see a dynamic drop exactly while they may be busy. Check it with a RedHawk ramp-up run in mixed mode, where setup analysis_mode lowpower (RH) is combined with perform analysis -dynamic (RH), and judge the always-on region during the wake window, not just the switched domain.

Technical Explanation

• Shared source: headers on VDD1p0 pull in-rush from the same grid that feeds PD_MYCHIP cells next to PD_COP.
• When it dips: the drop peaks while many switches conduct and VDD1p0_SW is still low, and lasts about as long as the ramp.
• Victims: always-on flops, the power controller U_PC and isolation-enable drivers near the boundary; a slowed cell can miss setup, and a deep dip can glitch a control signal.
• Static IR misses it: static analysis averages current, and an ON-state dynamic run never includes the turn-on event.
• Mixed mode: RedHawk can run lowpower mode with perform analysis -dynamic (RH), so the ramp and always-on switching share one simulation.
• Baseline: analyze_rail -voltage_drop (ICC2) with dynamic_vectorless gives the always-on drop without the wake event, so you can see what the wake adds.
• Fixes: stage the switch enables, add decap along the boundary, add straps or bumps on VDD1p0, or hold critical always-on activity until the switch ack returns.

# [ICC2]  icc2_shell
analyze_rail -voltage_drop dynamic_vectorless -nets {VDD1p0 VSS}
# [RedHawk]  redhawk TCL shell
setup analysis_mode lowpower
import gsr mychip_wake.gsr
setup design
perform pwrcalc
perform extraction -power -ground -c
perform analysis -dynamic

What To Check

• Worst VDD1p0 drop in the always-on region around PD_COP during the wake window.
• Always-on cells near the boundary: U_PC, isolation-enable drivers, retention control buffers.
• The wake-time drop against the dynamic IR budget used in timing signoff.
• Whether software keeps always-on traffic running while PD_COP wakes.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): Worst always-on VDD1p0 drop near PD_COP during wake is 38 mV against a 50 mV budget.
• Suspicious (illustrative): Worst bin is 44 mV, inside budget, but the bins over 40 mV cluster around U_PC.
• Hard stop: Always-on bins next to the first switch group reach 72 mV, above the 50 mV budget, with U_PC inside one of them.

What The Interviewer Is Testing

• Do you see that in-rush is a problem for the always-on neighbours, not only for the waking domain?
• Can you name a check that includes the turn-on event and the fixes that trade area against wake time?

Follow-up Question & Model Response

"Could you avoid this with a separate supply feed for the switched domain?"

Candidate Model Response: Partly, if the bump plan allows it: headers fed from their own bumps and straps keep most in-rush off the always-on grid. The cost is bumps, routing tracks and more supply planning, and the two grids usually still share the package plane. Most teams stage the enables and add decap first, because that costs area and wake time instead of package changes. A separate feed pays off when the switched domain is large and wakes often.