Get email delivery of the Cadence blog featured here
By Jack Marshall
Sr. Technical Leader
In my first article I wrote about how to generate a Global Timing Debug (GTD) timing report from within RC which would allow you to send all the necessary information to your favorite Cadence AE to facillitate their debugging of your critical timing paths - without giving up any RTL secrets.
This article is about how to "Do it Yourself" and perform the GTD analysis - without any Encounter or Encounter Timing System experience required at all. And we are going to do it without any screen shots - even though that would make a much better presentation (sounds like a white paper to me and if I publish one or can find one - I'll put a link to it in this blog post).
Let's get started. You can access ETS's GTD two ways - either through the Encounter GUI or by invoking ETS standalone: You do NOT need a config file (.conf) to start Encounter or ETS to do this debugging.
From RTL Compiler:
rc> report timing -gtd -slack 0 > timing.mtarpt
To Open & Debug the timing report using SOC Encounter:
unix> encounter -> Timing tab -> Debug Timing -> Display/Generate Timing Report -> Timing Report File -> Browse icon -> timing.mtarpt <OK>
Or to Open & Debug the timing report using Encounter Timing System:
Unix> ets -> Analysis tab -> Report File(s) -> Browse icon -> Display/Generate Timing Report -> Timing Report File -> Browse icon -> timing.mtarpt <OK>
At this point you should see a histogram of your timing paths displayed in the upper left hand corner of the Timing Debug Window. There are fours parts to this window: Path Histogram, Category Summary, Path Category, and Path List.
Path Histogram Window:The Path Histogram window displays a histogram of all of your failing paths. We are going to use this histogram to analyze the composition of the timing paths and see how they are related (if at all) in a variety of different analysis scenarios. As I mentioned in my first article - you might have several hundred timing paths that are violating your timing goals (they've got negative slack) - but you notice that several of the different paths have parts or areas or clocks or instances that are common amongst several paths. So if you can "fix" those paths you actually improve multiple paths in your design. The Histogram is your point of reference to see which of your critical paths are related to which other critical paths.
Category Summary Window:The Category Summary window at startup displays information regarding all of the paths in the timing report. The Global Timing Debugger creates "categories" of paths which share some type of common feature: clock domain, bottle neck (common instance), hierarchy, register endpoint or register startpoint, design rule violation etc. As different categories are created by GTD's analysis scenarios - you can view the timing characteristics (WNS, TNS, # of Failing Paths) of a particular category in this window.
Path Category Window:The Path Category window lists all of the different path categories that have been created by GTD's analysis scenarios. You can add to this list by running an analysis scenario from the Analysis tab located in the lower left hand side of this window. There is a menu which enables you to add, hide, edit, change color or delete a category listed in the window by right mouse clicking from within the window. By default, a category is not featured in the Path Histogram window until you "Add Category to Histogram" via the pop-up menu. Then you should see the corresponding bars of the histogram colored to match the particular category's color. We will use the Analysis tab of the Path Category window to select the different timing debug analysis scenarios of GTD later in this paper.
Path List Window:The Path List window displays more information about the particular category that has been selected in the Path Category window. Information like Clock, Required Time, Slack and Endpoint are displayed for each path in the category. If you "left-mouse-button-double click" on a path number (the leftmost column) -that will open a detailed Timing Path Analyzer window. This window has a tremendous amount of information regarding the individual path selected: graphically: a representation of the slack calculation, a distribution of the timing delays throughout the path, a hierarchy view of the instances involved in the timing path. textually: a listing of the start & end points, slack, skew and type of path, as well as a detailed listing of each component of the timing path. There are additional tabs that allow you to inspect more details regarding the clocks, the SDC's, a timing interpretation (analysis) of the path wrt latches, clock gating, hard macros present, HVT cells,buffering chain, net fanout, level shifters, large skew, divider in path, SI delay, External delay - but they are "greyed out" for our data - they're available when you run ETS/SOCE with a completed netlist, SDC, config, lef & def files (not our case)
Timing Analysis: Getting back to the main Timing Debug Window, let's perform some timing analysis using the timing analysis scenarios in the Path Category window. Right mouse click on the Analysis tab: you'll see several different analysis scenarios: Path Group Analysis, Clock Analysis, Hierarchical Analysis, View Analysis, Critical False Path, Bottleneck Analysis, DRV Analysis, Hierarchical Analysis Viewer. I would encourage you to try out each one - read the documentation under the Help tab - but I am going to just talk about my favorite scenarios (for me the most useful ones).
Path Group Analysis:The Path Group scenario will characterize each path based on the type of path it is: i.e. register to register, input to register, register to output and input to output. It creates a separate category for each type of path. If you don't know what type of paths are failing to meet timing - this is a good starting point to classify which types of paths are failing. I always focus on the core timing first - the register to register paths. If they are failing - then I ignore the other types of paths until I can get the R2R paths to pass. This is a quick and painless analysis. Move on.
Clock Analysis: The Clock Analysis scenario creates categories for the different clocks associated with a timing path. Again, if you aren't aware of the type of clocks involved in your critical paths - this is a good informational analysis to perform - you could find out that the majority of your most critical timing paths are associated with just one specific clock object. Then by adjusting the timing on that clock object (via path adjust or clock uncertainty or clock latency) - you can address multiple failing paths. This is another quick and painless analysis. Move on
Critical False Path:The Critical False Path analysis will call Conformal Constraint Designer under the hood and perform a False Path analysis of the critical paths. This is what I call "optimization-less solution" - if we can find out that one or more critical paths is actually a false path - i.e. it will never be energized during operation of the chip - and we can eliminate the path from our critical paths - then we save the time it would take to further optimize that path. Two caveats: 1. you can't use this without CCD license, 2. for GTD debug with our machine readable timing report - it won't work in CCD - CCD requires the complete netlist to do it's analysis. But this is still a good idea to try if you have the full design loaded in ETS or Encounter.
Bottle Neck Analysis:Bottle Neck Analysis creates categories of paths based on common instances in multiple paths. It will find if there is an instance that appears in more than one timing path. The name of the category reflects the instance name of the bottle neck. You can use that to see how many paths are influenced by a single instance in a design. You can use this information to break up or "parallelize" your RTL code to reduce the bottle necks in your design.
Displaying new categories in the Path Histogram Window:I have a specific methodology that I use during GTD:
Creating Customized Categories:This is the best part of GTD: creating your own categories. Select the Category tab inside the Path Category window. Then select "Create". This will open a custom category creation window called "Create Path Category". Provide a name for your category, then use the pull down menues to select which common path components you want GTD to find in as many paths as possible and put them in your category. The different "conditions" of path components are numerous: -to, -from, -through, -slack, -not_to, -number_of ... as well as the "type" of path components: instance, pin, cell, clock, port. You can add two "conditions" together to create more complex searches of the timing paths to find commonality. It's fun (and very useful). Click on the "Create" button on the button of the page to run and create the category. Add the category to your histogram view to see how widespread the category is amongst the critical paths in your design.
Well, that's enough for now, I expect to have this type of analysis available in RTL Compiler in the future - until then - you can access it via ETS's GTD inside Encounter or ETS standalone. I hope this gives you some ideas on how to take advantage of our Cadence tools to help analyze your design and hopefully find & solve your timing problems in your timing paths.
Good luck designing.