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.
Clock Tree Latency Calculation Difference between reportClockTree & report_timing.Hi, ALL:I found that using SOC Encounter 52 update 5, the clock tree latency report generated by reportClockTree -clkRouteOnly is quite different from the report_timing command. The detailed scenario is as follow:1. I use setCTSMode -routeClkNet -useCTSRouteGuide (I didn't type the exact option, just its meaning)2. Then Report the clock tree, the latency is 1400-1500ps.3. I then use report_timing to report certain timing path to get certain register clock pin latency.4. I search the clock tree report generated by reportClockTree, found that the latency is 200ps more than the 'report_timing' result.5. I use encounter db command & get_timing command to write a script calculating all the register clock pin latency, found the latency is around 1200-1350ps.( my test block has just 1 clock, hoho....)6. I carefully checked my script & option, nothing strange........Can anybody tell me why, need help.
The area you're working in is a common area of exploration for sure, I'm glad you raised it for discussion. I'd like to make a few observations here:1) When any clock tree synthesis tool reports the latency (while the tree is being built or after the tree has been built), it has to make approximations about the neighboring wires because they haven't been routed yet. It is therefore conceptually difficult to know for sure what the parasitics are going to be, and the latencies reported are therefore approximate. So we can't expect the numbers reported by CTS, or by reportClockTree to align perfectly with with STA especially when the entire design isn't yet detail routed.2) As I'm sure you've noticed, "reportClockTree" has 3 options for route estimation: "-preRoute | -clkRouteOnly | -postRoute". -preRoute is intended for a scenario that isn't used much anymore- where the clock net is routed after clock tree build. -clkRouteOnly aligns most closely the estimation that occurs during CTS- where all neighboring signal wires are approximated. I like using this option when I want to analyze or further optimize the clock tree prior to trialRouting the design after CTS. -postRoute should be used whenever the signal nets have been routed whether by trialRoute or NanoRoute.3) Further complicating things is the fact that launch clock timing can differ from capture clock timing when your design has "set_timing_derate" -or- any number of smaller effects when you're timing the design with "setAnalysisMode -analysisType onChipVariation". That's important to keep in mind when you're seeking to compare latency between CTS and STA.With these challenges in mind, it is of course always possible that you could be hitting a tool limitation associated with some nuance in the design (for example, your clock nets are routed with non-default rules and the CTS isn't extracting those accurately for some reason). Or that you might be able to do some things as a user to guide the tool for better alignment in this area (for example, you could provide a scale factor for the clock nets less than 1 after performing some analysis with the Ostrich parasitic correlation tool shipped with the software). It's difficult to say generally, but I hope these ideas might give you some food for thought.Feel free to post back with additional information or questions. Thanks,Bob
Many thanks for your always GREAT answers!!I am sure that your 2nd suggestion is the best. I find that using 'reportClockTree -postRoute option', I can get the same result with that of 'report_timing'. I am sure that the RC estimation during CTS is different from the result after other-non-clock nets are real or trial routed. And I am now trying to find a way to make the CTS correlation better, I will post back if further improvement is achieved.BRs
Hi All,I had the same problem by the past. I want to make script to calculate model, and teh two command report_clock_timing and reportClockTree did not report the same latency. I used these two command on a routed adtabase and by reading a dspf file. So no extraction underencounter ... and the two command gave me two different latencies. I do not remember to have a clean status on this difference by Cadence support.The only thing is that the two command sdo not use the same method to calculate the latency. The cadence answer was that reportClockTree use the CTS infrastucture (read by cts specification file) and report_clock_timing the CTE infrastructure (from SDC file). This secondcommand use the setAnalysisMode status.There is also a reportClockTreeOCV command. I had this problem with encounter 5 and 6 version. Now I am working with 71 but I do not try again thesecommands.You can try to run your two commands with verbose mode and compare the slew for each level. Generally you have a small differnce for each level, but a lot of small gives a big.report_clock_timing is the same command that you can find under prime time: -type report_type Specifies the type of report to be generated. Allowed values are as follows: transition - To specify a transition time report. latency - To specify a latency report. skew - To specify a skew report; you cannot use the -launch, -capture, -rise, -fall, and -lesser_than options if you specify a skew report, and you can use the -include_uncertainty_in_skew option only in a skew, interclock_skew or summary report. interclock_skew - To specify an interclock skew report; you cannot use the -launch, -capture, -rise, -fall, and -lesser_than options if you specify an interclock skew report, and you can use the -include_uncertainty_in_skew option only in a skew, interclock_skew or summary report. summary - To specify a summary report, which shows the worst instances of transition time, latency and skew over the clock network(s) or sub-network(s) of interest. You can use only the -clock, -to_list, -from_list, -include_uncertainty_in_skew, -nosplit, and -significant_digits options if you specify a summary report. -setup Indicates that only the setup data path is to be used in the report, and that the skews, latencies or transition times reported must correspond to those used by report_timing in the verification of setup constraints. -setup and -hold are mutually exclusive; if neither is specified, -setup is assumed. This option cannot be used in summary reports. -nworst worst_entries Specifies the number of worst report entries to be reported per clock domain; the default is 1. Entries are sorted with respect to the attribute of interest (transition time, latency or skew) specified with -type report_type. The worst entries are those most likely to cause a violation. For example, if you request a latency report using -setup and -capture, the smallest worst_entries are listed, sorted in ascending order, because small capture latencies for setup paths are more likely to lead to a violation than large capture latencies. By contrast, for skew reports, the worst entries always correspond to the largest skews over the specified domain. This option cannot be used in summary reports.Regards ...[b] [/b][b] [/b][b] [/b]