How do you analyze in-rush current when a domain powers up?

Short Answer

Ramp-up analysis in RedHawk simulates a switched domain turning on: switch models, the domain's capacitance and the real enable timing give the total in-rush current and the virtual-rail voltage over time. Run perform analysis -lowpower (RH) after the usual power and extraction steps, then read virtual_domain_total_i.rpt (RH) for current and virtual_domain_worst_v.rpt (RH) for the ramp.

Technical Explanation

• Physics: the off domain's virtual rail and all its gate and wire capacitance charge from near 0 V through the switches; that charging current is the in-rush.
• Inputs: switch models through SWITCH_MODEL_FILE (RH), switch nets in VDD_NETS and GND_NETS, powering-up instances in the GSC file, and a piecewise-linear capacitance file.
• Initial state: without a piecewise-linear capacitance file, RAMPUP_OFFSTATE_VOLTAGE (RH) sets the starting voltage of the off domain.
• Enable timing: the STA timing file must give timing windows for the switch control pins, so daisy-chain delays come from the real design.
• Outputs: total ramp-up current per switched domain, the worst node voltage waveform, and per-switch peak current and final ON or OFF state in switch_dynamic.rpt (RH).
• What breaks: a fast enable gives a peak that droops the shared supply; a slow one pushes wake time past the software budget.

# [RedHawk]  redhawk TCL shell
setup analysis_mode lowpower
import gsr mychip_rampup.gsr
setup design
perform pwrcalc
perform extraction -power -ground -c
perform analysis -lowpower

Formula Or Decision Rule

• Charge to deliver: Q = C_dom × V_DD, where C_dom is the total capacitance on the virtual rail.
• Average in-rush current: I_avg = Q / t_ramp = C_dom × V_DD / t_ramp.
• Peak current: roughly the number of switches conducting while the rail is still low, times each switch's saturation current.
• Decision rule: pick the enable schedule so the peak stays inside the current budget and t_ramp stays inside the wake budget.

What To Check

• Every switch cell in PD_COP has a model in the switch model file.
• The GSC file marks only PD_COP instances as powering up.
• Control-pin timing windows come from the real daisy-chain STA, not defaults.
• The peak in virtual_domain_total_i.rpt is compared against a budget agreed with the package and grid owners.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): PD_COP peaks at 28 mA and VDD1p0_SW reaches 95% in 1.2 µs, inside a 60 mA budget and a 2 µs wake target.
• Suspicious (illustrative): The peak is inside budget but virtual_domain_worst_v.rpt shows a long tail, so a few far rows reach full voltage late.
• Hard stop: A single-stage enable peaks at 180 mA against the 60 mA budget, or switch_dynamic.rpt lists switches still OFF at the end.

What The Interviewer Is Testing

• Can you connect in-rush current to capacitance, voltage and ramp time?
• Do you know which inputs RedHawk needs for ramp-up and which reports to read?

Follow-up Question & Model Response

"Why is the peak current not simply C × V divided by the ramp time?"

Candidate Model Response: C × V over the ramp time is the average current. The peak depends on how many switches conduct while the virtual rail is still near 0 V, because each one then has almost the full supply across it and runs at its saturation current. Turning every switch on at once puts all of them in that state together, so the peak lands well above the average. Staging the enables means only one group conducts hard at a time, which cuts the peak far more than it stretches the wake time.