BeginnerQuestion 17 of 95

What is clock latency, and what's the difference between source latency and network latency?

From PDVerse STA Mentor Guide, part of the pdVerse Mentor Guide

By Tabish Iqbal, who has 9+ years of VLSI Physical Design experience

Short Answer

Clock latency is the total time it takes the clock signal to travel from its true origin to a specific flip-flop's clock pin. The tool splits that total into two pieces: source latency, the delay before the clock even reaches the design's defined clock point, and network latency, the delay from that point through the on-chip clock tree to the flop.

Clock latency split into off-chip source latency before the clock definition point and on-chip network latency through the clock tree afterward — Technical Reference DiagramWhat is clock latency, and what's the difference between source latency and network latency?

Technical Reference DiagramWhat is clock latency, and what's the difference between source latency and network latency?

Technical Explanation

Splitting latency into these two pieces lets the tool model what's known accurately and what's still estimated.

Total latency is the sum: source latency plus network latency equals the full delay from the clock's true origin to any flop's clock pin.
Source latency covers everything before the clock definition point — delay from an off-chip oscillator, or an on-chip PLL's output, up to where create_clock was applied. It's set with set_clock_latency -source (SDC): set_clock_latency 1.5 -source -early [get_clocks CLK].
Source latency cancels out in most internal paths. Launch and capture flops on a reg2reg path share the same clock definition point, so they pick up the same source latency — it drops out of the slack calculation.
Network latency is the clock tree's own on-chip delay. Before the tree is built, it's estimated with a plain set_clock_latency value; once built, set_propagated_clock (PT) switches the tool to the tree's real, measured delays.

Common Mistake

The trap: applying a plain set_clock_latency value (without -source) after the clock tree has already been built and physically propagated.
The command was likely left over from an earlier, pre-layout stage of the flow and simply never removed.
Once set_propagated_clock is active, the tool is meant to use the real clock tree's measured delays for network latency — a leftover manual latency value on top of that either gets flagged by check_timing (PT) as a conflict, or silently overrides the physical tree data with an outdated estimate.

Follow-up Question & Model Response

Does source latency ever actually affect an internal register-to-register path's slack?

Candidate Model Response: No, not when the launch and capture flops share the same clock source — which is the normal case. Both flops see the identical source latency added to their respective arrival and required time, so it cancels out algebraically the moment slack is computed. Source latency only starts to matter for paths crossing to a different clock domain, or for input/output paths where only one side of the check — the port, not an internal flop — is affected by that particular source delay.

Practical Example

A design defines its clock 0.8 ns of network latency (pre-CTS estimate) from the clock port to a typical core flop, with a separate 1.5 ns of off-chip source latency modeling the board delay from the crystal oscillator to that port. Once clock tree synthesis is complete, set_propagated_clock [get_clocks SYS_CLK] replaces that 0.8 ns estimate with the clock tree's real, measured per-flop latency, while the 1.5 ns source latency stays as originally modeled.

Complete STA Handbook