试用CCOpt Native三天的心得体会

aiwen123

谢谢楼主分享

joemool

****************时钟树的约束格式*****************

原来的CTS用ctstch文件作为约束，而CCOpt Native直接用命令进行约束，命令基本都能跟ctstch对应上。比如原来的AutoCTSRootPin对应create_ccopt_clock_tree，等等。
无论是原来的CTS还是CCOpt Native，Encounter都提供了sdc转时钟树约束的功能，不过用它做出来的时钟树质量基本是娱乐级的...还是自己重新写一套约束比较好。

Joemool: 娱乐级，别搞笑了好吗？ 如果不是你SDC定义不充分，你有必要自己去定制ctstch文件吗？Native CCOPT的CTS部分EDI14.20才正式上马作为默认的CTS引擎，请别乱喷好吗？话说你如何来评价时钟树的质量，请别告诉我skew要小好吗？

*********对需要减小insertion delay寄存器的约束*********

对某些关键路径的寄存器，或是为了优化reg2out，或是为了减小OCV冲击，我们会希望它们的insertion delay尽可能小。在原来的CTS中，我们会通过定义正的MacroModel来将这些寄存器提前，但定义的值很难把握，稍有不慎就会使主时钟树被额外地推后。在CCOpt Native中，可以对这些寄存器创建一个Skew Group，把这个Skew Group的target_insertion_delay设为一个很小的值，工具会自动把这些寄存器提到最前。

Joemool：求你别乱误导大家好吗？原来的MacroModel约束，在Native CCOPT里面是set_ccopt_property -pin <pin_name> insertion_delay <value>，而不是target_insertion_delay好吗？后者等于ctstch里面的MinDelay好吗？Insertion delay有很多种，target insertion delay，Network insertion delay，pin insertion delay。MacroModel近似于pin insertion delay，是一个offset value，不是一个targer value，好吗？不懂就不要误导。

*********对需要增加insertion delay寄存器的约束*********

在原来的CTS中，我们会定义负的MacroModel来将这些寄存器推后。在CCOpt Native中，同样是对这些寄存器创建一个Skew Group，把这个Skew Group的target_insertion_delay设为你期望的推后值即可。

与原先相比的改进是，CCOpt Native中可以定义Delay Cell用来推后时钟（当然， 需要库里有上下沿平衡的Delay Cell），以节省面积和功耗。原来的CTS中要想工具自动调用Delay Cell是很困难的。

Joemool：同上。

**************隔离非关键寄存器的约束***************

在原来的CTS中，我们会把非关键寄存器丢到LeafPinGroup中，并通过一个小的ExcludeBuffer进行隔离，以防止对非关键寄存器的平衡降低主时钟树的性能。但有个局限是，一个设计中的寄存器通常并不能非黑即白地划分为“关键”和“非关键”，还有一些“次关键”寄存器，我们既不希望它们拖慢主时钟树，又不希望这些寄存器被太小的ExcludeBuffer过多地推后。问题是，ExcludeBuffer只能定义一个Cell，而且一旦被丢进LeafPinGroup，各项优化的优先级都会被降到最低。

在CCOpt Native中，只需对关键/次关键/非关键寄存器创建各自的Skew Group，设置好期望的insertion delay值即可。当开启advanced_insertion_delay_optimization和recluster_to_reduce_power两个变量后，工具会自动对“次关键”寄存器用大Buffer/Inverter隔离，“非关键”寄存器用小Buffer/Inverter隔离，非常智能。

Joemool：set_ccopt_property add_exclusion_drivers true

*********手动设置target insertion delay的意义**********

CCOpt Native在智能度大大改善的同时，还提供了相当多的手工约束命令，乍一看甚是吓人...为什么工具可以全自动完成，还要手动设置insertion delay，这要从CCOpt Native的流程来看。CCOpt Native的流程大致可描述为initial cluster -> optDesign -> adjust skew -> optDesign -> adjust skew...（循环）。如果不手动设置target insertion delay，那工具在initial cluster时会把时钟做成完全平衡的，这时跑optDesign会把datapath往错误的方向优化，很可能后面就回不来了...手动设置target insertion delay后，initial cluster就会把时钟做成你设置的skew值，第二步的optDesign就会收敛得非常快了。

手动设置的target insertion delay不需要特别精确，因为后面的adjust skew步骤里工具会自动帮你Fine Tune。

Joemool：preCTS开useful skew，得到虚拟latency的SDC，CCOPT自动转化为pin insertion delay，initial cluster直接就看到这个delay。还是那句话，强壮而丰满的SDC，让你事半功倍。

***************对Debug的一点Tips*****************

如果你刚刚接触CCOpt Native，那么建议打开ccopt_worst_chain_report_timing_too变量，在每一轮optDesign之后都会报一个timeDesign出来，这时候就可以进行Debug了，而不必等到整个CCOpt Native跑完。

Joemool: 这个debug变量只是九牛一毛。

******************QoR的改变********************

在以前CTS的流程中，preCTS的时序约束通常需要比postCTS更紧，收紧的值约等于时钟树skew值，因为skew可能会劣化Timing。

在CCOpt Native中，postCTS的约束甚至可以比preCTS再紧一点，因为所有的skew都是有益的。这确实是非常令人惊讶的QoR提升...

（以preCTS时序约束中Clock Latency已反标为前提）

Joemool：请直接调用postCTS SDC，注意改回ideal mode。

*****************一点改进建议********************

CCOpt Native这种针对Critical Chain的优化，是不能应用于同步链的（如果同步链的skew被借出去就会损MTBF，虽然Timing看起来是Clean的）。希望后续有方便点的方法来照顾同步链...

Joemool：你说的这种情况优先级不高，timing clean才是王道，客户才happy。


用了三天就来谈感想...
我不知道说你什么好。

Timme

****************时钟树的约束格式*****************

原来的CTS用ctstch文件作为约束，而CCOpt Native直 ...
joemool 发表于 2014-10-27 13:14

                               
登录/注册后可看大图

我们用CCOpt Native投的片子已经回来了，测着挺好的，时钟树功耗很小......


当时是用13.x开Limited Access Feature跑的。投片后也用14.x也跑过，感觉大同小异

给Skew Group设target_insertion_delay有没有效你自己试试就知道了，我们当时的SG有需要提前的有需要推后的，在Initial Cluster之后就能看到效果了。

joemool

运气好而已

Timme

运气好而已
joemool 发表于 2014-10-28 10:10

                               
登录/注册后可看大图

Joemool: 娱乐级，别搞笑了好吗？ 如果不是你SDC定义不充分，你有必要自己去定制ctstch文件吗？Native CCOPT的CTS部分EDI14.20才正式上马作为默认的CTS引擎，请别乱喷好吗？话说你如何来评价时钟树的质量，请别告诉我skew要小好吗？

SDC对应的是时钟的逻辑结构，ctstch对应的是时钟的物理结构，两者对不上是很正常的。如果你说的是对的，SDC足以约束整个时钟树，那create_ccopt_clock_tree这些命令就完全是多余的了，因为CCOpt引擎可以看到SDC。

评价时钟树质量，可以看主干分岔点是否过早、关键寄存器的级数是否最少且Size合理、Leaf寄存器分组是否合理，更细一点还可以看Critical Edge优化得好不好，比如正沿触发的关键寄存器前一级是否用上升沿比较快的BUF/INV、负沿触发的关键寄存器前一级是否用下降沿比较快的BUF/INV（UHD的的单元即便是CLKINV上下沿也不会平衡得非常好）。。。等等很多。反正跟skew没什么关系，又不是Mesh。

Joemool：求你别乱误导大家好吗？原来的MacroModel约束，在Native CCOPT里面是set_ccopt_property -pin <pin_name> insertion_delay <value>，而不是target_insertion_delay好吗？后者等于ctstch里面的MinDelay好吗？Insertion delay有很多种，target insertion delay，Network insertion delay，pin insertion delay。MacroModel近似于pin insertion delay，是一个offset value，不是一个targer value，好吗？不懂就不要误导。

我从来没说过MacroModel和target_insertion_delay等价，我说的是为了达到寄存器提前或推后这个结果，CTS可以用MacroModel，CCOpt可以创建SG并设置target_insertion_delay，不管是offset还是绝对值，最后达到的效果是类似的。

insertion_delay是针对Pin的属性，target_insertion_delay是针对SG的属性，两者不能互换，如果对SG设insertion_delay，会报Error。

get_ccopt_property target_insertion_delay -help的解释是：该SG的insertion delay会被实现为设置值正负target_skew，并没说不能提前、只能推后。

Joemool：set_ccopt_property add_exclusion_drivers true

14.1 get不到这个属性

Joemool：preCTS开useful skew，得到虚拟latency的SDC，CCOPT自动转化为pin insertion delay，initial cluster直接就看到这个delay。还是那句话，强壮而丰满的SDC，让你事半功倍。

你这个做法相当于用useful skew的引擎来指导CCOpt，而useful skew引擎的智能程度本身就比CCOpt要低一级，有点胳膊指挥大脑的感觉。再者，用RCP或DCT做物理综合时怎么办？它们没有Useful skew这个东西，是基于Critical Path的，和CCOpt的Critical Chain的Correlation非常差；而preCTS虽然有Useful skew，但再综合能力非常弱，直接吃没加Latency物理综合出来的网表，QoR非常差。还是你想告诉我跑个preCTS拿Latency SDC丢回给物理综合引擎用？

Joemool：你说的这种情况优先级不高，timing clean才是王道，客户才happy。

同步链MTBF出问题芯片就是一块铁，客户的竞争对手应该会很happy。
其他CTS引擎由于默认是平衡的，没有出现这个问题的潜在可能性。

运气好而已

我们这次运气的确很好，但跟主楼说的都没有关系。我们在投片后才发现SRAM的Lib不全，CK->Q只有Delay时间没有Retain时间（很多国内的Memory Compiler提供商都有这个问题），这时候算的Hold是不准的，报告很漂亮但是是假的。根据SRAM结构不同，Retain时间有可能低至Delay的1/3，OCV Derate根本Cover不了。其他CTS引擎因为默认是平衡的而且SRAM输出又很慢，就算不标Retain也没有Hold实际违规的潜在可能性，但CCOpt为了降低时钟树功耗，非常激进地“偷”掉了很多这个SRAM输出到下级寄存器的正的Hold Slack。。。反正片子回来没问题，的确有运气成分。

wlztteng

回复 1# Timme


    关于SDC command map to CCOpt有一些不懂：

BTW:CTS引擎对这些SDC中的约束又做什么样的解读。
SPEC文件是根据netlist和sdc得出来的，那么tools是从netlist和sdc中读入那些有用的信息，以此来写出严格的spec来做时钟树综合，如果时钟树比较复杂，我们需要手动的调整SPEC，又该根据netlist和sdc中那些信息来手动调整SPEC呀？

wlztteng

回复 1# Timme


    对于在CCOpt中提出一个worst chain概念，因为CCOpt可以在一个chain上面shifting slack，因此timing constraint 不再局限于flop to flop之间做优化，而可以将slack在一个chain之间一级一级的shift，从而使得phsical opt更加的easier。
   但是time borrowing 并不是无限制的，两种情况下不能借用：
     情况一:when the logic chain  loops back on itself
     情况二：when the logic chain reaches an IO pin.
因此也就将分为四种类型的chain：

    IO chain – a chain of flops starting at an input pin and ending at an output pin.
    Input-to-loop chain – a chain of flops starting at an input pin and ending at a looped path.
    Loop-to-output chain – a chain of flops starting at a looped path and ending at an output pin.
    Looping chain – a chain of flops starting and ending at a looped path.

问题一：为什么对于loop chain不能无限制的借用，是因为在无限制借用的时候借到最后又循环到其本身吗？
问题二：对于IO pin不能借用是因为要给外面的接口时序留出足够的 positive slack吗？
问题三：什么样的逻辑会综合成一个loop chain结构的网表，对于这种结构，我们再STA时需要注意哪些东西？在OPT时又需要做哪些设置？

caesars82

回复 15# Timme


   顶Timmer
关于pre cts useful skew这段，有个问题想问问：pre cts useful skew由于只是算skew，并没有与ck cell的delay相对应，因此，即使设置了-minAllowDelay，得出的skew值，也很难应用于CTS使的macro model，往往反而使CTS的clock latency相当长，所以，我们普遍都不用pre cts useful skew。

后来，我自己写了个脚本，大致流程如下：先不加macro model，自动长一版CTS，然后，用脚本抓出所有的endpoint violation path，再看这些有violation的endpoint，它们的后一级是否有余量，如果有，就把后一级的余量，分一半，给这个endpoint，分的这一半的余量，就作为macro model，设到该endpoint的ck端，然后再加载该macro model文件，重新长CTS。做出的效果，还可以。

我的问题是，用CCOPT方式后，以上作法，生成的macro model，还有没用处？是否就是用target insertion delay的方式，将这些macro model的值，设置给CCOPT，然后再做？同时，由于CCOPT和CTS的原理并不同，我比较疑惑，如何用脚本抓这些macro model，仍然先用普通CTS的方法长一次CTS，然后再抓，再把抓出的macro model值，作为target insertion delay，用CCOPT的方式，重新来做时钟树？Timmer一般是怎么决定将哪些reg丢到同一个SG里，然后怎么定该SG的target insertion delay值的？

caesars82

再补充问个问题，怎么让CCOPT native只做cts，不做post-cts opt？CCOPT script mode可以设置，但native mode没找到设置方法。我想先只做cts，根据cts后的情况，抓出有violation的reg，在这些reg的ck端，设置insertion delay，再用这个insertion dealy重新做CCOPT，并修timing，不知道这方法可行不？

Timme

回复 18# caesars82

首先，即便不用prects useful skew，不设置任何insertion delay，CCOpt也会自动帮你调节skew来优化时序，即已经完全涵盖了你脚本所做的行为，还会做得更多。

但是这个过程会比较漫长（因为在没有外部设置insertion delay的情况时，CCOpt所做的跟你类似，也是先做个平衡的树出来，再根据时序报告多次迭代调整skew，不能“一步到位”），而且QoR不会最优，主要是受制于GigaOpt的再综合能力较弱（相比于RCP/DCT），不是CCOpt的问题。

我们现在采用2-pass flow，先用预估的Latency进行物理综合和prects，跑CCOpt做完Fine Tune，得到精确的Latency值，再反标丢给物理综合，走第二轮PR，这样Correlation会很完美。

至于SG怎么划分，还有最初的Latency如何预估等等，要求对RTL比较熟悉，否则就只能很被动地根据冒出来的违规路径进行调整了。由于我是前后端通吃的，所以......

script mode我从不在实际项目中使用。因为它只支持一条命令跑到底的傻瓜模式，出了问题没有任何人为干预的余地，只能干瞪眼。

至于Native下只做cts，由于我这边Native+GigaOpt用得很爽，没这个需求，所以没研究过...