How do you use report_clock_timing to debug a clock network that looks wrong in report_timing?

Short Answer

report_clock_timing (PT) shows how a single clock propagates through its entire network -- every buffer and inverter from source to every endpoint -- separately from any one data path, which is what lets a designer isolate whether an odd number in a report_timing (PT) path report comes from the data logic or from the clock tree itself. Where report_timing shows one path's clock arrival as a single number buried inside a larger report, report_clock_timing shows the whole clock's latency and skew profile across all its endpoints at once.

Technical Explanation

A report_timing (PT) path report only shows the clock arcs relevant to one startpoint-endpoint pair, so an unusual clock latency on that path is visible but not easy to compare against how the same clock behaves elsewhere in the design.

• report_clock_timing (PT) instead reports the selected clock's full propagation -- insertion delay, latency, and skew -- across every register the clock reaches, giving a design-wide view instead of a single-path view.
• This design-wide view is what makes it possible to tell whether a suspicious clock arrival on one path is a local anomaly -- a single mis-sized buffer on that branch -- or a global property of the clock, such as a source latency assumption affecting every endpoint equally.
• Because the command reports the clock network on its own terms, it works whether the clock is currently modeled as ideal or propagated, which matters when debugging why a path's clock arrival changed after set_propagated_clock (SDC) was applied post-CTS.
• Comparing report_clock_timing output before and after a clock-tree change -- a CTS re-run, a buffer swap -- isolates the clock network's contribution to a slack shift from any change in the data path, which a single report_timing path report cannot do by itself since it only shows one snapshot.
• A skew outlier found this way -- one branch of the clock tree arriving noticeably later or earlier than its siblings -- points the designer toward a specific clock-tree buffer or route to investigate, rather than toward the data-path cells a report_timing report would otherwise seem to implicate.

Follow-up Question & Model Response

If report_clock_timing shows every endpoint the clock reaches, how does a designer narrow that down to the specific branch causing an outlier?

Candidate Model Response: The report can be filtered to a subset of endpoints or sorted by latency, so the designer looks for the cluster where most endpoints' latency groups together against the one or few outliers sitting noticeably apart from that cluster. Once an outlier endpoint is identified, tracing its clock path back toward the source -- the same expansion report_timing -path_type full_clock_expanded (PT) shows for a single path -- usually finds the specific buffer or branch point where the outlier's latency diverges from its siblings. This narrowing works because a clock tree is built as a branching structure, so an anomaly typically enters at one shared ancestor point and then propagates to every descendant below it, making the divergence point identifiable rather than random. Cross-referencing that branch point against the CTS tool's own buffer list usually confirms whether it was an intentional balancing choice or a genuine tree construction issue.