Cadence.com will be under maintenance from Friday, Oct. 3rd at 6pm (PST) thru Sunday, Oct 5th at 11pm (PST).
Cadence.com login, registration, community posting and commenting functionalities will be disabled.
Home > Community > Blogs > Logic Design > rc to ets gtd an easy way to enable remote timing analysis without revealing your rtl
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

Register | Membership benefits
Get email delivery of the Logic Design blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Enable Remote Timing Analysis Without Revealing Your RTL

Comments(1)Filed under: Logic Design, RTL compiler, Encounter Timing System, Timing Report, Global Timing Debug, Timing InterfaceBy Jack Marshall
Sr. Technical Leader
Customer Solutions
Team FED

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.

Comments(1)

By theASICguy on March 3, 2009
Hi Jack,

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 :-)

Harry


Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.