Clock skew and jitter: Question bank — Hardware deep dive

Symbols used on this page (read first)

Every trap below assumes the timing model of a launch flip-flop → combinational logic → capture flip-flop chain, both clocked by the "same" clock. Here is every symbol, in plain words, before you meet it in a question.

Definition The timing symbols

$T$ — the clock period: the nominal time between two successive clock ticks. Higher frequency means smaller $T$ .
$t_{c q}$ — clock-to-Q delay: after the launch flip-flop sees its edge, how long until its output $Q$ actually changes.
$t_{l o g i c, ma x}$ — the slowest (longest) delay through the combinational logic between the two flip-flops. This is the path that limits setup / frequency.
$t_{l o g i c, min}$ — the fastest (shortest) delay through that same logic. This is the path that endangers hold.
$t_{s u}$ — setup time: how long data must be stable before the capture edge for the capture flip-flop to store it reliably.
$t_{h}$ — hold time: how long data must stay stable after the capture edge.
$t_{s k e w}$ — clock skew: the fixed, spatial difference in when the two flip-flops see the same edge (defined more carefully just below).
$t_{j i tt er}$ — clock jitter: the random, cycle-to-cycle wobble of an edge from its ideal time at one node.

True or false — justify

Positive clock skew always improves your maximum frequency.

False — it helps setup (the late capture edge borrows time) but hurts hold. If the hold path was already marginal, "useful skew" can push you into a hold violation you cannot clock your way out of.

Jitter can be treated like a positive skew that happens to help setup.

False — skew has a fixed sign, so it can consistently help. Jitter is random, so timing analysis assumes the worst-case direction, which always shrinks margin for both setup and hold.

Slowing the clock (raising

T

) can rescue a failing setup path.

True — setup is

t_{c q} + t_{l o g i c, ma x} + t_{s u} + t_{j i tt er} \leq T + t_{s k e w}

; increasing

T

enlarges the right side, so more period always relaxes setup.

Slowing the clock can rescue a failing hold path.

False — the hold inequality

t_{c q} + t_{l o g i c, min} \geq t_{s k e w} + t_{h} + t_{j i tt er}

contains no

T

. Hold is an edge-vs-edge race on the same cycle, so period is irrelevant.

Clock skew is a random quantity you can only model statistically.

False — skew is spatial and deterministic: it comes from fixed differences in clock-tree path length, buffer count, and load, so it is a repeatable offset. Jitter is the random one.

Two flip-flops with identical clock-tree paths have zero skew but can still have jitter.

True — equal paths cancel the spatial (skew) term, but both flops still ride the same oscillator/PLL, whose edges wander cycle-to-cycle, so jitter remains.

If both setup and hold pass at nominal values, adding a little jitter is always safe.

False — jitter eats margin on both sides simultaneously. A path passing setup and hold by tiny margins can fail one (or both) once realistic jitter is folded in.

Negative skew (capture clock arrives early) helps hold.

True — an earlier capture edge means FF2 finishes latching sooner, so fast new data is less likely to overrun the hold window; but that same early edge hurts setup.

Jitter and skew add into the same term in the setup equation.

False — jitter adds to the required time (left, or reduces effective

T

) while skew adds to the available time (right, with

t_{s k e w}

). They sit on opposite sides and have opposite effects on setup.

Spot the error

"Hold violation? Just drop the clock frequency until it passes."

The error: hold has no

T

term. The real fix is to add delay to the data path (buffers, longer route) so

t_{l o g i c, min}

grows, or to reduce skew.

"We measured skew of +0.2 ns, so we gained 0.2 ns of setup margin — free speed."

Only half true, and dangerous. You did gain setup margin, but you lost 0.2 ns of hold margin. Booking the gain without checking hold is how "free speed" becomes silicon that fails.

"Jitter is 0.05 ns, so I'll subtract it from the period like I subtract skew."

Wrong sign logic. Jitter worsens both constraints, so for setup it is added to the delay side (padding the period), never subtracted. Only a helpful positive skew gets subtracted from

T_{min}

"Setup and hold both fail — must be one root cause, fix it once."

Likely two independent problems. Setup fails when the slow path (

t_{l o g i c, ma x}

) is too slow relative to

T

; hold fails when the fast path (

t_{l o g i c, min}

) is too fast relative to the edge race. They pull in opposite directions and usually need separate fixes.

"Increasing

t_{l o g i c, min}

fixes setup."

No — adding minimum-path delay only helps hold. Setup depends on

t_{l o g i c, ma x}

; padding the fast path does nothing for the slow path that limits frequency.

"Since skew is deterministic, static timing analysis can ignore it."

Backwards. Deterministic means STA can and must model it precisely as a fixed offset per path — that determinism is exactly why it is included, not excluded.

Why questions

Why does positive skew help setup but hurt hold, using the same physical edge?

For setup, the late edge is the next cycle's capture edge — later means more time for slow data. For hold, the relevant edge is the current cycle's capture edge — later means FF2 is still latching when fast new data arrives, corrupting it.

Why is hold independent of clock period

T

Hold compares the new data (launched at the current edge) against that same current capture edge. Both events live in one clock cycle, so the spacing between cycles (

T

) never enters the race.

Why must timing analysis assume jitter acts against you rather than averaging out?

A single edge can arrive early or late, and either extreme can violate a constraint. Averaging would hide the failing tail; robust design must survive the worst realizable edge, so worst-case jitter is applied to whichever side it damages.

Why does the maximum-frequency formula subtract skew but add jitter?

A helpful positive skew genuinely lends the setup path extra time, shrinking the required period, so it subtracts. Jitter only ever removes usable time, so it must pad the period, adding to

T_{min}

Why can a design meet setup and hold on paper yet still fail in the lab?

On-paper checks may use nominal or optimistic uncertainty. Real supply noise, temperature, and PLL wander produce larger jitter, and clock-tree variation shifts skew, eroding the thin margins the paper analysis assumed.

Why is the clock distribution network the source of skew but the PLL the source of jitter?

The distribution network's unequal wire lengths and buffers create fixed spatial arrival differences (skew). The PLL/oscillator generates the edges themselves with noise that varies edge-to-edge (jitter).

Why does inserting buffers fix hold but risk breaking setup?

Buffers raise the minimum path delay, satisfying hold. But if placed on a path that is also near its setup limit, they also raise

t_{l o g i c, ma x}

, potentially violating setup — so placement must target the fast-but-not-slow path.

Edge cases

What happens to the setup and hold equations when skew is exactly zero?

Setup becomes

t_{c q} + t_{l o g i c, ma x} + t_{s u} + t_{j i tt er} \leq T

and hold becomes

t_{c q} + t_{l o g i c, min} \geq t_{h} + t_{j i tt er}

— the "clean" textbook forms. Jitter still hurts both; only the spatial term vanishes.

What if jitter is zero but skew is large and positive?

Setup gains room (subtract full skew), but hold shrinks by the full skew and may fail. This is the classic "useful skew went too far" scenario.

What if the two flip-flops share literally the same clock pin?

Skew between them is zero (same node), so only jitter matters. This is why local, tightly coupled register pairs are hold-robust but still period-limited by jitter and logic delay.

What is the degenerate case with zero combinational logic between FF1 and FF2 (

t_{l o g i c} \approx 0

Setup is easily met (almost the whole period is free), but hold is at maximum risk: data races through with only

t_{c q}

, so any positive skew or jitter can drive

t_{c q} \geq t_{s k e w} + t_{h} + t_{j i tt er}

to fail. Directly-connected flops are the textbook hold-violation case.

What happens as jitter grows toward the size of the whole timing margin?

Effective usable period collapses; both constraints tighten until one violates. Beyond that point no fixed frequency is safe — the fix is a cleaner clock source (better PLL), not more logic tuning.

At the exact boundary where a constraint holds with equality, is the design safe?

Marginally — equality means zero slack. Any real-world variation (temperature, voltage, a hair more jitter) pushes it into violation, so zero-slack paths are treated as failing in practice.

What if skew is negative and jitter large — which constraint dominates?

Negative skew hurts setup (subtracts available time) while jitter hurts setup too, so setup is doubly squeezed and becomes the binding constraint; hold, meanwhile, is comfortably helped by the early edge.

Recall One-line self-test before you leave

Say it without looking: skew is spatial & deterministic, jitter is temporal & random; positive skew helps setup, hurts hold; hold has ==no $T$ term so you fix it with data-path delay==, never by slowing the clock.

Connections

Setup and Hold Time — the windows every trap above erodes.
Static Timing Analysis — where these constraints are formally checked.
Maximum Clock Frequency — what jitter and negative skew push down.
Clock Distribution Network — physical origin of skew.
Phase Locked Loop (PLL) — physical origin of jitter.
Metastability — the failure mode when setup/hold lose.
Flip-Flops — the elements being clocked.