• 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. Digital Implementation
  3. deciding insertion delay and clock skew.

Stats

  • Locked Locked
  • Replies 2
  • Subscribers 92
  • Views 26049
  • 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

deciding insertion delay and clock skew.

gops
gops over 15 years ago

Usually in a clock tree file we need to provide the values of insertion delay and skew values.I have read , that its usually advisable to give 10% of clock period for minimum skew value if the chip is not much big in size and we can go below to 5% as chip size increases.Anyway the skew value is dependent on the technology also.If I make the skew value to a low value it will make my design consume high power, because of the clock  buffers needed to attain the skew value.So someone please throw some ideas how the skew value and insertion delay values can be chosen for a design.

I know the defenitions of both and also I know the skew value can't be more than the clock period.So please give me a clear answer from your experience, How I can decide a safe skew value for the clock which will meet the timing with minimum power consumption.

  • Cancel
Parents
  • jagadishbvn
    jagadishbvn over 8 years ago

    Latency depends on the no of flops w.r.t that clock domain and pre-cts logic depths . If you pre-cts logic depth is high (more cts logic in the clock paths because of more controller logic added such as MUX , AOI ) then obviously your latency will be high .Assuming there is less logical cells from the cts root to the flops , the latency depends on the no of flops and the type of floor plan i.e your clock root pin placement and so on.There is no hard and fast rule , however the best possible way is to see how much latency you see when you do only drv fixing on clock paths in  cts .This option is available with the ccopt where its does only drv fixing and not skew. With this you can see the max latency seen from the clock root , if this latency is acceptable  and is required for the drv fixing assuming the placement of the flops is  appropriate  then it is  feasible to set  this as the max latency for your design . Coming the skew (global)  , you can blindly set it to 10% of clock period for initial analysis  but  is   technology dependent (foundry , PVT , ocv etc) and design dependent  ( ex processor and high speed data paths need very less skew to meet timing) where you cant compromise over the  skew .

    • Cancel
    • Vote Up 0 Vote Down
    • Cancel
Reply
  • jagadishbvn
    jagadishbvn over 8 years ago

    Latency depends on the no of flops w.r.t that clock domain and pre-cts logic depths . If you pre-cts logic depth is high (more cts logic in the clock paths because of more controller logic added such as MUX , AOI ) then obviously your latency will be high .Assuming there is less logical cells from the cts root to the flops , the latency depends on the no of flops and the type of floor plan i.e your clock root pin placement and so on.There is no hard and fast rule , however the best possible way is to see how much latency you see when you do only drv fixing on clock paths in  cts .This option is available with the ccopt where its does only drv fixing and not skew. With this you can see the max latency seen from the clock root , if this latency is acceptable  and is required for the drv fixing assuming the placement of the flops is  appropriate  then it is  feasible to set  this as the max latency for your design . Coming the skew (global)  , you can blindly set it to 10% of clock period for initial analysis  but  is   technology dependent (foundry , PVT , ocv etc) and design dependent  ( ex processor and high speed data paths need very less skew to meet timing) where you cant compromise over the  skew .

    • 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