IntermediateQuestion 6 of 112

What's the difference between clock source latency and clock network latency, and why model them separately before CTS?

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

Source latency is the delay from the clock's true origin — an off-chip pin, or a PLL — to the point in the design where the clock is defined. Network latency is the estimated on-chip delay through the clock tree itself, from that definition point to each register. Both are set with set_clock_latency (SDC) as stand-in numbers before clock tree synthesis has built a real tree to measure.

Clock latency split into off-chip/PLL source latency and on-chip clock tree network latency, both set via set_clock_latency before CTS — Technical Reference DiagramWhat's the difference between clock source latency and clock network latency, and why model them separately before CTS?

Technical Reference DiagramWhat's the difference between clock source latency and clock network latency, and why model them separately before CTS?

Technical Explanation

Source latency covers the part of the clock's journey the design doesn't build. If a clock enters the chip through an input pin, or comes from an on-chip PLL, there is delay between the true origin of that clock edge and the point where create_clock (SDC) defines it. That delay — off-chip trace length, PLL lock and buffering delay — is source latency.
Network latency covers the on-chip tree. From the point the clock is defined, it still has to reach every register through buffers and wiring. Before that tree physically exists, network latency is an estimate of what that delay will be, based on floorplan size and expected buffer count.
Why they're modeled separately. Source latency does not change no matter how large the on-chip clock tree grows — it is fixed by whatever sits upstream of the design. Network latency, in contrast, is exactly what clock tree synthesis is about to build and refine. Keeping them as separate numbers lets the source portion stay stable across CTS iterations while only the network portion updates.
Both use set_clock_latency (SDC). The -source option applies the value to the off-chip/PLL portion; leaving it off applies the value to the network portion. Each can also be split into -early/-late values to model minimum and maximum expected delay before a real tree exists.
They stop being separately meaningful after propagation. Once set_propagated_clock (SDC) is applied to a clock with a real, built network, the tool computes the actual network delay from the physical tree, and only the source latency estimate remains as a user-supplied number layered on top.

Common Mistake

The Trap: Setting one combined clock latency number and calling it source latency.

If the network portion is folded into the source value, that whole number gets treated as fixed and immune to CTS updates, when really only the source part should stay fixed.
Once set_propagated_clock takes over the network estimate, a combined number leaves the source latency wrong — either double-counting the network delay or losing the off-chip delay entirely.

Follow-up Question & Model Response

Why does source latency still matter after set_propagated_clock is applied, if propagation is supposed to compute the real clock delay?

Candidate Model Response: Propagation only computes delay through the network that actually exists inside the design database — it has no visibility into whatever sits upstream of the clock definition point, such as an off-chip PLL or board trace. Source latency has to keep supplying that upstream number even after the on-chip network is propagated, because the tool cannot measure something it was never given a model for. Dropping the source latency value after propagation silently understates the total clock delay by exactly that off-chip amount, which can hide real setup or hold margin loss on paths that depend on it.

Practical Example

A chip receives its core clock from an external oscillator through a board trace and an on-chip PLL, with a combined 2.2 ns source latency (1.4 ns PLL lock/buffer delay plus 0.8 ns board trace). Before CTS, the design team also estimates 0.9 ns of network latency based on the block's expected size: set_clock_latency -source 2.2 [get_clocks CLK] and set_clock_latency 0.9 [get_clocks CLK]. After CTS builds the real tree and set_propagated_clock is applied, the tool replaces the 0.9 ns estimate with a measured 1.05 ns network delay from the actual buffers — but the 2.2 ns source latency stays exactly as configured, since the physical clock tree still can't see past its own definition point.

Complete STA Handbook