Setup Time, Hold Time & Slack

The setup check, is data early enough?

The setup check makes sure data launched on one clock edge reaches the capture flop and settles before the next edge. Working through one clock period T: the launch flop responds to its edge after its clock-to-Q delay, the signal then takes the combinational logic delay to reach the capture flop's D pin, and it must be stable at least the library setup time before the capture edge. Any clock uncertainty is subtracted as margin. If the data arrives with time to spare, setup passes.

As an inequality, setup is met when: clk→Q + logic delay + setup ≤ T + capture-clock skew - uncertainty. In words, the data path (left side) must fit inside one clock period minus the setup requirement. Setup is a long-path / max-delay check, it is the one that limits how fast the clock can go, so setup is fundamentally about frequency.

Setup slack

Setup slack turns the check into a number: slack = required time - arrival time. The required time is when the data must be there (one period minus setup and uncertainty); the arrival time is when it actually gets there (clk→Q plus logic delay). Positive slack means the path has margin; negative slack means it is too slow and the design cannot run at that frequency. The worst path's slack is the WNS you see in QoR.

Worked example, is this path fast enough?

Numbers make it click. Take one path on a 500 MHz clock (period = 2.00 ns) and add up each side.

ARRIVAL  (when data actually reaches FF2's D pin)
    clock-to-Q of FF1 ......  0.20 ns
    combinational logic ....  1.50 ns
    ---------------------------------
    data arrival time ......  1.70 ns

REQUIRED (when the data must be there)
    clock period ...........  2.00 ns
  - setup time of FF2 ......  0.10 ns
  - clock uncertainty ......  0.05 ns
    ---------------------------------
    data required time .....  1.85 ns

setup slack = required - arrival = 1.85 - 1.70 = +0.15 ns   ->  PASS

The path passes with 0.15 ns to spare. Now change one number, make the logic 1.75 ns instead of 1.50. Arrival becomes 1.95 ns, slack becomes -0.10 ns, and the path fails: the chip can no longer run at 500 MHz until you make that path faster.

From slack to maximum frequency

The same numbers tell you the fastest the clock can go. The minimum clock period is the whole arrival side plus the setup requirement: T(min) = clk→Q + logic + setup + uncertainty = 0.20 + 1.50 + 0.10 + 0.05 = 1.85 ns. So the maximum frequency is 1 / 1.85 ns ≈ 540 MHz. The single slowest register-to-register path in the entire design pins this number, which is exactly why closing the worst path means closing the frequency.

Reading a timing report

Every number above appears in a report_timing print, which walks one path stage by stage. The top block adds up the arrival time, the bottom block adds up the required time, and the difference is the slack:

Startpoint: reg_a  (rising, clk)
Endpoint:   reg_b  (rising, clk)
Path Type : max (setup)

  Point                       Incr    Path
  --------------------------------------------
  clock clk (rise)            0.00    0.00
  reg_a/CK (DFF)              0.00    0.00
  reg_a/Q  (DFF)              0.20    0.20 r   clk->Q
  u1/Z     (BUF)              0.15    0.35 r
  u2/Z     (AND2)             0.28    0.63 r   logic
  u3/Z     (BUF)              0.18    0.81 r
  reg_b/D  (DFF)              0.00    0.81 r
  data arrival time                  0.81

  clock clk (rise)            2.00    2.00
  clock uncertainty          -0.05    1.95
  reg_b/CK (DFF)              0.00    1.95
  library setup time         -0.06    1.89
  data required time                 1.89
  --------------------------------------------
  data required time                 1.89
  data arrival time                 -0.81
  --------------------------------------------
  slack (MET)                        1.08

Read the top block as the data racing down the path: it starts at the launch edge (0.00), adds reg_a's clock-to-Q, then each gate delay, and lands at 0.81 ns when data reaches reg_b's D pin. The bottom block is the deadline: it starts at the capture edge one period later (2.00), subtracts the clock uncertainty and reg_b's setup time, and leaves 1.89 ns. Slack is 1.89 minus 0.81, so +1.08 ns, and MET means it passes. The 'r' marks a rising transition, and scanning the Incr column shows at a glance where the delay is piling up (here the AND2 at 0.28 ns is the heaviest cell). Reading this report fluently is the single most useful STA skill, and it is what most interview questions are really testing.

The hold check, is data late enough?

The hold check is the mirror image, and it catches a subtler failure. When a clock edge captures data, the very same edge also launches new data from the previous flop. If that new data races through a short, fast path and reaches the capture flop's D pin too soon, before the flop has finished latching the old value, it corrupts the capture. Hold requires that new data stay away until a hold time after the edge. Crucially, hold compares launch and capture on the same edge, so it does not involve the clock period at all.

As an inequality, hold is met when: clk→Q + logic delay ≥ hold + uncertainty (+ any skew toward the capture flop). Because the period T never appears, hold violations happen at every frequency, you cannot fix a hold problem by slowing the clock down.

Worked example, is this path late enough?

Hold uses the same edge, so watch the clock period disappear. Take a short path between two flops that sit close together:

ARRIVAL  (when NEW data reaches FF2's D pin)
    clock-to-Q of FF1 ......  0.20 ns
    combinational logic ....  0.08 ns   (short, fast path)
    ---------------------------------
    new data arrival .......  0.28 ns

REQUIRED (how long the old value must be held)
    hold time of FF2 .......  0.15 ns
  + clock uncertainty ......  0.05 ns
    ---------------------------------
    data required to hold ..  0.20 ns

hold slack = arrival - required = 0.28 - 0.20 = +0.08 ns   ->  PASS

New data arrives at 0.28 ns but only has to stay away until 0.20 ns, so hold passes by 0.08 ns. The clock period (2.00 ns) appears nowhere in the maths, that is the proof that a hold-failing path fails at 10 MHz just as it does at 1 GHz, and why the only fix is to add delay to the short path.

Setup and hold pull against each other

Notice the two checks want opposite things. Setup wants the data path fast (arrive early); hold wants it slow (arrive late). That is why fixing one can break the other: speeding a path up to close setup can create a hold violation on the same or a neighbouring path, and adding delay to fix hold eats into setup margin. Clock skew tilts the balance too, positive skew toward the capture flop relaxes setup but tightens hold. Good timing closure holds both in balance.

Fixing setup vs hold violations

The fixes are opposites because the checks are opposites. To fix a setup violation you make data arrive earlier: restructure the logic to cut depth, upsize the critical cells, add buffers to drive heavy loads, borrow time with useful skew, or retime. To fix a hold violation you make data arrive later: insert delay (hold) buffers on the short path. See Timing Closure Techniques for the full playbook.