Stats

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

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.

 

 

Parents

  • 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!

Reply

  • 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!

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.