Stats

  • Locked Locked
  • Replies 12
  • Subscribers 93
  • Views 26912
  • 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

clock gating paths

maven7783

Hi All,

In my design i got many clock gating setup violations which are due to negative skew i.e., my launch clock delay is more than capture clock delays.Placement in the design is clock gate aware.

Can someone suggest some techniques for these kind of violations. 

Parents

  • Hi maven,

    I downloaded and viewed your attachment. Thanks for sending that. I think we're aligned on the fundamental challenge presented here.

    I think the tool is inserting buffers downstream from the ICG for a reason. Either it needs to satisfy max cap/max tran -or- it is seeking to minimize overall insertion delay. One thing that occurred to me is that perhaps your ICGs are marked dont_touch in the .lib?  It's fairly common that the ICGs would be marked by the library provider as such.  The reason I think this could be relevant is that if the ICGs were marked dont_touch, it would disallow the tool from upsizing the ICG to meet max cap/tran and the tool would be forced to insert buffers downstream from the ICG as a result.

    To check whether this might be the case, check for dont_touch (and dont_use while you're at it):

    encounter 11> get_property [get_lib_cell <name_of_your_icg_cell>] is_dont_touch
    encounter 12> get_property [get_lib_cell <name_of_your_icg_cell>] is_dont_use 

    If this is the case, you'll want to relieve the dont_touch/use markings within the tool to enable CTS to resize the ICG to avoid making downstream buffer insertion necessary.

    Just something else to consider in conjunction with icg cloning.

    -Bob

Reply

  • Hi maven,

    I downloaded and viewed your attachment. Thanks for sending that. I think we're aligned on the fundamental challenge presented here.

    I think the tool is inserting buffers downstream from the ICG for a reason. Either it needs to satisfy max cap/max tran -or- it is seeking to minimize overall insertion delay. One thing that occurred to me is that perhaps your ICGs are marked dont_touch in the .lib?  It's fairly common that the ICGs would be marked by the library provider as such.  The reason I think this could be relevant is that if the ICGs were marked dont_touch, it would disallow the tool from upsizing the ICG to meet max cap/tran and the tool would be forced to insert buffers downstream from the ICG as a result.

    To check whether this might be the case, check for dont_touch (and dont_use while you're at it):

    encounter 11> get_property [get_lib_cell <name_of_your_icg_cell>] is_dont_touch
    encounter 12> get_property [get_lib_cell <name_of_your_icg_cell>] is_dont_use 

    If this is the case, you'll want to relieve the dont_touch/use markings within the tool to enable CTS to resize the ICG to avoid making downstream buffer insertion necessary.

    Just something else to consider in conjunction with icg cloning.

    -Bob

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.