clock gating paths

I think I know how you feel (wanting CTS to balance skew with respect to the clock pin of the ICG).  I felt the same way last time I was working through a scenario similar to this.  But I found that if I balanced to the clock pin of the ICG that the downstream registers driven by the ICG would have increased insertion delay relative to the rest of the registers in the design and as a result large skew.  It would just be pushing the problem to other paths in the design.

If you wanted to test that the theory that balancing to the clock pin of the ICG would be the right thing to do, you could specify the clock pins of the ICG lib cell(s) as LeafPorts in your clock tree spec file (but be aware that anything downstream from these points will not be buffered which I consider a problem that makes this approach unsuitable):

LeafPort
+ ICGX1/CK rising
+ ICGX2/CK rising

Similarly, I think marking the output nets of the ICGs dont_touch isn't suitable because it prevents the tool from optimizing in cases where buffering is required to reduce delay.

If I were looking at your design, I'd ask these questions:

What is the fanout of the ICGs in the cases where you're seeing a setup violation on the enable pin? If it is greater than 10 or so I would think this is a case where you'd need to do cloning. If it's less than 10 it seems like a case where the tool did a poor job placing the ICG at the center of gravity of the flops it drives (ie, "setPlaceMode -clkGateAware false" didn't work very well.)

Thanks,
Bob

I think I know how you feel (wanting CTS to balance skew with respect to the clock pin of the ICG).  I felt the same way last time I was working through a scenario similar to this.  But I found that if I balanced to the clock pin of the ICG that the downstream registers driven by the ICG would have increased insertion delay relative to the rest of the registers in the design and as a result large skew.  It would just be pushing the problem to other paths in the design.

If you wanted to test that the theory that balancing to the clock pin of the ICG would be the right thing to do, you could specify the clock pins of the ICG lib cell(s) as LeafPorts in your clock tree spec file (but be aware that anything downstream from these points will not be buffered which I consider a problem that makes this approach unsuitable):

LeafPort
+ ICGX1/CK rising
+ ICGX2/CK rising

Similarly, I think marking the output nets of the ICGs dont_touch isn't suitable because it prevents the tool from optimizing in cases where buffering is required to reduce delay.

If I were looking at your design, I'd ask these questions:

What is the fanout of the ICGs in the cases where you're seeing a setup violation on the enable pin? If it is greater than 10 or so I would think this is a case where you'd need to do cloning. If it's less than 10 it seems like a case where the tool did a poor job placing the ICG at the center of gravity of the flops it drives (ie, "setPlaceMode -clkGateAware false" didn't work very well.)

Thanks,
Bob