Global Timing Debug has been a very popular capability within SoC-Encounter. Once you start using it, it becomes hard to go back to looking at text reports. The high level philosophy of Global Timing Debug is to assess not just the worst path in the design- but all of the failing paths to get a feel for the categories of problems which are blocking timing closure.
That said, I find that Global Timing Debug visualizes a single path extremely well. In addition to highlighting the path in the layout window, it adds useful details that are hard (or impossible) to extract from the textual report. For example:
- It clearly states the clock skew for the path.
- It shows the relative contribution to path delay for each instance in the path and colorizes the instances based on cell type.
- It reports the SDCs which potentially affect the path with line numbers from the SDC file.
- It provides a "Timing Interpretation" which gives suggestions on things to look for when analyzing why a path is failing.
For these reasons and more, it is often useful to bring up a single specific path within Global Timing Debug. For example, if you've got a worst path text report from your signoff timing tool and you'd like to see that exact start/endpoint path visualized within Global Timing Debug. The following screencast shows how you would use "report_timing -machine_readable" to output a .mtarpt file that can be read into Global Timing Debug:
I'll be doing future screencasts on Global Timing Debug, but I hope this targeted example is useful.
Question of the Day: What is your favorite part of Global Timing Debug? What features would you like to see added?