What does report_global_timing show that checking individual failing paths does not?
From PDVerse STA Mentor Guide · pdVerse Mentor Guide
Short Answer
Reading one report_timing (PT) result at a time tells you about a single path, but it says nothing about whether the design as a whole is converging toward closure or drifting further from it. report_global_timing (PT) summarizes the overall timing closure state across the design, how many endpoints are met, how many are violating, and by how much in aggregate, giving a single closure snapshot instead of a path-by-path picture.
Technical Explanation
report_global_timing(PT) works alongside features like path grouping and constraint reporting, but focuses specifically on the closure status of the whole design rather than any one path.- Because it reports global closure status, it is meant to be run repeatedly across ECO iterations to track whether the total violation count and total negative slack are actually shrinking.
- It can be scoped down to specific path groups or clocks, useful for tracking closure progress on one clock domain separately from the rest of the chip.
- Options control how much path-gathering work the report does before summarizing, since a global sweep of the whole timing graph is more expensive than reporting one path.
- A design can show individual failing paths getting fixed one at a time while the aggregate picture from
report_global_timing(PT) reveals new violations appearing elsewhere just as fast, which a path-by-path view alone would miss. - Signoff reviews typically ask for the global summary first, to judge whether the design is actually converging, before drilling into any specific path.
Common Mistake
The Trap: Judging ECO progress purely by whether the specific paths fixed last week still look clean, without rechecking the design-wide violation count.
- A design can look locally improved while its overall closure state is flat or worse, because each fix nudges load or timing onto a neighboring path that was not being individually tracked.
Follow-up Question & Model Response
If a team fixes ten reported violations but report_global_timing shows the same total violation count as before, what does that usually mean?
Candidate Model Response: It usually means the fixes shifted the problem rather than removing it, buffering or resizing cells on the ten fixed paths likely added load or delay onto neighboring nets, creating roughly as many new small violations as were cleared. This is common when fixes are chosen locally, one path at a time, without checking the aggregate closure number after each round. Comparing the global summary before and after a batch of ECOs is what actually reveals this pattern, since the ten individually-checked paths would all look clean on their own. The next step is usually to look for a shared cause across the newly appearing violations, rather than continuing to fix paths one at a time.
Practical Example
Before a round of ECO fixes, report_global_timing (PT) shows 340 violating endpoints and -18ns of total negative slack. After fixing the ten worst individually-reported paths, the same command shows 335 violating endpoints and -17.4ns total negative slack, real but modest progress, prompting the team to look for one shared root cause across the domain instead of continuing single-path ECOs.
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