Clock Tree Latency Calculation Difference between reportClockTree & report

Unanswered

Active Topics

Forums

Forums > Digital IC > Floorplanning, Place and route

Subject: Clock Tree Latency Calculation Difference between reportClockTree & report_timing

Posting to forums is available to community members only.
Login or Register

Rate this topic:

Author

Messages

eminemshow
Posts: 75
Online: User is Offline

6/20/2008 3:35 AM
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.

BobD
Posts: 80
Online: User is Offline

6/20/2008 7:29 AM
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

eminemshow
Posts: 75
Online: User is Offline

6/20/2008 8:23 AM
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

aidans
Posts: 35
Online: User is Offline

7/01/2008 1:43 AM
Hi Bob Great post! I'd like push this topic a step further: what's the difference between the following two command? report_clock_timing -type skew -nworst 5 -setup reportClockTree -postRoute

Black Lutin
Posts: 11
Online: User is Offline

7/01/2008 2:18 AM
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 under encounter ... 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 second command 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 these commands. 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]

Posting to forums is available to community members only.
Login or Register

Forums > Digital IC > Floorplanning, Place and route > Clock Tree Latency Calculation Difference between reportClockTree & report_timing

ActiveForums 3.6