Clock grouping techniques/ methodology

 you are asking a very general question.  There is no single CTS technique/flow that solve all the clock skew problem.  First thing, do you really care about the clock skew if your design meet timing with OCV.  If you do, you better know which group of flops should have very tight skew (get your RTL designers involve).  If you don't know you clock tree structure, you can use "clockDesign -check" to report the clock tree structures (after you load in the clock spec file) and get some insight info on why simple/complex is the design clock tree.  Always start with the tool default flow and then fine tune the clock SPEC to get the result you want.

li siang

Hi Li Siang,

Thanks for your inputs on the subject.

When a tool like encounter can generate a clock tree specification file with clock grouping (feature available from 8.1 ??), it has to internally use some algorithm/methodology to do the same. What would be the factors considered ? Please do share it if its possible.

Thanks

Rajesh

Hi Rajesh,

If I had no idea which clocks needed to be balanced, I'd run without any clock groups and then time the design after "optDesign -postCTS".  I'd then look at the failing paths and examine if they were caused by paths that started in one clock domain and ended in another clock domain.  If they were caused by this circumstance, I'd check whether the violation was caused by excessive skew.  If so- I'd try grouping the clocks.

If we wanted to be more sophisticated about this, we could identify these with Global Timing Debug and/or a CTE-TCL script.  I've never attempted such an automated approach- I usually just identify them interactively as I go through the timing closure process.

Another approach would be to time the design prior to CTS (with timeDesign -prePlace, or in our synthesis tool) to check if there are *any* data paths that go between various clock domains.  If there are, we could balance them right from the start.  A downside to this approach is that you could potentially build trees with quite a bit of latency for balancing purpose for paths that could be fixed through other means (like data path optimization, or useful skew for example).

Hope this helps,
Bob