icc2/innovus关于reg2icg的较详细的解决方案（二）

话接上文，前面的文章，我们已经介绍了为什么reg2icg容易产生setup的violation，以及针对这个情况，我们应该在实际项目中如何实现解决这种类型的违例。

回顾一下，上文介绍了两种办法，分别是在place阶段设置set clock latency以及set clock gating check这两种命令。

1.set clock latency这个是直接作用于timing path上的network delay的，目的就是让工具提前预估cts阶段tree的变化，关于这个命令，我说一下我自己的见解：

比如我们在解决一些reg2reg的timing violation的时候，startpoint 的上一级setup有足够的margin，hold也是满足的，此时我们可以借timing，尽管在place阶段不考虑hold以及tree，但是后续阶段总归是要考虑的，我们根据cts或者route阶段的时序结果，进行认为的useful skew操作，如果我们对startpoint进行设置clock latency的话，此时的violation是-70ps，那么我们可以写成：

set clock latency -0.1 [get_pins startpoint/ck]

这个含义就是告诉工具说后续的阶段会把这个地方的tree做短100ps的，你不必花费太多精力在这个path上，去多多的优化其他path的data吧，在我的理解里，工具的精力和权重是有限的，无法考虑的那么全面和详细，需要我们进行告诉一下，毕竟她怎么知道后续这个path可以被干掉呢？

2.set clock gating check 上一节已经讲得很详细了，我认为其实在pr阶段不用remove掉这个gating check数值，保留着吧，可以始终过约，前提是reg2icg的问题比较多且严重下，可以这么搞，其他的话，还是在cts之后进行remove掉吧，让工具写上正确的lib setup time。

3.early global tree

在place阶段进行预做tree处理，目的就是让工具在布局的时候，对reg以及icg单元的摆放尽量的靠近一点，我搭配着使用的命令是：

set_app_options -name place_opt.flow.trial_clock_tree -value true​

set_app_options -name place_opt.flow.clock_aware_placement -value true​

set_app_options -name place_opt.flow.optimize_icgs -value true

大概解释一下就是：

工具在布局阶段 模拟时钟树的拓扑结构和延迟（不实际生成时钟树），从而：

预估时钟路径的延迟和偏差，指导寄存器和其他时序关键单元的摆放。避免后期CTS后出现意外的时序违例

启用 时钟感知布局（Clock-Aware Placement），优化寄存器与时钟门控单元的位置

最后进行模拟绕线，对reg2icg的时序进行提前模拟，从而进行再优化

总结起来就是：

先提供时钟网络的预估模型，利用该模型优化寄存器/ICG的位置，最后再进一步细化时钟门控单元的布局和逻辑。

使用好之后，我们选择了同一条path进行比对

  launch 790ps   capture 370ps   data 890ps   slack -220ps

4.open some options to optimize reg2icg

这个是在icc2中，添加的一些可以优化关于icg单元的options，我所添加的如下：

set_app_options -name place_opt.flow.cts_icg_resynthesis -value true ​

 set_app_options –name cts.icg.timing_aware -value true  ​

set_app_options –name cts.compile.cell_relocation_with_banal_estimates -value true

然后也是对同一条path进行高亮，比对结果：

launch 750ps capture 410ps data 850ps slack -80ps

5.

set clock latency​​

set clock balance point​

set clock gating check

用上面三个命令叠加，操作之后，也是同一条path，进行比对，如下：

launch 710ps capture 390ps data 850ps slack -70ps​

最后再给出一个，什么都没有设置的白板run，也是同一条path进行比对：

launch 750ps capture 410ps data 890ps slack -130ps​

有耐心的朋友不知道是不是已经看到这里来了，我们通过讲理论，产生原因，分析理论，提出解决方法，最后进行实践，从而得出上面的结果，后面我们来分析一下，其实各位看这个结果，不用我多分析，只要认真看了的，应该心里都知道了各个方法的优点了，下面我来总结一下：

1.对于place预做tree的方法，可以看出来，物理距离是简短了不少，从205um到68um，但是data path还是比较长的，tree甚至还差了

2.加的一些icg的options，可以看出来，tree是没有变化，但是data是减少了很多，从而也使优化了reg2icg

3.通过设置的一些latency，可以看出来，launch短了，data短了，capture也相应的短了，但是这两者的skew值比之前小了，也是起到了优化作用

所以，这里进行猜想一下，是不是可以把early global tree和icg options以及clock gating check结合到一起来，会不会效果会好呢？这个我会进行try run一下，下一期给大家揭晓喔！

好啦，本期内容就到这里啦，还有一个open ccd/useful skew还有一个skew group没有写，这个就放在下一期写吧，一个一个字敲出来的，仿佛去年的时候在学校写毕业论文，疯狂敲键盘，如果觉得小弟我写的可以的话，麻烦点个赞，收藏一下，一起学习，一起进步，为中国半导体事业做贡献！