Get email delivery of the Cadence blog featured here
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:
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?
Hi Bob, great demo! I posted this link to our lab PDLs for Encounter floorplanners and block builders. I will let you know if I receive any request for additional features/information.
Hi Bob, great demo. I suggested this very thing to someone the other day. My favorite parts of Global Timing Debug are getting a quick visual look at the failing paths (sometimes that's all you need to see what's wrong), the list of SDCs affecting the path, and the Timing Interpretation.