Stats

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

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
Parents

  • Eng Han,

    You're right about removing the timing constraints after CTS if you follow my suggestion. It's a good point, and I should have said that in the first place (our flow uses tweaked SDCs between pre and post CTS, I just forgot about that "minor" detail!!).

    "path_adjust" sounds good, but how many tools other than RC support it? I'd not come across it before, might have to have a play in the morning (well morning for us europeans!!).

    I also note your comment about the timing of the gating (either have simple logic or false-path it), that sort of thing is something (in my opinion) you need to design in from the architecting level. For example, by false/multicycle constraint, you make the gating non-immediate (switch may or may not pass clock this cycle). This gating is then only suitable for on/off switching (eg turning a block on for use then off again after some period of time). This behaviour may need even the s/w guys to account for. By contrast the gating done for localised power control is immediate (the clock must pass on the next cycle). The only way this enable can meet timing is to have simple logic gating a small register bank (so the tree size after the gate is minimised).

    Or perhaps we could just persuade the world to stick to mains-powered devices and stop using these damn batteries ;-)

    CD


    Originally posted in cdnusers.org by crispy_duck
Reply

  • Eng Han,

    You're right about removing the timing constraints after CTS if you follow my suggestion. It's a good point, and I should have said that in the first place (our flow uses tweaked SDCs between pre and post CTS, I just forgot about that "minor" detail!!).

    "path_adjust" sounds good, but how many tools other than RC support it? I'd not come across it before, might have to have a play in the morning (well morning for us europeans!!).

    I also note your comment about the timing of the gating (either have simple logic or false-path it), that sort of thing is something (in my opinion) you need to design in from the architecting level. For example, by false/multicycle constraint, you make the gating non-immediate (switch may or may not pass clock this cycle). This gating is then only suitable for on/off switching (eg turning a block on for use then off again after some period of time). This behaviour may need even the s/w guys to account for. By contrast the gating done for localised power control is immediate (the clock must pass on the next cycle). The only way this enable can meet timing is to have simple logic gating a small register bank (so the tree size after the gate is minimised).

    Or perhaps we could just persuade the world to stick to mains-powered devices and stop using these damn batteries ;-)

    CD


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