Stats

  • Locked Locked
  • Replies 1
  • Subscribers 92
  • Views 13227
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Timing path sum is not correct?

eminemshow

Hi, all:

Following is a report of optDesign

------------------------------------------------------------
     optDesign Final Summary
------------------------------------------------------------

+--------------------+---------+---------+---------+---------+---------+---------+
|     Setup mode     |   all   | reg2reg | in2reg  | reg2out | in2out  | clkgate |
+--------------------+---------+---------+---------+---------+---------+---------+
|           WNS (ns):| -0.131  | -0.131  | -0.061  | -0.103  |   N/A   |  0.012  |
|           TNS (ns):|-117.914 |-115.222 | -2.322  | -0.370  |   N/A   |  0.000  |
|    Violating Paths:|  2733   |  2673   |   55    |    5    |   N/A   |    0    |
|          All Paths:|  99908  |  99607  |  4544   |   174   |   N/A   |   889   |
+--------------------+---------+---------+---------+---------+---------+---------+

Density: 60.258%
Routing Overflow: 0.00% H and 0.00% V
Real DRV (fanout, cap, tran): (0, 0, 0)
Total DRV (fanout, cap, tran): (0, 7, 0)
------------------------------------------------------------
**optDesign ... cpu = 0:55:36, real = 0:55:41, mem = 2873.6M **
*** Finished optDesign ***
As we can see, the 'All Paths' line have several numbers, but 99607 + 4544 + 174 > 99908
why? (I didn't list clkgate group because it overlaps with reg2reg group)
Need someone to explain this.
BRs

  •  I just read an article about it on sourcelink:

     

    Results from timeDesign not matching between summary and individual timing reports

    Error Message:
    None
    Problem statement:
    After running timeDesign on a netlist using SOCE version 6.1, there are a set of reports
    generated including a summary report, and individual timing reports for the different path 
    groups.  These groups includ in2reg, reg2reg, reg2out, and clkgate.

    There are times when the WNS and number of violating paths reported in the
    summary report , don't match the values reported in the individual timing reports. 
    Why are these results different?
    Solution:
    In this case, the problem was occurring when running post-CTS timing, and
    using the set_propagated_clocks [ all_clocks] constraint.     In the original 
    constraints there are several pin-level set_clock_latency constraints that were
    overriding the clock propagateion numbers, and caused a discrepency in the 
    paths reported in the summary and the individual timing reports.

      Once the pin-level constraints were eliminated and the propagated clocks
    were allowed to be used for all of the checks, the WNS and total violating
    paths matched between the summary and the individual path fgroup timing reports.

     

     

     

     

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. 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. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.