AdvancedQuestion 13 of 63

How do generated clocks interact with source latency, and how does edge-specific source latency propagation work?

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

A generated clock's source latency is inherited from its master, not specified independently - it is the master clock's insertion delay from its origin down to the generated clock's source pin. PrimeTime computes it automatically when the master is propagated, and tracks it separately per edge because a clock network's rise and fall delays are not always equal.

Waveform diagram showing a master clock with different rising-edge and falling-edge network latencies, and a divide-by-2 generated clock inheriting each edge-specific latency value separately rather than an averaged one — Technical Reference DiagramHow do generated clocks interact with source latency, and how does edge-specific source latency propagation work?

Technical Reference DiagramHow do generated clocks interact with source latency, and how does edge-specific source latency propagation work?

Technical Explanation

Source latency is inherited, not independent. A generated clock's source latency is the latency from the master clock's origin down to the generated clock's source pin - in other words, the master's insertion delay up to the point where the generated clock is derived.
When the master is propagated, PrimeTime computes it automatically. create_generated_clock (SDC) ties the generated clock to a master; if that master has set_propagated_clock (SDC) active, its real latency is propagated forward to the generated clock's source pin, so the generated clock inherits the correct upstream insertion delay without it being specified separately.
When the master is ideal, you supply it. With no real latency to propagate, the generated clock's source latency comes from an explicit set_clock_latency (SDC) or from the master's own specified latency, as applicable.
Why edge-specific propagation exists. A clock network's rise and fall delays through cells and nets are not always symmetric, so the master's rising edge, falling edge, and their early/late values may not all reach the source pin with the same delay.
How the generation relationship determines which edges matter. A generated clock is derived from specific master edges through its divide, multiply, or -edges relationship, so which master edges it is built from determines which of the master's edge-specific latencies it inherits.
The result. PrimeTime tracks source latency per edge of the generated clock and propagates the master's edge-specific latencies through the generation relationship, instead of collapsing everything into one averaged latency number - which is what keeps generated-clock timing accurate where the master's rise/fall latency asymmetry is significant.

Common Mistake

Assuming a generated clock's source latency needs to be set explicitly even when the master is already propagated, duplicating a value PrimeTime already computes automatically.
Treating rise and fall source latency as interchangeable, when a clock network's asymmetric rise/fall delays mean the generated clock's edges genuinely inherit different latency values.
Cost: a manually specified source latency that conflicts with the automatically propagated value, producing a generated-clock timing report that doesn't match the master's real, edge-specific insertion delay.

Follow-up Question & Model Response

If a master clock's rising-edge network latency is 80ps and its falling-edge network latency is 95ps, what happens to a generated clock created with -divide_by 2, and why does the 15ps difference matter?

Candidate Model Response: A divide-by-2 generated clock is built from alternating master edges, so which of the master's rising or falling edge latencies feeds into the generated clock's own edges depends on the specific edge relationship the divide creates. Because PrimeTime tracks source latency per edge rather than as one averaged number, the generated clock's edges genuinely inherit the master's 80ps and 95ps values according to which master edge produced them, rather than an averaged 87.5ps. The 15ps difference matters because it directly affects the generated clock's own duty cycle and edge placement relative to the rest of the design, and averaging it away would introduce a real inaccuracy into every path that clock times.

Practical Example

A propagated master clock has a rising-edge network latency of 120ps and a falling-edge network latency of 138ps, an 18ps asymmetry from unbalanced buffer sizing in the clock tree. A generated clock created with create_generated_clock -divide_by 2 -source [get_pins master_buf/Z] inherits these values edge-by-edge rather than as one averaged 129ps figure. report_clock_timing (PT) on the generated clock's network displays the two distinct source-latency values, letting a downstream setup check on that domain use the correct 138ps figure for its capture edge rather than an averaged number that would understate the real risk by 9ps.

Complete STA Handbook