What 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?
From PDVerse STA Mentor Guide · pdVerse Mentor Guide
Technical Explanation
report_timing offers extensive filtering to scope exactly which paths get reported — including multiple -through lists, -input_pins, -max_paths N, -slack_lesser_than, and path-based analysis mode selection — while path tagging lets you mark alreadyanalyzed paths so successive exhaustive PBA runs don't redundantly re-analyze them.
Timing-path Reasoning
report_timing's -through option can be specified multiple times to chain a path through several intermediate points, -max_paths N caps how many paths are reported, slack_lesser_than filters to only paths worse than a given slack threshold, and pba_mode {path|exhaustive|ml_exhaustive} selects which path-based analysis mode computes the reported delays. For exhaustive PBA, which is more computationally expensive than graph-based analysis, path tagging (enable_path_tagging, create_path_tag_set, report_path_tag_set, get_path_count_for_tag, remove_path_tag_set) lets you mark a set of paths that have already been analyzed under a tag, so subsequent exhaustive PBA passes on successively-worse path sets can skip re-analyzing the tagged ones, saving runtime while still converging on the true worst-case set.
Command
report_timing -input_pins -max_paths N -slack_lesser_than -through [through ...] -nosplit -pba_mode {path|exhaustive|ml_exhaustive} significant_digits -attributes {list} -exclude {tag1 tag2}; set_app_var
enable_path_tagging true; create_path_tag_set; report_path_tag_set -name
tag1; get_path_count_for_tag -name tag1; remove_path_tag_set -name tag1Switch-by-switch
-input_pins reports delays at input pins along the path. -max_paths N limits the number
of paths returned. -slack_lesser_than filters to paths with slack below a threshold.
Multiple -through clauses chain the path through several required points. -nosplit affects
report formatting. -pba_mode selects path-based analysis granularity (path, exhaustive,
or ml_exhaustive). -exclude {tag1 tag2} skips paths already marked with the given tags,
which is how tagging integrates directly into report_timing to avoid redundant exhaustive
PBA work.Expected Result
Filtered reports return only the paths of interest (by endpoint, slack severity, or routing through specific points), and tagged-path exclusion lets successive exhaustive PBA passes progressively analyze the next-worst path set without recomputing alreadyverified paths.
Failure Symptoms
Without filtering, large designs generate unmanageable report volumes; without path tagging, repeated exhaustive PBA runs on large violating path sets redundantly reanalyze already-cleared paths, wasting significant runtime on big designs.
Root Cause
Exhaustive and ml_exhaustive PBA modes are computationally more expensive than simpler modes, so without a mechanism to remember which paths have already been checked, successive refinement passes must always restart from scratch.
Mentor Note — Debugging Procedure
Enable path tagging with set_app_var enable_path_tagging true, tag the currentlyanalyzed path set with create_path_tag_set, verify the tag's coverage with report_path_tag_set/get_path_count_for_tag, and pass -exclude {tag} on subsequent report_timing/exhaustive PBA runs to skip already-tagged paths. report_timing's rich filtering options (through/from/to, nworst-style max_paths, slack thresholds) make targeted debugging tractable, and path tagging is what makes exhaustive PBA scalable on large violating path sets by letting successive passes build on prior work instead of repeating it.
Continue learning free
Get a practical low-power chapter
Receive the existing “Low Power and Multivoltage Fundamentals” PDF chapter and its download link by email.
Continue practising