Stats

  • Locked Locked
  • Replies 10
  • Subscribers 92
  • Views 17182
  • 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 tree quality

Rajesh Vembu

What are the metrics (physical and timing-related) that determine if the clock tree built is robust and of good quality?

If i want to compare the clock tree quality built using 2 different clock tree spec files, what would be the steps to follow?

It should be noted that the AutoCTSRootPin definitions in the 2 spec files could be different, hence a one-to-one comparison of the clock tree report (generated using reportClockTree) won't be helpful.

 - Rajesh

Parents

  • Hi, Rajesh,

    From timing consideration, if a clock tree make the timing closure easier or could make it with larger margin (for example, allow larger clock uncertainty), then, I will think this clock tree is better.

    Generally, timing closure is the first priority, therefore, the above criterion is the king.  Also, other factors may get in. such as insertion delay (or level of clock tree). Too large the insertion delay (or too many clock tree level) may create other issues like power assumption, OCV, routing conggestion (sometimes, we need to use wider wires, larger space, and even shield for clock wire).  So, physically, I like the clock tree as simple as possible.

     Another thing I will look into it is the final standard cell density in the block  and total routing wire length after timing closure.  If the clock tree is not perfectly fit into the design, the hold timing opt may add thousands and thousands of buffers/inverters and therefore, make the block very crowded, which may even impact the routability of the block. So, check the density and total routing wire length after the timing closure achieved.

    - Gele

Reply

  • Hi, Rajesh,

    From timing consideration, if a clock tree make the timing closure easier or could make it with larger margin (for example, allow larger clock uncertainty), then, I will think this clock tree is better.

    Generally, timing closure is the first priority, therefore, the above criterion is the king.  Also, other factors may get in. such as insertion delay (or level of clock tree). Too large the insertion delay (or too many clock tree level) may create other issues like power assumption, OCV, routing conggestion (sometimes, we need to use wider wires, larger space, and even shield for clock wire).  So, physically, I like the clock tree as simple as possible.

     Another thing I will look into it is the final standard cell density in the block  and total routing wire length after timing closure.  If the clock tree is not perfectly fit into the design, the hold timing opt may add thousands and thousands of buffers/inverters and therefore, make the block very crowded, which may even impact the routability of the block. So, check the density and total routing wire length after the timing closure achieved.

    - Gele

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.