Home > Community > Forums > Digital Implementation > Clock Tree Latency Calculation Difference between reportClockTree & report_timing

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

 Clock Tree Latency Calculation Difference between reportClockTree & report_timing 

Last post Tue, Jul 1 2008 2:18 AM by archive. 4 replies.
Started by archive 20 Jun 2008 03:35 AM. Topic has 4 replies and 4143 views
Page 1 of 1 (5 items)
Sort Posts:
  • Fri, Jun 20 2008 3:35 AM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    Clock Tree Latency Calculation Difference between reportClockTree & report_timing Reply

    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.


    Originally posted in cdnusers.org by eminemshow
    • Post Points: 5
  • Fri, Jun 20 2008 7:29 AM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: Clock Tree Latency Calculation Difference between reportClockTree & report_timing Reply

    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


    Originally posted in cdnusers.org by BobD
    • Post Points: 0
  • Fri, Jun 20 2008 8:23 AM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: Clock Tree Latency Calculation Difference between reportClockTree & report_timing Reply

    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


    Originally posted in cdnusers.org by eminemshow
    • Post Points: 0
  • Tue, Jul 1 2008 1:43 AM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: Clock Tree Latency Calculation Difference between reportClockTree & report_timing Reply
    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

     


    Originally posted in cdnusers.org by aidans
    • Post Points: 5
  • Tue, Jul 1 2008 2:18 AM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: Clock Tree Latency Calculation Difference between reportClockTree & report_timing Reply

    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]


    Originally posted in cdnusers.org by Black Lutin
    • Post Points: 0
Page 1 of 1 (5 items)
Sort Posts:
Started by archive at 20 Jun 2008 03:35 AM. Topic has 4 replies.