Why do you care about peak power, not just average power?
From PDVerse Low-Power Physical Design Mentor Guide · pdVerse Mentor Guide
Short Answer
Average power sets battery life and steady temperature, but peak power sets what the package, the power grid and the regulator must survive in a single instant. A chip can meet its average budget and still fail when many blocks switch together or a domain wakes up and draws rush current. You plan and check both, because they break different things: average power drains the battery and heats the package, while a peak collapses the supply for a few nanoseconds and fails timing inside that window.
Technical Explanation
- Average power: energy over a long window divided by time; it drives battery life, cooling design and steady-state junction temperature.
- Peak power: the highest short-window current, which the regulator, bumps, package and on-chip grid must deliver without the supply collapsing.
- di/dt: a fast current step through package inductance causes a supply droop of L times di/dt, on top of the resistive IR drop in the grid.
- Wake-up: switching on a gated domain charges its whole virtual rail at once; without staged switches that rush current droops the always-on neighbours sharing the grid.
- Hotspots: a block that bursts at high power heats locally, and leakage rises with that local temperature, even when the chip average looks comfortable.
- How you measure: average comes from activity over a use case; peak needs a time-resolved trace or dynamic IR analysis around the worst event.
- What breaks: a droop during a peak slows gates, so paths that pass static timing fail in that window, and a deep enough dip can flip flop state.
Common Mistake
The Trap: Sizing the regulator and power grid from the average power number alone.
- The first test that wakes PD_COP while the CPU is busy droops VDD1p0, and timing fails only in that mode, which is hard to reproduce on the bench.
- The fix after tapeout is firmware that forbids the overlap, which costs performance the architecture assumed it had.
Follow-up Question & Model Response
"How do you reduce peak power without lowering average performance?"
Candidate Model Response: Spread the events out in time. Daisy-chain the power switches so a domain wakes over microseconds instead of nanoseconds, and stagger clock enables so large blocks do not start on the same edge. Clock skew scheduling can also spread current across the cycle. These cost a little latency, but the average work done stays the same. Firmware can also forbid the worst overlaps, such as waking PD_COP during a CPU burst, if the analysis shows they cannot be fixed in hardware.
Practical Example
Design Scenario: (illustrative) MYCHIP averages 180 mW in video decode, well inside a 400 mW package limit. A time-resolved analysis shows a 6 ns window at 1.1 W when PD_COP wakes while U_CPU runs a burst: rush current into VDD1p0_SW plus CPU switching. VDD1p0 droops 70 mV against a 50 mV budget. Lengthening the PD_COP switch daisy chain spreads the wake over 1.5 us and brings the peak under 600 mW, with the average unchanged. The droop falls to 40 mV, inside budget, and the wake latency grows from a few nanoseconds to 1.5 us, which the power controller already allows for.
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