Before you can write a timing inequality you must know which edge launches the data and which edge captures it. Get this wrong and every number in the report is wrong, even if every delay is right. For the common case (positive-edge flops on one clock) the answer is simple. For half-cycle paths, different clocks and multicycle paths it is the first thing to check.
A flop launches new data at its active clock edge. The capturing flop samples at an active edge, and the tool chooses the closest later capture edge after the launch edge. With both flops on the rising edge of the same clock, that is exactly one period later. The data therefore has one period, adjusted by clock latencies and the flop's own delays, to cross the combinational logic.
Launch edge | Capture edge | Edge relationship (same clock) | Default budget (50% duty) |
|---|---|---|---|
Rising | Rising | One period later | T |
Rising | Falling | Half a period later | T / 2 |
Falling | Rising | Half a period later | T / 2 |
Falling | Falling | One period later | T |
With any other duty cycle the budget is the rising-to-falling (or falling-to-rising) edge difference from the clock waveform; the Waveform and Edge Cases works a 25% duty example.
The same edge relationship sets the hold check. For same-edge paths on one clock the period cancels out of hold, but for half-cycle paths it does not: for rising launch to falling capture (and falling to rising), hold slack = dmin + T/2 - H at 50% duty, where dmin is the minimum data-path delay and H is the hold time. The previous capture edge sits half a period before the launch edge, so the period enters the hold check.
The waveform below is simulation output for a launch flop, a 4 ns combinational delay and a capture flop on a 10 ns clock. Lanes are sampled once per clock half-cycle: even slots show the clock low, odd slots high.
How to read it: launch_q changes in every odd slot, right after a rising edge (slot 1 first, then 3, 5, and so on): that is the launch, one clock-to-Q after the edge. d follows in the next even slot, after the falling edge, because the 4 ns path pushes the change from 1 ns past the rising edge to 5 ns past it. cap_q changes in the odd slot after that (slot 3 first): the capture flop sampled d on the next rising edge, a full period after the launch. The value captured at slot 3 is the one launched at slot 1. The lanes show that the data arrives half a period before it is needed; that spare half period is the setup margin before the setup time is subtracted.
The edge relationship the tool used matches the design intent: a negative-edge flop in a path halves the budget, and the report shows it as a launch and capture edge pair.
Paths between different clocks have a derived relationship (the closest edges of both clocks); if the clocks are unrelated the check is meaningless and needs an exception or a clock group.
Multicycle paths change the capture edge on purpose; they are covered in the constraints section.
Half a period, 4 ns, because the nearest capture edge after the rising launch edge is the falling edge 4 ns later. For this rising-launch-to-falling-capture relationship, hold slack = dmin + T/2 - H at 50% duty, so hold slack = dmin + 4 ns - H: the previous falling capture edge is half a period before the launch edge, so the period enters the hold check.