Stats

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

    Thanks for giving the script a try. I think you are understanding how it works correctly.

    It sounds like you're missing timing by -1ns postCTS. It would be useful to know, for your worst paths, whether this is caused by significant clock skew on a path ending on an ICG enable pin.  If it is, then this script will give you insight into whether the tool could do a better job optimizing these paths preCTS than it can postCTS.  You indicated there is no significant improvement- so that implies that the problem can't really be solved by enabling the tool to see the violations preCTS. 

    Are these paths meeting timing preCTS? If so, it would indicate that there was approixmately a 1ns skew on paths ending on ICGs, which would also imply that the clock is arriving at certain ICGs 1ns earlier than the downstream flops it drives.  That is a very large delay, and it sounds like we need to fundamentally seek a way to resolve the situation whereby so much downstream delay occurs after the ICG.  What is the fanout from the output of the ICG to the downstream flops it drives in cases where there is such bad skew?  If it is large (greater than 10) then I'd recommend pursuing cloning. If it is small (less than 10) then I'd recommend seeking to understand why "setPlaceMode -clkGateAware true" didn't place the ICG at the center of gravity of the downstream flops it drives.

    Thanks,
    Bob

Reply

  • Hi maven,

    Thanks for giving the script a try. I think you are understanding how it works correctly.

    It sounds like you're missing timing by -1ns postCTS. It would be useful to know, for your worst paths, whether this is caused by significant clock skew on a path ending on an ICG enable pin.  If it is, then this script will give you insight into whether the tool could do a better job optimizing these paths preCTS than it can postCTS.  You indicated there is no significant improvement- so that implies that the problem can't really be solved by enabling the tool to see the violations preCTS. 

    Are these paths meeting timing preCTS? If so, it would indicate that there was approixmately a 1ns skew on paths ending on ICGs, which would also imply that the clock is arriving at certain ICGs 1ns earlier than the downstream flops it drives.  That is a very large delay, and it sounds like we need to fundamentally seek a way to resolve the situation whereby so much downstream delay occurs after the ICG.  What is the fanout from the output of the ICG to the downstream flops it drives in cases where there is such bad skew?  If it is large (greater than 10) then I'd recommend pursuing cloning. If it is small (less than 10) then I'd recommend seeking to understand why "setPlaceMode -clkGateAware true" didn't place the ICG at the center of gravity of the downstream flops it drives.

    Thanks,
    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.