• 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. How to find ThroughPin(s) for generated clock

Stats

  • Locked Locked
  • Replies 6
  • Subscribers 91
  • Views 2783
  • 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

How to find ThroughPin(s) for generated clock

MMode
MMode over 15 years ago

Hi all,

in our design we use a number of generated clocks, i.e. the main clock is for instance divided by 13339. The clock dividers are specified as generated_clock in the SDC file. Now, we would like to build a clock tree for the main clock including the generated clock domains. This should be possible with the ThroughPin feature of the clocktree spec. However, we are unsure of how to correctly define our scenario using ThroughPins. Do we actually need to specify a ThroughPin entry for every bit of the counter that divides the clock? Or is this the wrong approach anyway?

 

We have tried some approaches by now but still cannot achieve timing closure on our design, so we would be thankful for any suggestions and background explanations.

  • Cancel
  • Rajesh Vembu
    Rajesh Vembu over 15 years ago

     Have you tried using the automatic clock tree specification generation available in encounter?

    If not, please refer the user manual/ command reference manual for createClockTreeSpec or clockDesign -genSpecOnly 

    The automatic clock tree specification determines the ThroughPins automatically based on the timing constraints.

    Please review the generated ctstch file and modify according to your needs.

     

    Hope this is helpful.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • MMode
    MMode over 15 years ago

     Hi Rajesh,

     

    thank you for your suggestion. We tried that but the ThroughPin section was empty in the resulting file. However, with this we were unable to reach timing closure.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Rajesh Vembu
    Rajesh Vembu over 15 years ago

     Have you checked the clock trace file?

    This can be generated using ckSynthesis -check [-forceReconvergent] after specifying the cts spec file.

    The trace file would give a good idea as to how the tool traces the clock path based on the AutoCTSRootPin definitions in ctstch file.

    Sometimes the ThroughPins are not "explicitly" defined in the ctstch file created automatically. But this can always be verified by checking the trace file.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • MMode
    MMode over 15 years ago

    Thank you for your hints, that was very helpful - we considered the ThroughPin spec to be mandatory for every generated clock, this does not seem to be correct.

    We checked the clock trace, it shows that the registers in questions are sinks of the clock tree, so you are right, the ThroughPin does not seem to be necessary here. However, we do not reach a setup WNS better than -3 ns for the generated clock during postCTS and postRoute optimizations - even though there is enough space and the divided clock is really slow.

    Do you have any other suggestions where we might locate the problem? According to the clock trace, the clock tree does not seem to be the problem.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • Kari
    Kari over 15 years ago

     I would suggest next running the Timing Debugger. By looking at the failing paths visually, you may see what the issue is. Make sure to look at the Timing Interpretation tab - this will flag some potential issues as well.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • MMode
    MMode over 15 years ago

     Hi Kari, thank you for your suggestion. It seems we were simply misled by assuming that the ThroughPin entries are mandatory for every clock divider - as a result, we were trying to locate the source of our problem at the wrong place. I think we have found some potential issues by now.

     

    Thank you all for your clarifications and suggestions, that was very helpful!

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel

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