How would you like to send more than just a timing report to your favorite Cadence AE but you’ve got a proprietary design that can’t leave your company?
What if there was a way to remotely enable more critical path analyses like bottleneck analysis, categorization of the contents of your critical paths and histogram analysis of your timing paths – all without requiring you to send any of your design files (RTL, libraries, constraint files)? What if I told you that you could do all that and more by yourself? (good - that’s my next article) For now, here’s how you can enable remote analysis by someone else – without sending them all of your design files.
This exchange of information is possible with a new type of timing report generated by RTL Compiler (RC). This format has been available for over year, but might not be well known. That’s why I’m writing a series of articles that highlight some of the “less popular” tool interfaces built into RC and the potential capabilities they enable.
What we are going to enable is an Encounter feature called “Global Timing Debug”. GTD is a great tool to analyze your critical timing paths. Often times I found that while I might have several hundred violating paths – they really consist of only one or two different types (or categories) of timing path. Thus if I can analyze the different types of paths and find common elements within the paths and then improve those common elements – I end up fixing more paths at once vs. one at a time. GTD facilitates that type of analysis.
GTD is currently not available in RC, it is associated with SOC Encounter and is part of the Encounter Timing System (ETS). GTD offers a variety of analysis capabilities based on a timing histogram of the critical paths in a design. RC does have an interface command “write_ets”, which will create an ETS script file with your design files (libs, lef, gate level netlist, constraint files) assigned to the correct ETS variables – but that script requires you to share your design database files in order for it to work and that command is NOT the subject of this article.
The subject of this article, a machine readable timing report format, generated by RC, contains all the necessary information in one file to characterize the timing of the critical paths of the design without requiring any supporting files (and no, it doesn’t tar them up and put them inside the file). It captures enough technology specific data to recreate the timing paths and their constraints inside ETS without the netlist. It enables GTD analysis – which can be done by you, or someone else – either onsite or offsite – with just one file.
Creating a ETS-GTD machine readable file: RTL Compiler to Encounter Timing System
Here's what you do:
1. After you've synthesized your design to gates (synthesize -to_mapped) you are ready to create and save a machine readable timing report. To create the machine readable timing report formatted file use the following command:
"report timing -gtd -num_paths 1000 > filename.mtarpt"
The "-gtd" option, which stands for "Global Timing Debug", is the feature that enables the capturing of the data in a machine readable format.
Note: I use "-num_paths 1000" so that there's a lot more than just one path in the report – I’ll use a histogram in ETS to see the distribution of the critical paths and from that determine the scope of the problem (i.e. how widespread is it).
2. You’re done. Send the file to who ever you want to look at your design timing data to analyze it using ETS’s GTD.
In my next article I'll discuss some of the features of Global Timing Debug and how YOU can use them to debug your timing problems.
Good luck designing.
Good to see you in the blogosphere!!!
Interesting article. Perhaps I'll start a side business interpreting timing reports for designers in tapeout crunch. Just send me your GTD file and I'll tell you where your timing problem is. Kinda like a high-tech version of Lucy Van Pelt's 5 cent Psychiatry advice booth ... but more expensive :-)