• Skip to main content
  • Skip to search
  • Skip to footer
Cadence Home
  • This search text may be transcribed, used, stored, or accessed by our third-party service providers per our Cookie Policy and Privacy Policy.

  1. Community Forums
  2. Digital Implementation
  3. Timing analysis on partitioned design in EDI

Stats

  • Locked Locked
  • Replies 3
  • Subscribers 93
  • Views 14943
  • 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 analysis on partitioned design in EDI

weian
weian over 15 years ago

After assembling the partitions into the top design, I tried to do static timing analysis over the whole design, but the timing report showed 0 slews and delays in the buffers of clock paths. It seems that the tool didn't consider the wire load while computing timing although the log file showed the RC extraction operations. In the timing analysis of each individual partition, however, the path delays looked fine. Can anyone tell me why and how to fix? Did I miss something after assembling the partitions? Thanks very much.

  • Cancel
Parents
  • Martinage
    Martinage over 15 years ago

    It sounds like some of your clock trees are still in ideal mode.  Try running the following to
    find all clock endpoints that are not receiving a propagated clock:

    encounter 2> check_timing -check_only clock_not_propagated -verbose
    ###############################################################
    #  Generated by:      Cadence Encounter 09.13-s229_1
    #  OS:                Linux x86_64(Host ID pe-opt13)
    #  Generated on:      Wed Nov  3 17:04:26 2010
    #  Command:           check_timing -check_only clock_not_propagated -verbose
    ###############################################################
         +------------------------------------------------------+
         |                 TIMING CHECK SUMMARY                 |
         |------------------------------------------------------|
         |       Warning        |      Warning       |  Number  |
         |                      |    Description     |    of    |
         |                      |                    | Warnings |
         |----------------------+--------------------+----------|
         | clock_not_propagated | Ideal clock at pin |       10 |
         +------------------------------------------------------+
         +-----------------------------------------+
         |           TIMING CHECK DETAIL           |
         |-----------------------------------------|
         |      Pin      |         Warning         |
         |---------------+-------------------------|
         |  TR0/BR1/CK   | Ideal Clock WAVE at pin |
         |  TR1/BR1/CK   | Ideal Clock WAVE at pin |
         |    CGR/CK     | Ideal Clock WAVE at pin |
         |  BLK/BR0/CK   | Ideal Clock WAVE at pin |
         |  BLK/BR1/CK   | Ideal Clock WAVE at pin |
         |  BLK/BR11/CK  | Ideal Clock WAVE at pin |
         |  BLK/BR2/CK   | Ideal Clock WAVE at pin |
         | BLK/SPARE1/CK | Ideal Clock WAVE at pin |
         | BLK/SPARE2/CK | Ideal Clock WAVE at pin |
         |  TR2/BR1/CK   | Ideal Clock WAVE at pin |
         +-----------------------------------------+

     

    If this report does show up some ideal clocked endpoints, you likely have a set_clock_latency still set somewhere
    between the clock definition and the endpoints.  You could consider running the  reset_clock_tree_latency command.

    This will walk the specified clock trees and remove any set_clock_latency assertions that are still around.

     

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • Martinage
    Martinage over 15 years ago

    It sounds like some of your clock trees are still in ideal mode.  Try running the following to
    find all clock endpoints that are not receiving a propagated clock:

    encounter 2> check_timing -check_only clock_not_propagated -verbose
    ###############################################################
    #  Generated by:      Cadence Encounter 09.13-s229_1
    #  OS:                Linux x86_64(Host ID pe-opt13)
    #  Generated on:      Wed Nov  3 17:04:26 2010
    #  Command:           check_timing -check_only clock_not_propagated -verbose
    ###############################################################
         +------------------------------------------------------+
         |                 TIMING CHECK SUMMARY                 |
         |------------------------------------------------------|
         |       Warning        |      Warning       |  Number  |
         |                      |    Description     |    of    |
         |                      |                    | Warnings |
         |----------------------+--------------------+----------|
         | clock_not_propagated | Ideal clock at pin |       10 |
         +------------------------------------------------------+
         +-----------------------------------------+
         |           TIMING CHECK DETAIL           |
         |-----------------------------------------|
         |      Pin      |         Warning         |
         |---------------+-------------------------|
         |  TR0/BR1/CK   | Ideal Clock WAVE at pin |
         |  TR1/BR1/CK   | Ideal Clock WAVE at pin |
         |    CGR/CK     | Ideal Clock WAVE at pin |
         |  BLK/BR0/CK   | Ideal Clock WAVE at pin |
         |  BLK/BR1/CK   | Ideal Clock WAVE at pin |
         |  BLK/BR11/CK  | Ideal Clock WAVE at pin |
         |  BLK/BR2/CK   | Ideal Clock WAVE at pin |
         | BLK/SPARE1/CK | Ideal Clock WAVE at pin |
         | BLK/SPARE2/CK | Ideal Clock WAVE at pin |
         |  TR2/BR1/CK   | Ideal Clock WAVE at pin |
         +-----------------------------------------+

     

    If this report does show up some ideal clocked endpoints, you likely have a set_clock_latency still set somewhere
    between the clock definition and the endpoints.  You could consider running the  reset_clock_tree_latency command.

    This will walk the specified clock trees and remove any set_clock_latency assertions that are still around.

     

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Children
No Data

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.

© 2025 Cadence Design Systems, Inc. All Rights Reserved.

  • Terms of Use
  • Privacy
  • Cookie Policy
  • US Trademarks
  • Do Not Sell or Share My Personal Information