How do you report timing results across all scenarios at once in PrimeTime?
From PDVerse STA Mentor Guide · pdVerse Mentor Guide
Short Answer
The report_global_timing (PT) command summarizes worst-case timing across every active scenario in one view, instead of requiring a separate report per scenario that a designer would have to compare by hand. It gathers each path's result from whichever scenario stresses it hardest and presents a single, ranked summary of the design's actual worst-case timing status.
Technical Explanation
Once a design has more than a handful of scenarios, comparing results scenario by scenario stops being practical, and a global view becomes necessary.
- It reports across the current scenario scope. With
current_scenario -all(PT) in effect,report_global_timing(PT) considers every active scenario; narrowing focus first restricts the summary to just the scenarios in scope, the same way other reporting commands respectcurrent_scenario. - It reports the worst case per path, not every scenario's number for every path. For a given endpoint, the command surfaces whichever scenario produces the worst slack, since that is the number that actually decides whether the path is safe.
- Path gathering and output can both be controlled. Options exist to control how many worst paths are collected before ranking, and how the final report is formatted and grouped, so the summary can be tuned for either a quick top-level check or a deeper design-wide sweep.
- It complements, rather than replaces, per-scenario reporting. A global report tells you where the worst violations are and which scenario is responsible; a follow-up
current_scenario(PT) narrow-and-report_timing(PT) sequence still gets the full path detail. - What breaks: reading a per-scenario report's worst slack as the design's true worst slack — a path fine in the scenario you happened to check can still be the design's actual worst violation elsewhere.
Common Mistake
The Trap: checking only the one or two scenarios a team "knows" are usually the worst case, instead of running a global report across all active scenarios.
- A designer assumes the slow-slow, worst-voltage functional scenario is always where the worst setup violation shows up, based on experience from earlier designs, and only checks that one before declaring the block clean.
- A different scenario — perhaps a scan-test mode with a different clock configuration — turns out to have the real worst path this time, and it goes unchecked because the team's habitual assumption skipped a genuine
report_global_timing(PT) sweep.
Follow-up Question & Model Response
If report_global_timing shows the design's worst path is in a scenario you did not expect, what would you check first before trusting that result?
Candidate Model Response: First, I would confirm that scenario's own setup is valid — its operating condition, parasitics, and mode-specific SDC consistent with each other — since a genuine setup mistake, like mismatched parasitics, can produce an artificially bad number. If the scenario checks out, the result is telling me something real that habitual checking would have missed, and I would treat it as a genuine finding rather than second-guessing it for being unexpected.
Practical Example
A block has 9 active scenarios in focus via current_scenario -all (PT). Running report_global_timing (PT) returns a ranked list of the 20 worst paths across all 9, and the single worst entry — a -31ps setup violation — comes from test_ffg_rcmin, a scan-test-mode scenario the team had not manually checked in over a month because their habitual spot-check routine focused on the two functional-mode scenarios. Investigating that path with current_scenario {test_ffg_rcmin} (PT) followed by report_timing (PT) traces the violation to a scan-chain reconfiguration change made three weeks earlier that had never been re-verified against the test-mode scenario specifically.
Complete STA Handbook
Master Signoff-Ready Static Timing Analysis
Get the complete 10-chapter STA handbook covering setup/hold margins, clock modeling, OCV/POCV, crosstalk noise, and PrimeTime closure.
Continue practising