• 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. Logic Design
  3. Properly optimizing enable to clock gating enable

Stats

  • Locked Locked
  • Replies 10
  • Subscribers 61
  • Views 25155
  • 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

Properly optimizing enable to clock gating enable

archive
archive over 19 years ago

Hi,

I am curious to know how you handle the path to clock gating enable  pin.

I have a design containing multiple level of clock gating on the clock network and when synthesizing using ideal clock all my patht o enable pins have a full  cycle but when My CTS will introduced the latency of the network will reduce the available time to reach those pins.

I understand I could perform post CTS optimization but I would prefer a more robust method to constraint those in ideal clock mode.

I'am thinking of the 2 following approach and would like to hear from you if you have use them or if you have used any others.

- max_delay to enable pins equal to (clock period - expected network latency post clock gating element)
- defining generated clock after each clock gating element with different latency

Those 2 methods have the inconvenience of requiring a lot of data management  :(

Thanks for your help,
Eric.


Originally posted in cdnusers.org by evenditti
  • Cancel
Parents
  • archive
    archive over 19 years ago

    Ever been beaten by that one due to the clock latency making your enable being seen one cycle too late?
     

    Hence my comment about needing to design/structure this from scratch. if the system is designed to cope with the uncertainty, then it shouldn't be a problem (BOCTAOE)

    By the way, this structuring becomes even more important when you start to consider multiple-supply voltages, because turning the power onto a block is far slower than turning a clock on, and if your s/w can’t handle this delay/prediction for clocks, you’ll never manage it for voltage!!).

    CD


    Originally posted in cdnusers.org by crispy_duck
    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • archive
    archive over 19 years ago

    Ever been beaten by that one due to the clock latency making your enable being seen one cycle too late?
     

    Hence my comment about needing to design/structure this from scratch. if the system is designed to cope with the uncertainty, then it shouldn't be a problem (BOCTAOE)

    By the way, this structuring becomes even more important when you start to consider multiple-supply voltages, because turning the power onto a block is far slower than turning a clock on, and if your s/w can’t handle this delay/prediction for clocks, you’ll never manage it for voltage!!).

    CD


    Originally posted in cdnusers.org by crispy_duck
    • 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