ExpertQuestion 47 of 69Source: Synopsys PrimeTime User Guide: Reporting Clock Timing

How do you use report_clock_timing to confirm a generated clock's source and network latency were computed correctly after fixing its definition?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

report_clock_timing -type latency (PT) prints, per clock pin, the transition, source latency, network latency, and total latency the tool actually computed, which is the direct way to confirm a generated clock expanded correctly instead of just trusting that the SDC no longer throws an error. A generated clock that traces properly shows a real, non-zero source latency inherited from its master and a network latency consistent with its position in the clock tree; one that still has a tracing problem shows a zero, missing, or clearly wrong latency value even when the SDC itself no longer reports an error.

Technical Reference DiagramHow do you use report_clock_timing to confirm a generated clock's source and network latency were computed correctly after fixing its definition?
report_clock_timing table showing MCLK, MCLK_div2, and MCLK_div4 with monotonically increasing network latency (25.36ns, 27.80ns, 31.42ns) confirming a correctly traced generated clock chain

Technical Explanation

  • report_clock_timing -type latency [-nworst N] (PT) reports, for each clock, the worst N clock pins by some criterion, showing Trans (transition time), Source latency, Network latency, and Total latency in one table.
  • Source latency for a generated clock should reflect the real delay from the design's true clock source through the netlist to the generated clock's own source pin — not zero, unless the design genuinely has no delay there.
  • Network latency should scale sensibly with the generated clock's position in the tree: a divide-by-4 clock two stages downstream of the primary clock should show more network latency than the divide-by-2 stage feeding it, not less and not an identical value.
  • Running this report immediately after fixing a -master_clock chain, as opposed to just re-running check_timing and seeing no error, confirms the fix produced sensible numbers, not merely a silent SDC that happens not to complain.
  • The same report works for merged, multi-scenario runs in distributed analysis, listing a Scen column so latency can be compared scenario by scenario for the same clock pin — useful when a fix needs verifying across every corner, not just one.
  • A generated clock that still traces incorrectly after a fix often shows a Total latency identical to its master's, or a network latency of exactly zero, both of which are strong signs the tool is not actually walking the real logic between the two.
  • What breaks if this check is skipped: an SDC edit that silences an error message can still leave the generated clock's latency wrong in a way that never shows up until a specific path unexpectedly passes or fails signoff, long after the SDC review that "fixed" it.

Common Mistake

The Trap: Treating the disappearance of an unexpanded-clock warning as proof the generated clock is now timed correctly, without checking the actual latency values it produced.

  • A -master_clock chain can be edited into a form that no longer triggers a warning but still traces through the wrong logic, producing a plausible-looking but incorrect latency number.
  • The mistake surfaces only later, when a downstream path's slack changes in a way nobody can explain, because the "fixed" clock was never actually re-verified against expected values.

Follow-up Question & Model Response

"What specific numbers in the report tell me the fix actually worked, versus just quieting the error?"

Candidate Model Response: Compare the generated clock's Source latency against its master's Total latency at the source pin they share — the generated clock's source latency should equal or closely track that value, since it is inherited through the same physical network. Then check that Network latency increases monotonically down the divider chain, since each added stage of real logic should add delay, not reset it. If either number is zero, identical across stages that should differ, or otherwise implausible given the netlist, the -master_clock chain is still wrong even though the SDC no longer errors, and the fix needs another look before signoff trusts it.

Practical Example

After correcting MCLK_div4's master-clock reference to point at MCLK_div2 instead of MCLK, report_clock_timing -type latency -nworst 3 shows MCLK's source pin at 0.11 ns source / 25.36 ns network, MCLK_div2 at 0.11 ns source / 27.80 ns network, and MCLK_div4 at 0.11 ns source / 31.42 ns network — each stage's network latency growing by roughly the real buffer delay added at that stage. Before the fix, MCLK_div4 had shown an identical 25.36 ns network latency to MCLK itself, the giveaway that its master-clock chain was still tracing through the wrong logic.

Complete STA Handbook

Get the complete 10-chapter STA handbook covering setup/hold margins, clock modeling, OCV/POCV, crosstalk noise, and PrimeTime closure.

Explore Complete STA Guide →
Timing Constraints (SDC) Handbook — nine chaptersSDC ConstraintsNine chapters on clocks, exceptions, and constraint linting. →

Continue practising

Related STA questions

ExpertWhy must a cascaded chain of divide-by generated clocks name the previous generated clock as its master, instead of all pointing back at the original clock?ExpertWhat happens if you forget to run set_propagated_clock, and why can an ideal clock network hide a real skew problem?IntermediateHow do you model early and late clock source latency with set_clock_latency?IntermediateWhat does check_timing report, and why must you run it before trusting any slack number?