clock gating cell约束

在某个clock的驱动源处手动加入lib中集成clk gating cell，在脚本中设置了dont_touch，综合出来timing显示gating cell的ECK（输出时钟端）为非ideal network，所以ECK到DFF CK pin的delay特别大，又在约束脚本中加入了set_ideal_network [get_pins xxxxxx/gatingcell/ECK]，ECK到DFF CK pin的delay变成0了，但是gating cell CK pin(时钟输入端）到ECK仍有延时，虽然较小，但是仍影响时序分析和优化，怎样设置可以使得CK to ECLK的delay=0，时序调整在CTS时候做?

如果在DC里面的设定没错的话，不应该出现这种情况
是不是lib没有定义好?

lib的定义没有问题，scripts中通过set_clock_gating_style设计的clk gating，DC在syn时候自动加入了clk gate，这个clk gate是我在clk source处RTL代码中手动加入的，例化了一个clk gate cell，clk net的ideal属性到这个cell的时候截止了，由于该cell属于多端口而且是时序cell，因此在其输出端ECK就没有ideal net 属性了，看来dc在syn的时候不认为这个cell是clk gating，跟dc自动加入的clk gating cell还是有点区别的，虽然都是一个东西。在ECK输出的net上设置了ideal net，但是这个clk gate cell本身仍有延时，有没办法把这个cell的延时给强制设成零?

可以用set_annotated_delay强制为0
但是我还是觉得你的设计哪里有问题

那里有问题?多谢！

对不住，你的信息不够，我无法判断。
既然你希望强制为零，就试试那个方法。
等你以后有时间了，再去研究为什么你的ideal clock的属性没有穿过gate clock cell吧

会不会是lib中cell的属性定义不够精确

为啥不在clock source端set ideal network呢
就是 整个clock的源端

ideal 属性能穿过门的前提条件是，这个门的所有输入是ideal属性或者这个门是ideal属性，则这个门的输出是ideal的

原来如此，哈哈。好题材

report cell看看加入的clock gate的属性，估计是black box，且是一个sequential cell，所以idea network 属性没有propagation。这个原因不清楚，如果你找到了，请分享出来。
除了你说的方法外，还可以在clock gate处再generate一个clock，这样会把clock gate cell看成一个endpoint，从generate clock出分析。或者设置high_fanout_net_pin_capacitance属性。

ECK到DFF CK pin的delay为什么要屏蔽掉呢?这个延迟可以不做考虑?

学习了

我认为这个问题应该是因为没有设置set_ideal_network 给clock的source点吧。因为不管是手动在RTL中例化的ICG还是DC自己加的ICG，他们的ECK上的ideal_net 都是false的。但是这并不会影响report_timing时register的CK端的“clock network delay (ideal)” 的情形。这个delay还是会为0的。我猜小编遇到的问题应该是report_timing -through ICG_CELL/ECK这样的报告中，在这种report里，确实是会看到ICG cell的delay的。