SIPI

Power Integrity / 09

Power-Supply-Induced Jitter: Connecting PI and SI

A gate switches faster when its supply is higher and slower when it is lower. So noise on a power rail does not stay in the power domain — it comes out of the clock tree as timing noise. This is the bridge between power integrity and signal integrity, and it is the reason a jitter problem is sometimes a decoupling problem.

Best viewed on a laptop or desktop. These panels are built so you can move a slider and watch several charts answer at once. A phone has no room to put them side by side.

Supply ripple → delay modulation → periodic jitter illustrative periodic jitter rms noise at loop
The supply — three periods of the ripple
supply ripple ±peak
The clock edge — magnified to picoseconds
nominal edge at peak / trough pk-pk displacement
30 mV peak
This is a PDN number, not an SI one
120 MHz
Whether the loop helps depends on where the noise enters
30 ps/V
Delay change per volt of supply, per stage ps per stage per unit supply
8 stages
The effect accumulates down the tree
A first-order loop treats these three oppositely

Why a power problem becomes a timing problem

In hardware engineering teams, Signal Integrity (SI) and Power Integrity (PI) are often treated as entirely separate disciplines. SI engineers focus on eye diagrams, loss budgets, trace geometry, and equalization; PI engineers focus on decoupling capacitor counts, plane impedance, and millivolts of ripple. Power-Supply-Induced Jitter (PSIJ) is the direct physical bridge where these two worlds collide.

Every digital gate, clock buffer, and serializer in a high-speed transmitter is constructed from CMOS transistors whose propagation delay is governed by their operating voltage. When a power rail fluctuates because of load steps or resonant impedance peaks, the transistors switch faster when the supply rises and slower when it dips. That voltage ripple is converted directly into picoseconds of timing uncertainty on clock and data edges. An engineer trying to debug a closed eye by adjusting receiver equalization will make zero progress if the jitter is actually being generated by a ringing power plane ten millimetres away.

A CMOS stage charges its load through a transistor, and how much current that transistor delivers depends on its gate-to-source voltage — which is referenced to the supply. Raise the supply and the stage drives harder and switches sooner. Lower it and the stage switches later.

One stage's shift is tiny. But a clock edge passes through a long chain of buffers on its way from the PLL to the flip-flops, and each one adds its own shift in the same direction. The delay change accumulates down the tree.

So a rail wobbling by a few percent produces an edge arriving a few picoseconds early or late, varying at whatever rate the rail is wobbling. That is jitter, and it has arrived without anything at all happening to the signal path.

Voltage modulates delay

A CMOS stage drives its load with a current set by its supply. Lower the supply and the stage switches later; raise it and it switches earlier. Across a clock tree of many stages the effect accumulates, so a small percentage wobble on the rail becomes a meaningful shift in when the edge arrives.

The sensitivity is usually expressed as delay change per unit of supply change, and it is highly design-dependent — a long clock tree on a low-voltage rail is far more sensitive than a short path on a well-regulated one. What matters structurally is that the relationship exists, is roughly linear for small perturbations, and multiplies by the number of stages the edge passes through.

The frequency decides its fate — but only once you say where it entered “A PLL tracks out slow supply noise” is right for exactly one injection point, and a first-order loop treats the three oppositely. Noise on the VCO, inside the loop, is high-pass filtered: the loop corrects it below the loop bandwidth. Noise at the reference is low-pass filtered — the loop follows it onto the output, so slow reference noise is not removed at all. Noise on an output buffer outside the loop has no feedback path reaching it and is never corrected at any frequency.

The panel above makes the difference concrete: the same 30 mV of 1 MHz ripple produces 3.5 ps peak-to-peak entering at the VCO and 14.0 ps entering at the reference. Four times the jitter from an identical supply. “How much ripple?” has no answer without “entering where?”

The debug signature

This is the mechanism that makes PI and SI one problem, and it has a recognisable fingerprint. A PDN impedance peak at some frequency, excited by activity at that frequency, produces supply ripple at that frequency, which produces periodic jitter at the same frequency in the eye.

So when jitter decomposition reports a PJ component, the first question is what its frequency is, and the second is whether that frequency matches anything on the PDN impedance plot. A match is close to a diagnosis. Common culprits, in rough order:

The practical lesson is about ownership rather than physics. An eye that fails with clean-looking signal integrity — good return loss, budgeted insertion loss, crosstalk under control — and a stubborn periodic jitter term is not an SI problem being solved by an SI engineer. Looking at the PDN impedance plot early costs an hour and regularly saves a week of channel tuning that was never going to work.

Sources

Why this decides how your board behaves

What to do about it

First establish where the noise is entering. This is the whole diagnosis, and the panel above is built around it. The answer determines whether the loop helps you, ignores you, or actively carries the noise onto the output.

Attack the impedance at the frequency that matters, not everywhere. Once you know the injection point, the loop's response tells you which band of rail noise actually reaches the output. Flattening the PDN somewhere the transfer function rejects is effort spent for nothing.

Separate the sensitive rails. A dedicated supply for the PLL and SerDes — ideally through its own regulator, or at minimum through a filter — breaks the coupling path rather than reducing it. On-chip low-dropout regulation for analogue blocks exists for this reason.

Reduce the noise at its source where you can. Staggering clock-gate release lowers the di/dt that made the noise in the first place, and it costs no hardware. The best PDN-induced jitter fix is often a firmware change.

Using this to find a fault
  • Jitter with a periodic component at a switching-regulator frequency. Almost conclusive. Read the spur frequency and compare it with the converter's switching rate and its harmonics.
  • Jitter that changes with workload but not with the data pattern. The channel is not the cause. Rail noise tracks activity; ISI tracks the pattern.
  • A link that degrades when an unrelated block powers up. Shared rail or shared plane. Check the transfer impedance between them, not the channel.
  • Jitter present at the transmitter output with a clean input clock. The noise is getting in after the reference — output buffer supply or VCO, and the frequency dependence will tell you which.
Go deeper — the three injection points, and why "a PLL tracks out slow noise" is only sometimes true

The common claim is that a PLL removes slow supply noise. That is right for exactly one injection point, and a first-order loop treats the three oppositely:

  • Noise on the VCO — inside the loop. High-pass filtered. The loop measures the phase error and corrects it, so noise below the loop bandwidth is suppressed and noise above it passes. This is the case the claim describes.
  • Noise at the reference. Low-pass filtered — the exact opposite. The loop's job is to follow the reference, so slow reference noise is faithfully reproduced on the output and is not removed at all.
  • Noise on an output buffer — outside the loop. No feedback path reaches it, so it is never corrected, at any frequency.

This is why identical rail noise can produce very different output jitter depending on which supply it landed on, and why the first question in any PSIJ investigation has to be where rather than how much.

The KPSIJ sensitivity coefficient and the jitter budget. Inside silicon design kits, power-supply jitter sensitivity is quantified by the metric KPSIJ = ∂tdelay / ∂Vdd, expressed in picoseconds of edge displacement per millivolt of supply ripple (ps/mV). For a typical clock distribution tree or multi-stage CML-to-CMOS converter, KPSIJ commonly falls between 0.05 and 0.20 ps/mV.

The consequence for multi-gigabit links is severe. Consider a 32 Gbps NRZ link with a unit interval of just 31.25 ps. If the transmitter's clock tree has a KPSIJ of 0.12 ps/mV, a modest 40 mV peak-to-peak ripple on the VDD rail injects 40 mV × 0.12 ps/mV = 4.8 ps of deterministic periodic jitter (PJ). That single power-supply perturbation eats over 15% of the total timing budget before channel loss, crosstalk, or receiver setup time even take their share.

The units trap. Supply sensitivity is quoted as a delay change per volt, or sometimes as a fractional delay change per fractional supply change. Those are different quantities and mixing them is an easy way to be out by the supply voltage — a factor of nearly one and a half on a 0.75 V rail versus a 1.1 V one. Always check whether a sensitivity figure is ps/V or ps/%.

And a caution about superposition. The linear treatment here assumes the perturbation is small enough that delay varies linearly with supply. For a deep droop that stops being true — the relationship is genuinely nonlinear at large excursions, and a sensitivity fitted at small signal will understate the effect of a big one.

In the real world

PDN-induced jitter is where the two halves of this site meet, and it is usually discovered by accident — a link fails, the channel is exonerated, and someone eventually looks at the supply. The reason it takes so long is organisational: channel analysis and PDN analysis are different tools, different models and frequently different people.

Which makes the useful habit a cheap one. When a jitter number does not reconcile with the channel model, look at the rail before re-examining the channel. It is ten minutes with a scope and it resolves the question either way.

Related

Sources

Rows marked with a claim id are tracked in the claim ledger, which records what each source can and cannot establish.