ExpertQuestion 67 of 69Source: Synopsys PrimeTime User Guide: get_timing_paths and Path Collection Scripting

How do you script a custom timing triage list with get_timing_paths when report_timing only shows one path at a time?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

report_timing (PT) prints a fixed, human-readable report of one or a few paths at a time, which does not scale to triaging hundreds of near-critical paths after a big netlist change. get_timing_paths (PT) instead returns a collection of path objects that a script can filter, sort, and summarize programmatically, which is the tool built for large-scale triage rather than one path at a time.

Technical Reference DiagramHow do you script a custom timing triage list with get_timing_paths when report_timing only shows one path at a time?
A collection of 640 near-critical paths pulled with get_timing_paths -slack_lesser_than 0.05, grouped by shared clock buffer attribute, showing 410 tracing back to one re-buffered clock tree stage.

Technical Explanation

  • report_timing (PT) is designed for reading, with a fixed layout showing arrival and required time build-up for the paths it is given, which works well for confirming one specific path's mechanism.
  • get_timing_paths (PT) returns path objects as a collection, and its options, such as -nworst, -to, and -slack_lesser_than, filter that collection down to the paths worth looking at before any scripting begins.
  • Because the collection holds path objects rather than printed text, a script can pull specific attributes off each path with the -attributes option, for example its slack value or its dominant exception, without parsing report text at all.
  • This matters most after a large change, a new netlist, a re-route, or a derate update, that can shift hundreds of paths near zero slack at once, where reading them one report at a time is not practical.
  • A typical triage script gathers paths within some slack window using -slack_lesser_than, sorts them by endpoint, and groups them by a shared root cause, the same clock buffer, the same aggressor net, the same block, so an engineer fixes one root cause instead of one path at a time.
  • Because the same collection can feed straight into further PrimeTime commands, a script can chain triage and reporting together, for example generating a custom summary table instead of the tool's fixed report layout.
  • A triage script is also easy to re-run after each ECO fix, since it is just another command in the same PrimeTime session, so an engineer can watch the failing-path count shrink cluster by cluster instead of re-reading a fresh set of individual reports each time.

Common Mistake

The Trap: trying to triage hundreds of near-critical paths by running report_timing repeatedly with different path filters, instead of pulling them all into one collection with get_timing_paths and post-processing the data.

  • Manually reading dozens of individual reports to look for a shared root cause is slow and error-prone compared to grouping the same data programmatically.
  • Assuming report_timing's few built-in sorting options, like -nworst or a slack limit, are the full extent of what triage can do undersells what a scripted collection can accomplish.

Follow-up Question & Model Response

If get_timing_paths returns objects instead of printed text, how do you actually inspect what's inside one?

Candidate Model Response: Each path object carries attributes you query directly, using the -attributes option the same way PrimeTime exposes timing path attributes for unconstrained-path debugging, so a script reads a path's slack, startpoint, endpoint, or dominant exception instead of being limited to the tool's built-in report layout. This lets the script decide what to print, summarize, or act on next, whether that is a custom table or a feed into a further ECO step. The tradeoff is that a script has to be written and maintained, so teams tend to build one triage script per project and reuse it across ECO cycles rather than writing report filters from scratch each time.

Practical Example

After a re-route, report_timing -nworst 20 (PT) would only ever show the worst 20 paths by hand, but a triage script using get_timing_paths -slack_lesser_than 0.05 -nworst 5000 (PT) style filtering pulls every path within 50ps of failing across the whole design, around 640 paths that day. Grouping those objects by their shared clock buffer attribute shows that 410 of the 640 trace back to a single clock tree stage that got re-buffered during the route, letting the team fix one buffer sizing issue instead of chasing 640 paths individually, and cutting what would have been days of manual report reading down to one scripted pass and a single targeted ECO.

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 →
VLSI Physical Design Planning Handbook — fourteen chaptersDesign PlanningFourteen chapters, floorplanning through timing budgets. →

Continue practising

Related STA questions

BeginnerWhat is get_timing_paths, and why would you use it instead of report_timing?ExpertWhat options does PrimeTime provide for filtering and reporting specific timing paths (through/from/to, nworst, path tagging), and why would you use path tagging for exhaustive PBA?ExpertWhat does a PrimeTime message about an unconstrained endpoint mean, and how do you find it?AdvancedCompare disabling a path with case analysis, set_disable_timing and set_false_path - mechanism, blast radius, and when each is the right tool.