Visual walkthrough — Clock skew and jitter

We build strictly from a picture of two flip-flops sharing one clock. If a word or symbol has not been drawn yet, we draw it before using it. See Setup and Hold Time for the raw windows and Flip-Flops for the storage elements themselves.

---

Step 1 — Draw the circuit before any symbol

WHAT. Two flip-flops. The first one, call it FF1, launches data. It sends that data through a lump of combinational logic (any gates — AND, OR, adders) to the second flip-flop, FF2, which captures the data. One clock wire feeds both.

WHY start here. Every timing rule on this page is a statement about "did the data get from FF1 to FF2 in the right window?" You cannot talk about that window until you can point at the two boxes and the wire between them.

PICTURE. The clock (teal) enters a clock tree that branches to both flip-flops. Notice the two branches are drawn with different lengths — that difference is the whole story of skew, coming in Step 4.

---

Step 2 — Lay down the ideal timeline

WHAT. Draw a horizontal time axis. Put FF1's clock edge at $t=0$. Put FF2's next edge at $t=T$, where $T$ is the clock period (one full tick-to-tick interval).

WHY. Timing is a race between time available and time consumed. A timeline turns "does it fit?" into "is this arrow shorter than that gap?" — something a 12-year-old can literally measure with a ruler.

PICTURE. Two teal ticks: one at $0$, one at $T$. The gap between them is the entire budget we are allowed to spend.

$\underset{\text{time available (one period)}}{\underbrace{T}}$

Here $T$ is the only "gift" of time we get per cycle. Everything else on this page either eats into it or gives a little back.

---

Step 3 — Grow the data-arrival arrow (setup, no skew yet)

WHAT. After FF1's edge at $t=0$, data appears at FF1's output after $t_{cq}$, then crawls through the logic taking $t_{logic}$. So the data lands at FF2's input at time $t_{data}=\underset{\text{FF1 wakes up}}{\underbrace{t_{cq}}}+\underset{\text{travels through gates}}{\underbrace{t_{logic}}}.$ FF2 will sample at $t=T$, but it needs the data frozen for $t_{su}$ before that. So the data must arrive by $T-t_{su}$.

WHY this comparison. A flip-flop that samples changing data can land in a forbidden half-state — see Metastability. The setup window $t_{su}$ is exactly the safety cushion that forbids that. So the rule is "arrive early enough to be frozen through the cushion."

PICTURE. A plum arrow of length $t_{cq}+t_{logic}$ grows from $0$. A hatched setup band of width $t_{su}$ sits just left of the $T$ tick. The arrow tip must not poke into that band.

The requirement, read straight off the picture: $\underset{\text{data arrival}}{\underbrace{t_{cq}+t_{logic}}}+\underset{\text{freeze cushion}}{\underbrace{t_{su}}}\le \underset{\text{available}}{\underbrace{T}}.$

---

Step 4 — Slide FF2's edge: enter clock SKEW

WHAT. The two clock-tree branches from Step 1 are not equal, so FF2's edge does not land exactly at $T$. Define $t_{skew}=t_{clk\to FF2}-t_{clk\to FF1}.$ If this is positive, FF2's capturing edge arrives later, at $T+t_{skew}$.

WHY it appears now. Skew is spatial — it is the same edge seen at two places. It is deterministic (a fixed offset), because wire length does not change tick to tick. See Clock Distribution Network for where it physically comes from.

PICTURE. Slide the right teal tick from $T$ to $T+t_{skew}$ (orange shift arrow). The available gap grows — positive skew hands the setup path extra time.

Replace $T$ with $T+t_{skew}$: $t_{cq}+t_{logic}+t_{su}\le \underset{\text{late edge = more room}}{\underbrace{T+t_{skew}}}.$

---

Step 5 — Shake the edge: enter clock JITTER

WHAT. PLL noise, supply noise and thermal noise make each edge land a little early or late randomly, by up to $t_{jitter}$. Unlike skew, it has no fixed direction — so for a guarantee we assume the worst.

WHY worst-case. Skew we can measure and lean on. Jitter is random, so when we ask "will it always work?" we must take the direction that hurts. For setup, the harmful direction is the capture edge arriving earlier (less time), so it subtracts from the gap.

PICTURE. A fuzzy plum cloud of width $t_{jitter}$ around the capture tick. The left (early) edge of the cloud is the one that bites the setup budget.

$\boxed{t_{cq}+t_{logic,max}+t_{su}+\underset{\text{edge may come early}}{\underbrace{t_{jitter}}}\le T+t_{skew}}$

We use $t_{logic,max}$ (the slowest logic path) because setup is a worst-case-slow question. Rearranged, this is exactly the parent's max-frequency formula: $T_{min}=t_{cq}+t_{logic,max}+t_{su}+t_{jitter}-t_{skew}.$

---

Step 6 — The OTHER race: HOLD on the same edge

WHAT. Hold is a different race. It is not about the next edge — it is about the very same edge at $t=0$ launching new data that arrives at FF2 too fast and clobbers what FF2 is still capturing.

FF2's own edge (same edge, skewed) is at $t_{skew}$. The new, fastest data arrives at $t_{cq}+t_{logic,min}$. It must arrive after FF2's hold window $t_h$ closes: $t_{cq}+t_{logic,min}\ge \underset{\text{window stays shut until here}}{\underbrace{t_{skew}+t_h}}.$

WHY $t_{logic,min}$ now. Hold is a worst-case-fast question — the danger is data being too early, so we use the shortest logic path. Notice there is no $T$ here: both events live inside one cycle. That is why slowing the clock cannot save a hold violation.

PICTURE. Zoom onto $t\approx 0$. FF2's edge sits at $t_{skew}$. A short plum arrow (fast data, length $t_{cq}+t_{logic,min}$) must land to the right of the hold band $t_h$.

Now add jitter — for hold, the harmful direction is the capture edge arriving later (window stays open longer), so jitter adds to the right side: $\boxed{t_{cq}+t_{logic,min}\ge t_{skew}+t_h+t_{jitter}}$

---

The one-picture summary

WHAT. One timeline holds both races at once: the setup race stretching toward $T+t_{skew}$ on the right, and the hold race crammed near $t=0$ on the left. The clock uncertainty (skew shift + jitter cloud) squeezes both.

Recall Feynman: the whole walkthrough in plain words

Picture two runners with a baton. A whistle at $t=0$ tells the first runner to go; she takes a moment to react ($t_{cq}$), then jogs across a field ($t_{logic}$) to hand the baton to the second runner. The second runner grabs it on the next whistle, at $T$ — but only if the baton is steady in his hands for a moment first ($t_{su}$). That's setup. Now, the finish-line whistle doesn't ring at the same instant for both runners, because the sound travels different distances — that's skew, and if the second runner hears it late he gets more time to receive the baton. But the whistle-blower's hand also shakes randomly each time — that's jitter, and since it's random we always assume it makes things worse. There's a second danger: the same whistle that starts runner one could send a baton flying at runner two while he's still catching the previous one. If it comes too fast, he fumbles. That's hold, and no matter how much you s-l-o-w the whistle down between rounds, it never helps — the collision happens in one round, before the next whistle. To fix hold you make the fast path longer, not the clock slower.

---

Connections

• ↑ Parent: Clock skew and jitter
• Setup and Hold Time — the two windows every step measures against.
• Flip-Flops — FF1 and FF2 in every figure.
• Clock Distribution Network — why the two clock branches differ (skew).
• Phase Locked Loop (PLL) — where jitter is born.
• Maximum Clock Frequency — the setup constraint, solved for $f$.
• Static Timing Analysis — where these inequalities get checked automatically.
• Metastability — what a violated window actually does to a flip-flop.