ExpertQuestion 24 of 50

What is the rush-current problem during power-up, and how do daisy-chain vs. parallel switch-enable sequencing strategies address it?

From PDVerse Low-Power Physical Design Mentor Guide, part of the pdVerse Mentor Guide

By Tabish Iqbal, who has 9+ years of VLSI Physical Design experience

Short Answer

When a switched domain wakes, its whole capacitance charges from 0 V through the switches, and if they all turn on at once the charging current spikes far above normal load. That spike pulls down the shared always-on supply and can upset neighbours, including the controller doing the wake-up. Daisy-chaining the switch enables spreads the turn-on over time, trading a longer wake-up for a much lower peak.

Two overlaid wake-up cases for PD_GPU: VVDD rising from 0 to 0.9 V in 20 ns with a 90 mA current spike when all switches enable at once, versus a 200 ns staged daisy-chain ramp with a 9 mA peak, and the shared VDD rail dipping below its limit (red) only in the parallel case. — Technical Reference DiagramWhat is the rush-current problem during power-up, and how do daisy-chain vs. parallel switch-enable sequencing strategies address it?

Technical Reference DiagramWhat is the rush-current problem during power-up, and how do daisy-chain vs. parallel switch-enable sequencing strategies address it?

Technical Explanation

Physics: in-rush current follows I = C·dV/dt, so the faster the virtual rail rises, the higher the peak.
Parallel enable: every switch turns on together, giving the fastest wake and the largest spike on the shared VDD and ground.
Daisy chain: each switch passes the enable to the next, so on-resistance drops step by step and the peak is spread over the chain delay.
Mother/daughter: weak switches charge the rail first, then strong ones close once VVDD is near target, a two-stage version of the same idea.
Acknowledge: the last switch drives the ack back to the controller, which must wait for it before restore and isolation release.
What breaks: the dip on the shared rail causes timing or state failures in always-on logic next door, so it is a signoff item.

# [UPF]  design.upf
create_power_switch SW_GPU -domain PD_GPU -input_supply_port {vin VDD0p9} -output_supply_port {vout VDD_GPU_SW} -control_port {sleep U_PC/gpu_sleep} -on_state {ON vin {!sleep}} -ack_port {ack U_PC/gpu_ack {!sleep}}
# [ICC2]  icc2_shell
connect_power_switch -source U_PC/gpu_sleep -port_name gpu_sleep -mode daisy -ack_out U_PC/gpu_ack -ack_port_name gpu_ack -voltage_area VA_GPU
check_mv_design
# [RedHawk]  redhawk TCL shell
perform analysis -lowpower

Formula Or Decision Rule

In-rush current: I_peak ≈ C_domain × ΔV / t_ramp
Decision rule: pick t_ramp so I_peak stays under what the shared grid and package can supply without dropping neighbours below their IR limit.

What To Check

Peak ramp current per domain stays under the agreed limit.
Worst voltage on neighbouring always-on logic stays inside its IR budget during wake-up.
The ack comes from the last switch in the chain, not the first.
The controller waits for ack before restore and isolation release.

Command Checks & Actions

UPF (design.upf)create_power_switch SW_GPU -domain PD_GPU -control_port {sleep U_PC/gpu_sleep} -ack_port {ack U_PC/gpu_ack {!sleep}}

Declare the switch with its control and acknowledge ports

ICC2 (icc2_shell)

connect_power_switch -source U_PC/gpu_sleep -port_name gpu_sleep -mode daisy -ack_out U_PC/gpu_ack -ack_port_name gpu_ack

Chain the switch enables and bring the ack back

ICC2 (icc2_shell)check_mv_design

Check switch and control connectivity against the UPF

RedHawk (redhawk)perform analysis -lowpower

Run ramp-up analysis with switch models

Healthy, Suspicious & Hard-stop Results

Healthy (illustrative): PD_GPU peak ramp current is 9 mA and neighbouring AON cells stay within the 27 mV budget during wake-up.
Suspicious (illustrative): Peak is under the limit, but wake-up takes longer than the 300 ns the power controller allows.
Hard stop: A 90 mA spike drops PD_AON below its limit, or ack returns from the first switch in the chain.

Common Mistake

The Trap: Assuming isolation and retention make the power-up safe, so all switches can close at once.

Isolation and retention handle logic values; rush current is a supply-integrity problem that can fail a domain that was never switched.

What The Interviewer Is Testing

Can you explain rush current from I = C dV/dt?
Do you know the wake-up time versus peak current trade?
Do you know where the ack must come from?

Follow-up Question & Model Response

"If the chain makes wake-up too slow, what are your options?"

Candidate Model Response: Split the chain into two or more parallel chains so each branch is shorter, accepting a higher but still bounded peak. Use a mother/daughter scheme so the slow part is a small trickle charge and the strong switches close quickly once the rail is up. Strengthen the shared grid or add decap near the domain so it can absorb a larger spike. Re-run ramp-up analysis after each change.

Practical Example

Design Scenario: (illustrative) PD_GPU has 2 nF of capacitance and wakes to 0.9 V. All switches at once ramp in about 20 ns: 2 nF × 0.9 V / 20 ns = 90 mA. A daisy chain stretches the ramp to about 200 ns, for 9 mA. The 90 mA spike pulled PD_AON 40 mV low, past its 27 mV budget; the 9 mA ramp keeps it inside. Wake-up grows by 180 ns, which the controller allows.

Low-Power & UPF Handbook