BeginnerQuestion 89 of 95Source: Synopsys PrimeTime User Guide: Command Line Interface and Scripting

What is get_timing_paths, and why would you use it instead of report_timing?

From PDVerse STA Mentor Guide · pdVerse Mentor Guide

By Tabish Iqbal · 9+ Years VLSI Physical Design Experience

Short Answer

get_timing_paths (PT) returns a Tcl collection of path objects that a script can loop over, filter, or measure, instead of printing a formatted report to the screen. report_timing (PT) is built for a person to read; get_timing_paths is built for a script to process, which matters once you need to check hundreds of paths automatically rather than read them one at a time.

A flowchart: get_timing_paths returning a Tcl list of path objects, feeding into a script loop that checks each object's slack attribute and logs a pass/fail count. — Technical Reference DiagramWhat is get_timing_paths, and why would you use it instead of report_timing?

Technical Explanation

Both commands find the same paths under the hood, but they hand the result to different consumers.

report_timing (PT) formats its result as text for a terminal or log file, meant to be read directly.
get_timing_paths (PT) instead returns path objects into a Tcl variable, which a script can then query for slack, startpoint, endpoint, or any other path attribute without re-parsing text.
This matters for automation: a signoff script that needs to count how many paths fail by more than a threshold can loop over a get_timing_paths result far more reliably than parsing report_timing's printed text.
Both commands accept similar filtering options, such as -max_paths and -slack_lesser_than, since they share the same underlying path search.
A beginner writing a one-off manual check almost always wants report_timing; a beginner writing a script that runs the same check on every regression build wants get_timing_paths.
Because it avoids formatting overhead, get_timing_paths is also the command PrimeTime's own multicore analysis speeds up for very large path searches.

Common Mistake

The Trap: writing a script that runs report_timing and text-parses its printed output to extract slack values.

Report formatting can change between PrimeTime versions, silently breaking a text-parsing script that worked before.
get_timing_paths avoids this entirely by returning structured data meant for scripts, not display text.

Follow-up Question & Model Response

Once a script has a collection of path objects from get_timing_paths, how does it actually read a value like slack out of one of them?

Candidate Model Response: The script queries path attributes with a command like get_attribute (PT) on each path object returned by get_timing_paths, asking for the slack attribute directly rather than scanning any text. This keeps the whole check inside Tcl data structures from start to finish, with no report text involved at any step. The same pattern works for other attributes such as startpoint, endpoint, or path group, which is why scripted regression checks are built on get_timing_paths rather than on parsing report_timing output. This separation is also what makes the check portable across PrimeTime versions, since attribute names are more stable than report formatting.

Practical Example

A nightly regression script runs set worst [get_timing_paths -max_paths 5 -slack_lesser_than 0] (PT) after every build, then checks whether the count of returned paths grew compared to the previous night — flagging a regression automatically without anyone reading a single printed report.

Complete STA Handbook