Two kinds of latency appear in constraints and reports, and they are easy to confuse. Setting the wrong one, or setting network latency on a propagated clock where it is ignored, makes a block look different from how it will behave in the chip.
# not-run: SDC is not executable here
set_clock_latency -source 1.20 [get_clocks sys_clk] ;# delay from the true clock source (e.g. PLL) to the clock port
set_clock_latency 0.50 [get_clocks sys_clk] ;# network latency, used while the clock is idealSource latency | Network latency | |
|---|---|---|
What it models | Delay from the clock origin to the block's clock definition point | Delay from the definition point to the flop clock pins |
Applies to | Ideal and propagated clocks | Ideal clocks only; a propagated clock computes it from the tree |
Typical use | Block-level analysis of a clock that is delayed outside the block | Pre-CTS estimates of the clock tree depth |
# Capture clock arrival at a flop = source latency + network latency
src, net = 1.20, 0.50
arrival = src + net
assert abs(arrival - 1.70) < 1e-9
# Between two blocks, only the DIFFERENCE of total arrivals matters for slack:
launch_total, capture_total = 1.70, 1.85
assert abs((capture_total - launch_total) - 0.15) < 1e-9
print("PASS: clock arrival", arrival, "ns; skew between blocks 0.15 ns")Setting both clocks' latencies lets block-level analysis reproduce the skew the block will see in the chip. If a block's clock is 0.15 ns late relative to its neighbour's, as in the example above, paths between them see that skew; leaving source latency at zero hides it. On a single clock, source latency applies equally to launch and capture and cancels in register-to-register paths; only the difference between clocks matters.
Source latency values come from the top-level clock plan, not guesses, and are consistent with it, so the difference between blocks reproduces the real skew.
Network latency is not set on a propagated clock (it is ignored and misleads readers).
Block-level constraints derived from the top level carry source latency consistently.
Source latency (set_clock_latency -source 0.8), because it is delay before the clock enters the block, which stays valid with propagated clocks.