Synthesis to gate-level netlist: Visual walkthrough

Prerequisites we lean on lightly (open only if curious): Setup and Hold Time in Flip-Flops, Clock Skew and Uncertainty, Static Timing Analysis (STA), Standard Cell Libraries and .lib Timing Models.

Step 1 — The clock: a heartbeat that says "now!"

WHAT. Every synchronous chip has one shared wire called the clock. It doesn't carry data. It just goes up, down, up, down forever, like a metronome. The moment it jumps from low to high is the rising edge — that is the instant "now, act!"

WHY. Digital circuits need a shared "when". If everyone acted whenever they felt like it, signals would collide. So we pick a single drumbeat and agree: things only happen on the rising edge. The time between two rising edges is one clock period $T$ (measured in nanoseconds, ns).

PICTURE. Look at the square wave. Two rising edges are marked with amber arrows. The gap between them — the amber bracket — is $T$ . Everything we derive lives inside that one gap.

Figure — Synthesis to gate-level netlist

Step 2 — Two flip-flops: the runner and the catcher

WHAT. A flip-flop (FF) is a one-bit memory box that only looks at its input on the rising edge, snapshots it, and holds that value until the next edge. We place two of them in a row:

FF1 = the launcher (the runner who throws the data),
FF2 = the capturer (the catcher who must receive it).

Between them sits a cloud of logic gates (AND/OR/MUX…) — the combinational logic.

WHY. This "FF → logic → FF" sandwich is the atom of every synchronous design. If we can make one such sandwich meet timing, the tool just repeats the rule across millions of them. So we study exactly one.

PICTURE. FF1 on the left, the grey logic cloud in the middle, FF2 on the right. The same clock wire (cyan) feeds both flip-flops — they share the drumbeat.

Step 3 — The data is late leaving: clock-to-Q delay $t_{c q}$

WHAT. When the launch edge arrives, FF1 does not update its output instantly. It takes a small time — the clock-to-Q delay $t_{c q}$ — before the new value actually appears on its output pin (the pin called Q).

WHY. A flip-flop is itself built from transistors that need a moment to switch. The .lib file (see Standard Cell Libraries and .lib Timing Models) lists this delay for every cell. It matters because the runner starts late: the race clock started at the edge, but the data only leaves the gate $t_{c q}$ later.

PICTURE. The timeline starts at the launch edge (left amber line). The green "data valid at FF1 output" marker appears a gap $t_{c q}$ to the right of the edge — that gap is already eaten before any real work happens.

$delay from edge until data leaves FF1 t_{c q}$

Step 4 — Crossing the logic cloud: $t_{l o g i c}$

WHAT. Now the data enters the combinational logic and has to ripple through every gate on its slowest path. That travel time is the logic delay $t_{l o g i c}$ — the sum of the delays of all gates on the longest (worst) route.

WHY. This is the only term synthesis directly controls. By choosing which gates to use (a fast carry-lookahead adder vs a slow ripple adder), how big they are, and how the tree is balanced, the tool changes $t_{l o g i c}$ . Everything else ( $t_{c q}$ , $t_{s u}$ , $t_{u n c}$ , $T$ ) is mostly fixed by the library or the designer. So this term is the tool's lever.

PICTURE. The data marker slides further right by $t_{l o g i c}$ as it crosses the grey gate cloud. We label the path gate-by-gate so you can see the delay accumulating.

$leave FF1 t_{c q} + cross the gates (tool controls this) t_{l o g i c}$

Step 5 — The catcher needs early data: setup time $t_{s u}$

WHAT. FF2 cannot capture data that arrives exactly on the capture edge. It needs the data to be sitting still and stable for a little while before the edge — that required lead time is the setup time $t_{s u}$ .

WHY. Inside FF2 the incoming value must settle through internal transistors before the edge locks it in. If it arrives too late, FF2 can store a half-formed value (a "metastable" glitch). So the real deadline is not the capture edge itself — it is $t_{s u}$ earlier than the edge. The deadline moves left.

PICTURE. The capture edge is the right amber line at position $T$ . A forbidden red zone of width $t_{s u}$ sits just before it. Valid data must arrive at or before the start of that red zone — the effective deadline (dashed cyan line) is at $T - t_{s u}$ .

$deadline = capture edge T - data must be steady this long before the edge t_{s u}$

Step 6 — Reality wobbles the clock: uncertainty $t_{u n c}$

WHAT. We pretended the two edges are exactly $T$ apart and land at the same instant on both flops. In real silicon the clock trembles: it arrives at FF1 and FF2 at slightly different times (skew) and each edge jitters a bit in time (jitter). We lump this wobble into one safety margin: clock uncertainty $t_{u n c}$ .

WHY. If we budgeted zero margin and the capture edge happened to arrive a little early, a path that "just barely passed" would now fail. So we pessimistically shave $t_{u n c}$ off the available time — a guard band that makes the design robust to real clock imperfection.

PICTURE. The deadline from Step 5 slides further left by $t_{u n c}$ (the amber uncertainty band). The true, final deadline is now at $T - t_{s u} - t_{u n c}$ .

$true deadline = T - setup t_{s u} - clock wobble margin t_{u n c}$

Step 7 — Assemble the inequality: does the arrival beat the deadline?

WHAT. Now we simply demand: the moment the data actually arrives at FF2 must be no later than the true deadline.

Arrival time of the data at FF2 = time it left FF1 plus time crossing the logic: $arrival = t_{c q} + t_{l o g i c}$
Deadline = the true deadline from Step 6: $deadline = T - t_{s u} - t_{u n c}$

Require arrival $\leq$ deadline:

$t_{c q} + t_{l o g i c} \leq T - t_{s u} - t_{u n c}$

Move the two right-hand terms across (this is just algebra — add $t_{s u} + t_{u n c}$ to both sides):

WHY. This is the exact instant-by-instant statement that "the data got there in time." Rearranging puts every consumer of time on one side and the total budget $T$ on the other — the form the synthesis tool checks.

PICTURE. One combined timeline: the arrival marker (green) and the deadline marker (cyan) both drawn. As long as green sits left of cyan, the path passes. The leftover gap between them is the slack.

Step 8 — Every case: pass, fail, and the two degenerate limits

WHAT. We must never leave you at a scenario we didn't show. Four cases:

Slack > 0 (pass). Green arrives left of cyan. Example 1 below.
Slack < 0 (fail). Green overshoots past cyan into the red zone. Example 2 below.
Slack = 0 (critical path). Green lands exactly on cyan — no margin, zero spare. Legal but scary; any tiny extra delay tips it into failure. This is the critical path the tool reports.
Degenerate: $t_{l o g i c} = 0$ (two flops back-to-back, no logic between). Even here the constraint isn't free — you still spend $t_{c q} + t_{s u} + t_{u n c}$ . If that sum already exceeds $T$ , the clock is simply too fast for any logic, and the fix is a bigger $T$ (slower clock), not better gates.

WHY. Cases 3 and 4 are the ones people forget. Case 3 is where synthesis spends 90% of its effort. Case 4 proves timing failure can be a clock problem, not a logic problem — a smaller $T$ shrinks the whole budget.

PICTURE. Four stacked mini-timelines, one per case, sharing the same $T$ so you can compare the green arrival against the cyan deadline directly.

The one-picture summary

WHAT. One timeline that stacks all four time-eaters end to end, starting at the launch edge and ending exactly at the capture edge $T$ later — with the leftover shown as slack.

Read it left to right like a relay race: leave the flop → cross the gates → be steady early → keep a safety margin → and all of it must fit inside one clock beat.

Recall Feynman retelling — the whole walkthrough in plain words

There's a drumbeat (the clock). On each beat, a runner (FF1) throws a message to a catcher (FF2) one beat away. But the runner is slow to start — that's $t_{c q}$ . The message then has to run across a field of obstacles (the logic gates) — that's $t_{l o g i c}$ , and it's the only part we can speed up by choosing better obstacles. The catcher is fussy: it needs the message held still a moment before it grabs — that's $t_{s u}$ , so the real finish line is a bit earlier than the beat. And because the drum itself trembles a little, we move the finish line even earlier for safety — that's $t_{u n c}$ . Add up runner-start + running + fussiness + safety; if that total fits inside one drumbeat $T$ , we win, and the spare time is the slack. If it doesn't fit, either pick faster obstacles (shrink $t_{l o g i c}$ ) or slow the drum (bigger $T$ ). That single "does it fit the beat?" question is the entire reason synthesis exists.

Quick self-test

Recall What does each of the four terms physically represent?

$t_{c q}$ ::: delay from the launch edge until FF1's output actually changes. $t_{l o g i c}$ ::: time the signal takes crossing the combinational gates (the term synthesis controls). $t_{s u}$ ::: how long data must be stable before FF2's edge — moves the deadline earlier. $t_{u n c}$ ::: safety margin for clock skew and jitter — moves the deadline earlier still.

Recall If slack is exactly 0, is the path legal?

Yes — it just meets timing with zero margin (the critical path). Any extra delay makes it negative (a violation).

Recall Can a design fail timing even with zero logic between two flops?

Yes — if $t_{c q} + t_{s u} + t_{u n c} > T$ the clock is simply too fast; the fix is a larger $T$ , not better gates.