Visual walkthrough — Critical path identification
We are going to answer one question: how fast can we tick the clock before a bit gets dropped?
Step 0 — The cast of characters (before any symbols)
WHAT. A synchronous circuit is a chain of little memory boxes called flip-flops (FFs) with a lump of combinational logic (plain gates, no memory) between them. A shared clock wire ticks up-down-up-down, and every FF grabs a new value on the same kind of tick — the rising edge (the moment the clock jumps from low to high).
WHY start here. Every term we define later is a duration measured on this picture. If you can't see the two FFs and the logic between them, the algebra is just letters.
PICTURE. Look at the figure: on the left the launch FF (lavender) holds a bit. It hands it to the combinational cloud (mint). The result lands at the capture FF (coral) on the right. One clock wire feeds both.

See Synchronous Design Flow for why the whole chip shares one clock, and Setup and Hold Time for the box behaviour we lean on next.
Step 1 — Drawing time as a ruler, and marking the two edges
WHAT. Draw a horizontal time axis (a ruler). Mark two rising edges of the clock: the first at time , the next one exactly one period later. Call that gap ==== (the clock period, in nanoseconds).
WHY this tool — a number line for time. We want to compare how long things take against how much time we have. The only honest way is to lay every event on one shared ruler. is the total budget the whole race must fit inside.
PICTURE. Two tall vertical ticks. The distance between them, labelled , is our entire budget.
- — the period. Bigger = slower clock = easier to meet. Smaller = faster clock = harder.

Step 2 — The launch FF is not instant:
WHAT. At the first edge (time ) the launch FF decides to output its new bit — but it takes a small delay before that bit actually appears at its output pin (called Q). That delay is ==== ("clock-to-Q").
WHY it matters. The data does not leave at time ; it leaves at time . We just spent part of our budget before the logic even starts. Ignoring it would make us think we have more time than we do.
PICTURE. A short mint arrow starting at the first tick and ending a little to the right — the data only becomes available at the tip of that arrow.
- — clock-to-Q delay: the head-start the clock edge needs before Q is valid. Related to a gate's propagation delay.

Step 3 — The logic eats time:
WHAT. Now the bit travels through the gate cloud. Each gate has its own propagation delay; add them along the route the bit takes. The sum along one route is that route's ====.
WHY sum, and why "along a route". A gate can't produce its answer until its inputs are ready and it has physically switched. Those delays stack head-to-tail like a relay baton being handed on. Different routes through the cloud have different sums — that is the seed of the critical path.
PICTURE. A long coral bar stacked after the bar. Notice two candidate routes drawn faintly: a short one and a long one. Only the longest matters, and we'll see why in Step 6.
- — total gate delay along one path through the cloud.
- The running total is where on the ruler the bit reaches the capture FF's input pin (D).

Step 4 — The capture FF has a curfew: setup time
WHAT. The capture FF cannot have data changing at the very last instant. It demands the bit be steady and settled for a little while before the next edge. That required quiet window is ==== (setup time).
WHY a deadline before the deadline. Inside the FF a tiny sampling circuit needs the input to stop wobbling so it can latch cleanly. If the bit is still moving inside the setup window, the FF can go into a confused half-state (metastability). So the real deadline is not the second edge — it is earlier.
PICTURE. A butter-coloured "no-fly zone" of width painted just before the second tick. Data must arrive at or before the left edge of that zone.
- — the settle-quietly window the capture FF insists on.
- — the moment the data must already be there.

Step 5 — Snapping the pieces together: the inequality
WHAT. Line up the three durations on the ruler: start at , spend , then , arriving at . This arrival must land before the curfew .
WHY — it's just "does it fit?". Time used by the data must not exceed time available before the curfew.
PICTURE. All three bars laid end to end. If their combined length pokes past the butter zone's left edge, that's a violation (red). If it stops short, there's leftover room (green gap).
Move to the left to get the clean form the parent note states:
- Left side = time used (three real delays stacked up).
- Right side = time available (one period).
- — "fits inside". Equality means just barely.

Step 6 — Why only the slowest route counts
WHAT. The cloud has many routes. Every route must satisfy . The single largest is the hardest to satisfy — so it decides the minimum legal .
WHY the max, not the sum or the average. Picture runners leaving the same gun. You can't fire the next gun until the last runner is in — the slow one alone sets the tempo, and the fast routes just wait. That "wait for the last" is precisely the max operation Static Timing Analysis (STA) uses at every gate.
PICTURE. Three routes drawn as parallel bars. Only the longest (coral) touches the deadline; solve for using that one.
- — the delay of the critical path (the slowest route).
- — the top clock speed; one over the tightest period.

Step 7 — The edge cases (never leave a scenario unshown)
WHAT & WHY. Real numbers can be zero, negative, or shifted. Each needs its own picture so no reader hits an unexplained case.
Case A — clock skew helps. If the capture clock edge arrives later than the launch edge, the curfew slides right — more budget. The inequality gains a term:
- — extra time granted because the capture deadline moved later. See Clock Skew and Jitter.
Case B — slack, the leftover. Rearranged, the gap between deadline and arrival is the setup slack: Positive = green gap (passes). Zero = touches the line. Negative = a red overshoot = timing failure.
Case C — degenerate: . Two FFs wired directly (no gates). Then the constraint is just — the fastest a design can ever go. You cannot beat this floor.
Case D — over-fast clock: too small. Shrink until arrival pokes past the curfew → slack goes negative → dropped bit. This is why exists at all.
PICTURE. Four mini-timelines: skew-shifted deadline, a green-slack case, a zero-logic floor, and a negative-slack violation in red.

The one-picture summary
Everything above, on one ruler: budget across the top; three stacked bars (head-start , travel , curfew ); the leftover green slack; and the dashed rightward nudge that skew would add. If the bars fit → circuit runs at . If they spill → slow the clock or shorten the path (Pipelining).

Recall Feynman retelling — the whole walkthrough in plain words
A bit is a runner. The gun fires (clock edge) but the runner needs a moment to react () before actually running. Then it runs through a maze of gates, and its time is however long its route takes (). It must reach the finish gate and stand still for a beat before the next gun (). The next gun is one period away. So: react + run + stand-still must all fit inside . Many routes exist; the slowest runner sets how long we must wait between guns — that's the critical path. Any spare time is slack; a delayed finish-line clock (skew) gives a little extra; run the guns too fast and the slow runner is still mid-maze when it fires, dropping the baton. To go faster: faster gates, or cut the long route in half with an extra gate-in-the-middle (a pipeline register).
Recall
The minimum legal period is ::: Setup slack equals ::: The critical path is chosen by ::: the largest (worst/minimum slack), not gate count At a multi-input gate the arrival time is ::: max(input arrivals) + gate delay