Rush Current and the Daisy Chain

Part one

The mechanism

What a gated domain actually contains, what it costs to refill it, and who pays when you do it all at once.

01The question nobody asks #

You know how to turn a block off. Isolation on the outputs, save the registers you care about, drop the switch enable, and the domain stops leaking. Every low-power course teaches that, and every interview asks it.

Here is the question that follows, and it is the one almost nobody has an answer ready for. What does it cost to turn it back on?

Not in area. Not in leakage. In amperes.

   VDD                        1.0 V
   switch on-resistance       200 Ohm each, 5,000 in parallel  ->  40 mOhm
   grid resistance            20 mOhm

   I = 1.0 / 0.060  =  16.7 A

Sixteen amperes, out of a supply grid that was sized for a few hundred milliamps, for a few nanoseconds, every single time that block wakes up. The numbers are illustrative, but the order of magnitude is not.

That current has a name. It is called rush current, or in-rush current, and the mechanism that stops it from wrecking your chip is a wire that walks the enable signal through the switch fabric one cell at a time: the daisy chain.

This guide is about those two things, and about the third thing nobody mentions until it is too late, which is that the fix has a price measured in nanoseconds, and that price is an architecture decision, not a physical-design one.

What you should already know

You should know what a power domain is, what a header switch does, and roughly why isolation cells and retention flops exist. You do not need to have run a power-gating flow. If you have, the parts you will care about start at section 8.

02Off means discharged #

Two things are true of a gated-off domain, and the second one is the reason this guide exists.

The first is the one everyone knows: off is not zero. A domain with its header switches open still leaks - through the switches themselves, and through whatever always-on cells live inside it. The library characterises that leakage and the design has to budget for it. Powering down buys you most of the leakage back, not all of it.

The second is quieter and more expensive. Off means discharged.

When the switches open, the virtual rail stops being driven and everything hanging off it drains to ground. The gate capacitance of every cell in the domain. The interconnect capacitance of every net. And - the big one - every picofarad of decoupling capacitance you deliberately placed on that rail to keep it steady while the block was running.

All of it has to be put back before the block can work again. That stored charge deficit is where rush current comes from. It is not a parasitic effect or a second-order correction. It is the bill for the thing you asked for.

What being off costs you - illustrative

Proportions vary enormously with the domain. What does not vary is that the decap you added for stability is also the decap you have to refill.

03The switch cell you will actually instantiate #

Before the arithmetic, the object. A power switch comes in two flavours, and the choice is usually made for you.

Headers dominate in practice. With a header, ground stays common across the whole die, which keeps isolation, retention and every substrate-related question simpler. The price is physical: a PMOS device carries roughly two and a half times less current per unit width than an NMOS, so a header fabric is substantially larger than a footer fabric of the same on-resistance. You pay in area to keep the ground clean.

The other axis is granularity.

Most ASICs are coarse-grain. Which is to say: most ASICs have chosen the large-rush-current option, and then have to manage it.

Inside the cell

A switch cell is not just a transistor in a box. Open one up and there is a buffer in there too, and that buffer is the whole reason the rest of this guide works.

In a real library those pins are usually called SLEEPIN and SLEEPOUT, or NSLEEPIN and NSLEEPOUT for the active-low flavour. The buffer between them has a propagation delay, and the cell datasheet will quote it. Hold on to that number: it is about to become the most important number in the design.

04Why there are thousands of switches #

Nobody puts 5,000 switch cells into a block because they enjoy the area. They do it because of a single, unavoidable piece of Ohm's law.

When the domain is running, all of its current flows through those switches. Whatever resistance they present appears as a voltage drop between the always-on grid and the rail the cells actually see. That drop comes straight out of the timing margin of every path in the domain.

The arithmetic is not subtle. The drop is the domain current multiplied by the fabric resistance, and the fabric resistance is one switch's resistance divided by however many you put down in parallel:

   R_fabric  =  R_on / N
   V_drop    =  I_domain * R_on / N

   500 mA * 200 Ohm / 5,000   =   20 mV

Halving the drop means doubling the switch count. So the fabric grows until the drop fits inside the budget, and then it stops. That is the entire design rule, and it is a good one.

It is also a trap, and the next section is about why.

05The trap in that argument #

Look at that fabric resistance again. Forty milliohms. You arrived at it by insisting that the steady-state drop be small, and forty milliohms is a very good answer to that question.

Now ask a different question. What happens if you close all 5,000 of those switches at the same instant, with the rail at 0 V?

You have just connected a fully discharged capacitor to the supply grid through forty milliohms. Nothing in that circuit is limiting anything. The current is set by the resistance you worked so hard to make small.

What the fabric buys, and what it costs - illustrative

06Rush current, derived #

Three equations, and none of them is hard. The difficulty was never the mathematics - it is that the three are usually taught in different weeks.

One: the current

   I_peak  =  VDD / (R_switches + R_grid)
   R_switches = R_on / N  =  200 / 5,000  =  40 mOhm
   R_grid     = 20 mOhm                   (illustrative)

   I_peak  =  1.0 / 0.060  =  16.7 A

Two: the charge

   Q  =  C_rail * VDD
   C_rail = 20 nF   (decap + cell + net capacitance, illustrative)

   Q  =  20e-9 * 1.0  =  20 nC

Three: the time

   t_ramp  ~  C_rail * VDD / I_avg
   RC      =  0.060 * 20e-9  =  1.2 ns

Read those three numbers together and the shape of the problem is plain. The energy is small: twenty nanojoules, and the charge behind it twenty nanocoulombs. The power is enormous, because it is delivered in about a nanosecond. Rush current is a dI/dt problem, and dI/dt is what a supply grid is worst at absorbing.

07Who actually gets hurt #

The block being powered up is not the victim. It is at 0 V and has no opinion about anything. The damage lands on the always-on grid, and through the grid, on whatever else happens to be running.

What one wake-up costs the neighbours - illustrative

1. IR droop on the shared grid

The surge pulls VDD down across the always-on network. Every domain sharing that grid slows down for as long as the droop lasts. Paths that closed comfortably at nominal voltage go negative. The failure appears in a block that is functioning perfectly, caused by an event in a block that is not even running yet, and it is brutally hard to debug for exactly that reason: there is nothing wrong with the thing that failed.

2. Electromigration on the fabric straps

Amperes through the straps that feed the switch fabric consume electromigration budget in those wires. A single event is nothing. A device that wakes its accelerator a thousand times a second, for years, is not a single event - it is a lifetime question, and it is answered with an RMS current over the duty cycle rather than a peak.

3. Ground bounce

The same current has to return. Ground rise on VSS has the same effect on timing as droop on VDD, and a worse effect on anything holding an analogue reference.

4. Retention corruption

This is the one that turns a power-saving feature into a respin. Retention flops hold their state on the always-on supply. If the droop is deep enough and lasts long enough, the state you powered the domain down specifically to preserve is the state you lose. The block wakes up, restores, and restores garbage.

08Weak first, then strong #

The fix is not to make the fabric smaller. You already proved you cannot - the steady-state drop demands every one of those switches. The fix is to stop closing them all at the same time.

Split the fabric by strength and sequence it.

1. Weak stage. A small number of deliberately high-resistance devices - or a separate weak leg inside each switch cell - turns on first. Their resistance is the current limit. The rail ramps over hundreds of nanoseconds instead of shorting.
2. Strong stage. Once the rail has reached most of VDD, the strong switches close. By then the voltage across them is small, so the current is small, and they take over the steady-state load with the low resistance the design was sized for.

Two numbers make the teal curve worth having. The peak current never exceeds a few hundred milliamps, which the grid absorbs without noticing. And the whole thing finishes in about 205 nanoseconds instead of eight, which sounds like a loss until you look at what those eight nanoseconds cost.

In library terms this arrangement is sometimes called mother-daughter: a strong "mother" switch and a weak "daughter" that fires first. The same idea also appears as several independent chains staggered against each other, which is what you reach for when one chain cannot meet both the current limit and the latency budget.

09The daisy chain #

Splitting the fabric into two strengths is half the answer. The other half happens within each stage, and it is where the name in the title comes from.

Inside a stage, the enable does not broadcast. It ripples.

Each switch cell has an enable input and an enable output, and the cells are stitched together so that switch n hands the enable to switch n+1 after its own buffer delay. The buffer inside the cell - the one you met in section 3 - is the stagger element. That is what it is for. It is not there to drive the gate; the gate is a few femtofarads. It is there to delay.

Physically, the chain is a long signal net threading the entire switch fabric in placement order. The tool builds it and orders it. Your job is to constrain it, to check that the electrical order matches the physical order, and to make sure the far end genuinely reports back.

What the chain buys, and what it costs - illustrative

10Mentor's aside: it is not a shift register #

On a floorplan, the switch enable chain and a scan chain look identical. Both are a single net that visits a long list of cells in placement order. Both are reordered by the tool after placement. Both produce a satisfying-looking snake when you highlight them.

They have nothing else in common, and conflating them causes real mistakes.

Low-Power & UPFDomains, isolation, retention, and multivoltage UPF. →

11The arithmetic nobody does #

Everything so far, in one place, worked end to end. Substitute your own numbers; the structure does not change.

the stagger

   5,000 switch cells  x  30 ps per cell
   = 150 ns   just to propagate the enable from end to end

the surge, if fired together

   R_on per switch                200 Ohm    (illustrative)
   N                              5,000
   R_switches = 200 / 5,000       40 mOhm
   R_grid                         20 mOhm    (illustrative)
   VDD                            1.0 V
   I_peak = 1.0 / 0.060           16.7 A

the charge to be replaced

   C_rail                         20 nF      (illustrative)
   Q = C x V = 20e-9 x 1.0        20 nC

the weak stage, current-limited

   R_weak (all weak legs)         4 Ohm      (illustrative)
   I_weak at t = 0 = 1.0 / 4      250 mA
   RC = 4 x 20e-9                 80 ns
   ramp to ~0.85 V                ~150 ns

total wake-up latency

   enable propagation             ~150 ns
   rail settling                  ~55 ns
   acknowledge return             tens of ns
   reset release, restore, isolation release, clock restart
   ---------------------------------------------------------
   ~400 ns, and microseconds on a large domain

12The acknowledge is the only evidence #

The controller asserts the enable. Some time later the domain is ready. How does the controller know?

There is exactly one honest answer: the far end of the chain tells it. That signal is the acknowledge - PSE_ACK in this guide, SLEEPOUT or NSLEEPOUT at the library cell. It is the enable, having walked the entire fabric, arriving back.

Three things that must be true of it

• It must be always-on logic. It originates inside a domain that is at 0 V for most of its path. Every cell on it needs a supply that does not go away, or the acknowledge is not a signal, it is a floating node.
• It must come from the actual far end. Not from the controller's own counter dressed up as an acknowledge. Not from the first cell. The whole value of the signal is that it proves the last switch closed.
• The chain order must match the physical order. If the tool orders the chain by netlist name rather than placement, the "far end" electrically may be the near end physically, and the acknowledge will arrive before the fabric is actually on.

In UPF, the acknowledge belongs to the switch declaration itself, along with the delay you expect it to take.

13The full sequence, both directions #

Power-down and power-up are not mirror images, and writing them out as if they were is a reliable way to build a controller that almost works.

Down

1. flush any outstanding bus or external transactions
2. stop the clock
3. assert isolation on the domain outputs
4. assert SAVE, capturing state into the retention latches
5. assert reset
6. drop the switch enable

Up

1. assert the weak switch enable, and let the rail ramp
2. assert the strong switch enable
3. wait for PSE_ACK from the far end of the chain
4. release reset
5. assert RESTORE, reloading the retained state
6. de-assert isolation
7. restart the clock, glitch-free

One naming point before the list, because it trips people up. The figure above draws the switch state: high means the device is conducting. The UPF control port you will meet in section 14 is active-low, so the signal called PSE in the intent file is the inverse of those two traces. Keep the two straight and the sequence reads the same either way; mix them up and you will build a controller that powers the domain down when it means to wake it.

Part two

The implementation

Writing the intent down, and then building it out of metal, vias and placement constraints.

14Expressing it as power intent #

None of this is real until it is written down somewhere both the implementation tool and the verification tool will read. That place is the power intent file.

the switch, and the acknowledge

create_power_switch PD_ACC_SW \
  -domain             PD_ACC \
  -input_supply_port  {vin  VDD} \
  -output_supply_port {vout VDD_ACC_SW} \
  -control_port       {sleep U_PC/PSE} \
  -ack_port           {ack   U_PC/PSE_ACK} \
  -ack_delay          150 \
  -on_state           {on  vin {!sleep}} \
  -off_state          {off {sleep}}

The acknowledge belongs to the switch declaration, and so does the delay you expect it to take - which is the chain length you calculated, not a guess. -ack_delay is in the design's UPF time unit; here that is nanoseconds, so 150 is the 150 ns from section 11.

Two things in that fragment are worth dwelling on. -ack_port names the signal that comes back from the far end of the chain, and -ack_delay is where the 150 ns you derived in section 11 actually lands in the database. If those two disagree with the silicon, every downstream check inherits the disagreement.

weak and strong, as two declarations

create_power_switch PD_ACC_SW_WEAK \
  -domain             PD_ACC \
  -input_supply_port  {vin  VDD} \
  -output_supply_port {vout VDD_ACC_SW} \
  -control_port       {sleep U_PC/PSE_W} \
  -on_state           {on vin {!sleep}}

map_power_switch PD_ACC_SW_WEAK -domain PD_ACC \
  -lib_cells {HDRSW_WEAK_X1}
map_power_switch PD_ACC_SW      -domain PD_ACC \
  -lib_cells {HDRSW_X8}

The power intent says which control drives which switch. It is the library cell chosen by map_power_switch that makes one of them weak and the other strong - the strength is a property of the device, not of the declaration.

isolation on the way out

set_isolation PD_ACC_ISO -domain PD_ACC \
  -isolation_power_net  VDD \
  -isolation_ground_net VSS \
  -clamp_value 0 -applies_to outputs

set_isolation_control PD_ACC_ISO -domain PD_ACC \
  -isolation_signal U_PC/ISE -isolation_sense high

A clamp value of 0 is implemented with an AND gate, a clamp value of 1 with an OR. Note which supplies the isolation cell itself runs from: VDD and VSS, the always-on pair. An isolation cell powered by the rail it is isolating is not an isolation cell.

retention, and the controls that drive it

set_retention PD_ACC_RET -domain PD_ACC \
  -retention_power_net  VDD \
  -retention_ground_net VSS \
  -elements {u_acc/u_ctrl}

set_retention_control PD_ACC_RET -domain PD_ACC \
  -save_signal    {U_PC/SRE high} \
  -restore_signal {U_PC/SRE low}

SAVE and RESTORE originate in the always-on controller, and must never be mis-asserted together. The retention power net is the always-on supply - that is the whole mechanism: a second latch on a rail that does not go away.

And the state that is not a state

The domain has two declared operating states. It spends real time in neither of them.

For the two or three hundred nanoseconds the rail spends climbing, the domain is in a condition that appears nowhere in the power state table. That is not an oversight in the table. A power state table describes operating points - conditions in which the design is expected to function correctly - and a rail at 0.6 V is not one of those. The whole purpose of the control sequence is to guarantee that nothing observes the domain while it is in that condition: isolation is still on, reset is still applied, and the clock has not started.

If you ever find yourself wanting to add a "ramping" row to the table so that some check stops complaining, stop. The check is telling you that something is looking at the domain too early.

15Building it in metal #

Everything up to here has been electrical. Now it has to occupy area, consume tracks and connect through vias, and each of those has a bill.

Ring or grid

Ring against grid - illustrative

The virtual rail is real metal

It is easy to talk about virtual VDD as though it were a concept. It is not. It is a supply network with its own trunks, its own straps, its own via stacks and its own IR budget - and that budget is spent on top of whatever the always-on grid has already spent.

What the switched rail costs - illustrative

Secondary PG, and the cells that need it

This is where a power-gating flow stops being about switches and starts being about placement. Dual-rail cells can only go where both rails exist. The tool expresses that with secondary PG placement constraints, either declared with create_secondary_pg_placement_constraints and committed, or derived from the design with derive_secondary_pg_placement_constraints. Either route needs the advanced legalizer enabled.

What retention costs - illustrative

Signals that have to survive the dark

Every control signal in this guide is one of these. The switch enable walking through the fabric, the acknowledge coming back, the isolation enable, SAVE and RESTORE - all of them run through logic that is physically inside a domain that spends most of its life at zero volts. The tool sets is_always_on_logic on buffers and inverters whose supply differs from the domain primary, and check_mv_design is what catches the ones it missed.

What always-on logic costs - illustrative

Decap's double edge

What decap costs on a switched rail - illustrative

16Signing it off #

Four checks. Three of them are not the ones a normal block runs.

1. The surge is a transient, so analyse it as one

A static voltage-drop analysis will not find this. Static analysis builds a resistor network, replaces the supply with an ideal source, computes an average current per cell and distributes it. It explicitly assumes that decoupling capacitance smooths out the peaks, and it explicitly excludes localised dynamic effects. A 16.7 A event lasting a nanosecond is precisely the localised dynamic effect it was built to ignore.

analyze_rail -voltage_drop static
analyze_rail -voltage_drop dynamic
analyze_rail -electromigration

Run the dynamic analysis with the wake-up event in the stimulus, not just the running block. If your dynamic run never has the domain turning on in it, you have not analysed the thing this guide is about.

2. Electromigration over the duty cycle

A peak current does not by itself violate an electromigration rule; a sustained RMS current does. The question for the fabric straps is not "how big is the surge" but "how often does it happen, for how many years". A domain that wakes ten times a second and one that wakes ten thousand times a second have the same peak and wildly different lifetimes.

3. From droop budget to stagger

The chain length is not a taste. It falls out of the droop budget, and you can derive it in four lines.

   droop budget                    50 mV   of 1.0 V  (illustrative)
   grid impedance at the event     20 mOhm
   allowed current                 0.050 / 0.020  =  2.5 A
   unstaggered current             16.7 A
   -> the fabric must be spread by at least  16.7 / 2.5  =  6.7x
   and in practice by much more, because the grid is inductive

That last line matters. A supply grid is not a resistor; it has package and on-die inductance, and inductance responds to dI/dt, not to I. Spreading the same charge over a longer time helps twice - once through the resistive term, and again, more strongly, through the inductive one. It is also why the number you actually ship usually has a good deal of margin on top of the arithmetic above.

4. The control path is a timing path

The enable, the acknowledge, the isolation enable and the retention controls are not "power signals" exempt from static timing analysis. They are ordinary constrained paths that happen to live in an always-on domain and cross into one that switches off.

• SAVE and RESTORE have setup and hold requirements against the clock that captures them. Getting the sense backwards restores the wrong data, and it will not show up in a functional simulation that never powers down.
• The isolation enable has to be stable before the rail moves and must not release until after it has settled. Both of those are timing checks against the sequence, not just functional intent.
• The chain itself is a long combinational path across the block. It is not a violation that it is slow; it is a violation if anything downstream assumes it is fast.

So the wake-up event needs signing off at the fast corner, where the switch devices are strongest and the surge is largest, while the paths that droop breaks are closed at the slow corner. Two corners, one event. A scenario list that only contains one of them is not covering this.

Part three

The judgement

When the whole technique is worth it, when it is not, and what to remember either way.

17When power gating loses #

Every section so far has assumed power gating is worth doing and asked how to do it safely. This section asks the other question, and the answer is not always yes.

Gating a domain saves leakage while the domain is off. It costs energy to put the charge back, and it costs energy to run the controller, the isolation and the retention through the whole sequence. So:

   gating wins when
     leakage saved while off  >  energy to refill  +  energy in latency

   the latency term is dropped below: see the note

   P_leak x t_off  >  C_rail x VDD^2

   t_off  >  C_rail x VDD^2 / P_leak
          =  20e-9 x 1.0^2 / 8e-3
          =  2.5 us

The arithmetic drops the second term on the right, and it should say so. During the ramp the domain is held in reset with its clock stopped, so almost nothing in it is switching and the energy burned during the wake-up is small beside the 20 nJ needed to refill the rail. Dropping it makes the break-even slightly optimistic - the real crossover sits a little later than 2.5 us, not earlier. If your controller runs the domain at speed while the rail settles, put the term back.

Below that crossover, powering the domain down costs more energy than leaving it on and clock-gating it. And the crossover is not a small number. For an accelerator that wakes for a two-microsecond burst and sleeps for three, power gating is a net loss - it is doing work, adding risk and consuming area to make the chip use more energy.

Two honest consequences follow.

• Wake-up latency is an architecture number, not a physical-design one. A 400 ns turn-on consumes a fifth of a two-microsecond burst before any useful work happens. The team that chose the duty cycle and the team that sized the fabric need to have had the same conversation.
• The deeper you power down, the more it costs to come back. That is not a slogan. Retention off, full reset and reload is cheapest in leakage and most expensive in wake-up. Retention on is the middle. Clock gating is the shallowest and the fastest. Which one wins is decided entirely by how long the domain is actually idle - a number that comes from software, not from silicon.

18What to carry away #

Twelve statements. If you can say each of these from memory and defend it, you know this subject better than most people who have shipped it.

1. Off means discharged. The charge in every gate, every net and every picofarad of decap on the switched rail has to be put back before the block can run.
2. The fabric is sized by the steady-state IR drop, and that sizing is exactly what makes the turn-on dangerous.
3. Rush current is limited only by the switch resistance in parallel with the grid. With 5,000 switches and 1 V, that is amperes.
4. It is a dI/dt problem, not an energy problem. The energy is tiny; the rate is not.
5. The damage lands on the always-on grid and on the neighbours, not on the block being woken.
6. The worst outcome is retention corruption: losing the state you powered down to keep.
7. The fix is weak switches first, strong switches after, with the enable rippling through the fabric rather than broadcasting.
8. The buffer inside the switch cell is the stagger element. Its delay is the mechanism, not an overhead.
9. 5,000 cells at 30 ps is 150 ns of propagation before the rail has even settled.
10. Only the acknowledge from the far end of the chain proves the fabric is on. A counter is not evidence.
11. The worst-case power corner is fast, maximum voltage, maximum temperature - the opposite of the worst-case setup corner.
12. Below some idle duration, power gating costs more than it saves, and clock gating wins. Find out what that duration is before you build the fabric.

19Interview questions #

Fourteen questions, in the order they tend to be asked. Each answer is followed by what is really being tested, because that is usually different from what is being asked.

20Glossary #

Everything this guide uses, in one place.