13.3 Clock Jitter: Cycle-to-Cycle Timing Variation

Distinguish clock jitter from clock skew, describe its common sources, and compute effective usable clock period accounting for peak-to-peak jitter.

Clock jitter is short-term variation in the exact timing of clock edges from one cycle to the next — unlike skew, which is a fixed (or slowly-varying) spatial difference between two physical points in a clock tree, jitter is a temporal, statistical variation in a single clock signal's own edge timing over time. Every real clock source — a crystal oscillator, a PLL (phase-locked loop), a clock recovery circuit — has some amount of jitter, and it directly eats into the timing margin available for logic, exactly the way skew does, but it must be characterized and budgeted differently because it's fundamentally a statistical quantity rather than a fixed offset.

Core concept: skew is spatial, jitter is temporal

The spec draws this distinction directly: skew is a spatial/path difference — a fixed (for a given design) offset between where two different flip-flops' clock inputs are in the clock tree — while jitter is a temporal variation — the same single clock edge's own timing wobbling cycle to cycle even measured at one fixed point in the circuit. A clock tree with zero skew (every flip-flop's clock input perfectly balanced) can still have significant jitter, because jitter originates in the clock *source* itself (crystal oscillator phase noise, PLL loop noise) or is picked up along the way (power supply noise coupling into clock buffers), not from unequal path lengths.

Jitter is typically categorized by how it's measured: cycle-to-cycle jitter (the variation in period length between two immediately adjacent cycles), period jitter (variation in any single cycle's length relative to the long-term average period), and long-term/phase jitter (accumulated drift over many cycles). Sources include thermal noise and flicker noise inside the oscillator/PLL circuitry, power-supply noise coupling into clock generation and distribution circuits, and crosstalk from adjacent switching signals onto clock traces.

Budgeting jitter into timing margins

Because jitter is statistical, timing budgets typically account for it using a worst-case peak-to-peak figure (or a chosen number of standard deviations of a random-jitter distribution, in high-speed serial link design) subtracted directly from the nominal clock period before doing setup/hold slack calculations — effectively treating the clock period as if it were shorter by the jitter amount, in the worst case. This is conceptually similar to how skew is subtracted from or added to timing margin, but jitter's magnitude isn't a fixed, known offset the way skew often is (after clock-tree balancing) — it must be characterized statistically, typically from oscillator/PLL datasheets or direct measurement, and then treated as a worst-case allowance in the timing budget.

The distinction matters practically: skew can be measured once (for a given clock tree layout) and treated as a fixed design constant for timing closure, while jitter must be treated probabilistically — a jitter budget is usually expressed as 'the clock period will not shrink by more than X picoseconds, with some specified confidence level or guaranteed bound,' which timing tools and high-speed link budgets both need to account for explicitly.

Skew vs jitter, side by side

Skew   → spatial/path difference (between two different points in the clock tree)
Jitter → temporal variation (cycle-to-cycle wobble of a single clock edge over time)

Effective worst-case period ≈ T_nominal − Jitter(peak-to-peak)

Code Examples

In the worst case, a cycle can effectively shrink by the full peak-to-peak jitter amount, leaving only 9.7 ns of guaranteed period for logic and setup/hold checks to fit within, rather than the nominal 10 ns — timing closure must be verified against this reduced, jitter-adjusted period, not the nominal one.

300 ps of peak-to-peak jitter effectively shrinks a 10 ns period to a worst-case 9.7 ns for timing purposes.

Nominal clock period T = 10 ns  (100 MHz)
Peak-to-peak jitter    = 300 ps = 0.3 ns

Effective worst-case period ≈ T - Jitter(pk-pk)
                            = 10 ns - 0.3 ns
                            = 9.7 ns

Important Rules

Skew is a fixed spatial offset between different clock-tree destinations; jitter is a temporal, statistical variation in a single clock edge's own timing.

Jitter originates in the clock source (oscillator/PLL noise) or is picked up along the distribution path (power-supply noise, crosstalk), not from unequal wire lengths.

Timing budgets typically subtract worst-case (or statistically-bounded) peak-to-peak jitter directly from the nominal clock period before checking setup/hold slack.

Unlike skew, jitter cannot be 'balanced away' by clock-tree design — it must be reduced at the source (better oscillator/PLL, cleaner supply) or budgeted for.

Jitter budgets in high-speed serial links

High-speed serial interfaces like PCIe, DDR memory interfaces, and SerDes links live or die on jitter performance: their timing margins are so tight (multi-gigabit-per-second bit periods measured in tens of picoseconds) that jitter is broken down into separate random jitter (RJ, statistical/Gaussian, from noise) and deterministic jitter (DJ, from known, repeatable sources like crosstalk or duty-cycle distortion) components, each budgeted and measured separately via eye-diagram analysis, because exceeding the total jitter budget directly translates into a measurably higher bit-error rate on the link.

Treating jitter as a single, fixed number the way skew is often treated after clock-tree balancing.

Characterize jitter statistically (peak-to-peak, RMS, or a specified confidence bound) and budget for its worst-case impact on every cycle, not just a one-time fixed offset.

Because jitter varies cycle to cycle by nature, a design that only accounts for a single 'typical' jitter value can be caught out by a worse-than-typical cycle; real timing budgets use a guaranteed worst-case (or statistically bounded) jitter figure specifically because any individual cycle could realize that worst case.

Which statement correctly distinguishes clock jitter from clock skew? A. Jitter and skew are two names for the same phenomenon B. Skew is a fixed spatial difference in clock arrival time between different sequential elements; jitter is a temporal, cycle-to-cycle variation in a single clock edge's own timing C. Jitter only occurs in asynchronous circuits; skew only occurs in synchronous circuits D. Skew is caused by oscillator noise; jitter is caused by unequal wire lengths

B. Skew is a fixed spatial difference in clock arrival time between different sequential elements; jitter is a temporal, cycle-to-cycle variation in a single clock edge's own timing — This is precisely the spec's own distinction: skew → spatial/path difference (between two points in the tree); jitter → temporal variation (of one clock edge's timing across cycles). They have different physical origins and require different mitigation strategies — clock-tree balancing for skew, better oscillator/PLL and supply noise control for jitter.

Interview question: why can't clock-tree balancing (the standard fix for skew) also fix jitter? A. Clock-tree balancing actually does fix jitter completely; the two problems are identical B. Jitter originates in the clock source itself (oscillator/PLL noise) or from noise picked up along the path, not from unequal path lengths between destinations — balancing wire lengths does nothing to reduce noise-driven timing variation at the source C. Jitter only matters below 1 MHz, so balancing isn't relevant D. Balancing increases jitter as an unavoidable side effect

B. Jitter originates in the clock source itself (oscillator/PLL noise) or from noise picked up along the path, not from unequal path lengths between destinations — balancing wire lengths does nothing to reduce noise-driven timing variation at the source — Clock-tree balancing equalizes the *path length/delay* to different destinations, which directly addresses skew (a spatial phenomenon). Jitter is a temporal variation rooted in the clock source's own noise characteristics (and noise coupled in along the way) — no amount of balancing physical path lengths changes how much the source's own edge timing wobbles from cycle to cycle, so jitter must be addressed with a cleaner oscillator/PLL and cleaner power supply, not clock-tree topology.

A design's logic path needs 8.5 ns to complete (propagation delay + setup time) at a nominal clock period of 10 ns. If the clock source has 200 ps of peak-to-peak jitter, does the path still meet timing in the worst case? Show the check.

Effective worst-case period = 10 ns − 0.2 ns = 9.8 ns. Since the path needs 8.5 ns and 9.8 ns is available even in the worst-case jittered cycle, the path meets timing with 1.3 ns of margin remaining (9.8 − 8.5). If the jitter were instead 1.6 ns or more, the effective period would drop below the 8.5 ns required and the path would fail timing on its worst-case cycle even though the nominal 10 ns period looked comfortable.

Subtract the peak-to-peak jitter from the nominal period first, then compare against the required 8.5 ns.