• 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. density increase by 15% after postcts hold optimization

Stats

  • Locked Locked
  • Replies 3
  • Subscribers 91
  • Views 13785
  • 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

density increase by 15% after postcts hold optimization

jabbar
jabbar over 13 years ago

Hi,

I'm having problem with the high increase of utilization (from 70% to 85%) when I run optdesign -postcts -hold command in soc encounter. Could anyone please let me know what would be the reason of such dramatic increase of the number of buffer to fix hold violation?

My input delay constraint is about 15% (0.5 ns) of the clock period (3 ns). 

Thanks in advance.

 

 

  • Cancel
  • Tongju
    Tongju over 13 years ago

    Please look into your clock tree insertion delay. If it is a large number, then, your input-to-register hold violation fixes will need to add a lot of buffers/inverters (see the in2reg.tarpt for details).  Secondarily, if there is clock skew, then, hold violation will be large between those registers with clock skew and need a lot of buffers/inverters to fix those violations.

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • BobD
    BobD over 13 years ago

    These are good suggestions from Tongju.

    Additionally in my experience the primary cause of area explosion during hold fixing is a larger than intended hold uncertainty. Check your postcts SDCs and compare the hold uncertainty to what the signoff requirement is for hold uncertainty. Having a hold uncertainty target that's larger than the signoff target is more impactful on the hold side than the setup side because each 10ps (or so) of hold margin can lead to thousands of hold violations which can lead to thousands of delay cells which can lead to area explosion like you see.

    Hold SDCs are often not as well vetted during synthesis as compared to setup SDCs so it's particularly common that these things pop up postCTS when hold timing is evaluated for the first time.

    To gain further clarity into the types of hold violations that exist, I'd recommend using Encounter's Global Timing Debug feature on the design right after CTS. It will show you a histogram of the hold violations and allow you to categorize them by type which usually illuminates the primary cause of your problems.

    Great question - I'd be interested in hearing what you find!

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
  • jabbar
    jabbar over 13 years ago

    Thank you Tongju and BobD for the suggestions. I have solved it by analyzing the violated paths through "timing analyzer path" from global timing debug menu (setup check). Then I modified my constraints (SDC) and repeat the synthesis and place and route without any significant increase of density after optdesign -postcts -hold command. There is no problem with the clock tree, it is the problem of my constraints, specifically IO constraints.

    Can you please tell me how can I view histogram of hold time using timing debug in encounter. I have gone through the timing debug chapter in SOC guide but still dont know how to do that. I tried such as follows:

    ----------------

    create_path_category -name {test} -comment {}

    -check_type {{Hold Check}}

    -from_port all_inputs

    -to_cell all_registers

    ------------------------- 

     

    but the encounter gives this info:

    ------------------------

    INFO(create_path_category) : no paths met the criteria defined for group "test", so the group was not created.

    -------------------------
     
    Can you please guide me on how to do that?
     
    Thanks in advance. 

     

     

    Thanks again.

      

    • 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