Cadence® system design and verification solutions, integrated under our System Development Suite, provide the simulation, acceleration, emulation, and management capabilities.
System Development Suite Related Products A-Z
Cadence® digital design and signoff solutions provide a fast path to design closure and better predictability, helping you meet your power, performance, and area (PPA) targets.
Full-Flow Digital Solution Related Products A-Z
Cadence® custom, analog, and RF design solutions can help you save time by automating many routine tasks, from block-level and mixed-signal simulation to routing and library characterization.
Overview Related Products A-Z
Driving efficiency and accuracy in advanced packaging, system planning, and multi-fabric interoperability, Cadence® package implementation products deliver the automation and accuracy.
Cadence® PCB design solutions enable shorter, more predictable design cycles with greater integration of component design and system-level simulation for a constraint-driven flow.
An open IP platform for you to customize your app-driven SoC design.
Comprehensive solutions and methodologies.
Helping you meet your broader business goals.
A global customer support infrastructure with around-the-clock help.
24/7 Support - Cadence Online Support
Locate the latest software updates, service request, technical documentation, solutions and more in your personalized environment.
Cadence offers various software services for download. This page describes our offerings, including the Allegro FREE Physical Viewer.
Get the most out of your investment in Cadence technologies through a wide range of training offerings.
This course combines our Allegro PCB Editor Basic Techniques, followed by Allegro PCB Editor Intermediate Techniques.
Virtuoso Analog Design Environment Verifier 16.7
Learn learn to perform requirements-driven analog verification using the Virtuoso ADE Verifier tool.
Exchange ideas, news, technical information, and best practices.
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.
It's not all about the technlogy. Here we exchange ideas on the Cadence Academic Network and other subjects of general interest.
Cadence is a leading provider of system design tools, software, IP, and services.
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.