微波EDA网,见证研发工程师的成长!
首页 > 研发问答 > 微电子和IC设计 > IC后端设计交流 > 试用CCOpt Native三天的心得体会

试用CCOpt Native三天的心得体会

时间:10-02 整理:3721RD 点击:

首先CCOpt Native上手就要比原来的CTS要难很多,主要是跑一次的时间太长了。原来的CTS做完一次再Debug耗时较短(如果每次只做一个时钟就更快了),而CCOpt Native跑一次就是CTS + PostCTS optDesign的时间,完全不给人Try Run的机会...
以下介绍一下从原来的CTS切换到CCOpt Native的一些心得体会
****************时钟树的约束格式*****************
原来的CTS用ctstch文件作为约束,而CCOpt Native直接用命令进行约束,命令基本都能跟ctstch对应上。比如原来的AutoCTSRootPin对应create_ccopt_clock_tree,等等。
无论是原来的CTS还是CCOpt Native,Encounter都提供了sdc转时钟树约束的功能,不过用它做出来的时钟树质量基本是娱乐级的...还是自己重新写一套约束比较好。
*********对需要减小insertion delay寄存器的约束*********
对某些关键路径的寄存器,或是为了优化reg2out,或是为了减小OCV冲击,我们会希望它们的insertion delay尽可能小。在原来的CTS中,我们会通过定义正的MacroModel来将这些寄存器提前,但定义的值很难把握,稍有不慎就会使主时钟树被额外地推后。在CCOpt Native中,可以对这些寄存器创建一个Skew Group,把这个Skew Group的target_insertion_delay设为一个很小的值,工具会自动把这些寄存器提到最前。
*********对需要增加insertion delay寄存器的约束*********
在原来的CTS中,我们会定义负的MacroModel来将这些寄存器推后。在CCOpt Native中,同样是对这些寄存器创建一个Skew Group,把这个Skew Group的target_insertion_delay设为你期望的推后值即可。
与原先相比的改进是,CCOpt Native中可以定义Delay Cell用来推后时钟(当然, 需要库里有上下沿平衡的Delay Cell),以节省面积和功耗。原来的CTS中要想工具自动调用Delay Cell是很困难的。
**************隔离非关键寄存器的约束***************
在原来的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隔离,非常智能。
*********手动设置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。
***************对Debug的一点Tips*****************
如果你刚刚接触CCOpt Native,那么建议打开ccopt_worst_chain_report_timing_too变量,在每一轮optDesign之后都会报一个timeDesign出来,这时候就可以进行Debug了,而不必等到整个CCOpt Native跑完。
******************QoR的改变********************
在以前CTS的流程中,preCTS的时序约束通常需要比postCTS更紧,收紧的值约等于时钟树skew值,因为skew可能会劣化Timing。
在CCOpt Native中,postCTS的约束甚至可以比preCTS再紧一点,因为所有的skew都是有益的。这确实是非常令人惊讶的QoR提升...
(以preCTS时序约束中Clock Latency已反标为前提)
*****************一点改进建议********************
CCOpt Native这种针对Critical Chain的优化,是不能应用于同步链的(如果同步链的skew被借出去就会损MTBF,虽然Timing看起来是Clean的)。希望后续有方便点的方法来照顾同步链...

小编用的是EDI哪个版本? 稳定么?

ccopt 是edi 1x,x的标配了,今后版本都有的, 肯定是好于以前的cts,否则不是白收购了,

joemool小编专门研究这个的,你们可以好好谈论下,呵呵

收藏借用了,以后多多分享喔~

之前一直感叹ICC在CTS的时候,手工干预比较EDI好。
现在终于有有学习的方向了,感谢!
立刻开始学习中!

也请原谅我们使用的EDI版本比较老!

感谢小编列举了传统CTS和CCOPT的对比,也列出了一些设置的mapping,但是对于传统CTS中的一个常见做法,应该怎处理呢?比如设计中存在DFT,func clock和scan clock经过mux,那么可能分两段来做CTS,先做func clock,设为Dont touch,再做scan clock,吃进去func clock对应的macromodel。这种做法在ccopt中怎么实现会好一些?ccopt可以用多cpu或者线程吗?

不明觉历

好东西,谢谢分享!

谢谢小编分享

****************时钟树的约束格式*****************
原来的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。

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

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

当时是用13.x开Limited Access Feature跑的。投片后也用14.x也跑过,感觉大同小异
给Skew Group设target_insertion_delay有没有效你自己试试就知道了,我们当时的SG有需要提前的有需要推后的,在Initial Cluster之后就能看到效果了。

运气好而已

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。反正片子回来没问题,的确有运气成分。

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

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

对于在CCOpt中提出一个worst chain概念,因为CCOpt可以在一个chain上面shifting slack,因此timing constraint 不再局限于flop to flop之间做优化,而可以将slack在一个chain之间一级一级的shift,从而使得phsical opt更加的easier。
但是time borrowing 并不是无限制的,两种情况下不能借用:
情况一:when the logic chainloops 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时又需要做哪些设置?

顶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值的?

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

首先,即便不用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用得很爽,没这个需求,所以没研究过...



受兄启发,这三周,用CCOPT评估了一个block,觉得,确实CCOPT很强大,大致分享下心得。
用来评估的设计如下:80W+ standard cell,无power domain,近100块RAM,无其它IP。
用CCOPT前,post-route结果如下:utilization 51%(评估用,面积划的大了点,呵呵)。LVT% = 14%。timing能修完。
一直想把LVT%降下来,但试了很多方法,都无法降下来。受Timme启发,先做一轮到CCOPT fix timing,然后,用脚本抽出所有有violation的endpoint name及violation value。把这些值,返回给RCP,作为clock latency,用N2N的方法,重新优化一版网表。再用该网表及def,从placement开始做,一直跑到post-route opt结束。发现用RCP做N2N重新综合后,timing大大优化。N2N前后,各阶段的数据大致对比如下:pre-cts opt时,N2N前后,timing差别不大,都OK,是+100ps左右。post-cts opt后,差距就很明显了,不用N2N的,WNS/TNS = -290ps/-200ns,N2N+CCOPT后,WNS/TNS = -100ps/-30ns,感觉这个差距非常大,也许既有CCOPT的功劳,也有RCP的功劳,可能RCP的功劳更大。post-route opt时,不用N2N,打开LVT的,WNS/TNS = -30ps/-5ns,且LVT% = 14%。N2N后的,则直接修完,且LVT% = 3%。
从以上评估,感觉N2N+CCOPT,确实可以大大提高timing。也有以下心得:1. 用CCOPT时,关闭LVT。之前打开LVT用CCOPT,工具会先将SVT换为LVT,看timing OK了,就跳出,CCOPT根本未起作用,所以,做出的效果,和普通CTS几乎一样。关闭LVT后,CCOPT的效果,就完全体现出来了,会有多轮迭代,调skew来修timing。整个过程也不算慢,和CTS+post-cts opt差不多。 2. 用脚本抓出的endpoint violation path,不要作为insertion delay,直接给CCOPT,然后让CCOPT来重新优化,这样做出的结果,还不如什么都不设的好。用脚本抓出了2000+条有violation的path,估计PR工具要考虑的太多,把这2000+条path设给CCOPT后,无法兼顾,所以,优化结果反而更差。应该把这些path给RCP,进行N2N的opt,生成的网表,再重新进行placement及opt,这样得到的QoR,大大提高。应该是综合工具的优化能力,远强于PR工具的原因。3. CCOPT能看到derate,根据这个,来调skew,修timing,结果比CTS+post-cts opt的效果确实要好。普通CTS时,无法看derate,导致CTS时看到的skew还行,但在post-cts时看,就差了一截了,即使再用useful skew,效果也不如CCOPT的边CTS边useful skew opt timing来得有效果。4. 由于对设计不太了解,所以,未划分skew group,只是把CCOPT的所有设置都过了一遍,打开/关闭了一些参数,然后跑的CCOPT,感觉效果还不错。可能用了SG后,效果会更好。
以上就是大致的心得,以后N2N+CCOPT应该就是我做PR的标准流程了。欢迎Timme跟帖评论,看还有哪些可以进一步改进的。

原谅我没有太看懂,你将Violation Value作为Latency反标是何用意?依我的理解,这两个应该没有太直接的关系。
举个简单例子:时钟周期2ns,第一轮CCOpt后RegA的Insertion Delay是2ns,RegB的Insertion Delay是3ns,RegA到RegB的数据路径3.2ns,违规200ps。我们应该将RegA Latency 2ns、RegB Latency 3ns反标给RCP,或者按照相对值,只对RegB反标(3ns-2ns)=1ns的Latency,RegA保持默认的0 Latency也可以(但不推荐)。如果将违规值200ps作为Latency反标给RegB,那RCP看到的结果会完全不一样。

以该例子为例,我是用Setting attribute clock_network_late_latency -200ps,反标到regB的clk端,没有将regA的2ns和regB的3ns反标给RCP。目的是这样:根据CCOPT后的结果,看哪些路径无法修完,还差多少ps,就把这个violation再加紧一点,反标回去(比如-200ps的violation,再加150ps,变成-350ps,反标到regB的clk),让RCP先看到这段路径上的delay差值,然后预先进行优化。虽然这样看到的结果,确实不是时钟树综合后的真实clk tree长度,但达到了加紧约束的目的,让RCP预先按加紧的值进行优化。更有点类似于手工useful skew,看violation是多少,就把clk tree加紧一点,多优化一点。
Timme说的方法,我之前还确实没想到过,你的方法,是不是就应该在CCOPT后,把所有reg的clk tree的长度全部抽出来,然后反标给RCP,让RCP按照CTS后的真实结果,来做opt(如果只反标regA和regB的latency,那对于regB到regC的路径,regC的latency还是0ns,就相当于regB到regC的setup太过约束了)?这个方法确实更彻底,能看到所有的violation值。我的方法,可能反标了-350ps的latency后,那条路径在RCP看来,还是正的,所以,还是不会努力去修。
好,我再按你说的方法试试,抓出所有reg的clk latency值,反标给RCP,opt后,再给PR。也应该是将RCP新生成的netlist和def反馈给PR,然后去掉所有的clock latency,从pre-cts opt阶段开始做吧?

用同一版数据,分别试了反标clock latency给RCP及反标path violation给RCP,结果如下:
反标clock latency给RCP,重新综合后,在PR,直到CCOPT修完post-cts setup & hold,timing summary如下:
+--------------------+---------+---------+---------+---------+---------+---------+---------+
|Setup mode|all| reg2reg | in2reg| reg2out | in2out| clkgate | default |
+--------------------+---------+---------+---------+---------+---------+---------+---------+
|WNS (ns):| -1.302| -0.146|0.817| -1.302| -0.135| -0.126|0.000|
|TNS (ns):| -2203.9 |-144.786 |0.000| -2059.1 | -1.424| -5.871|0.000|
|Violating Paths:|4741|2801|0|1940|16|184|0|
|All Paths:|1.45e+05 |1.34e+05 |11510|1940|16|9982|0|
+--------------------+---------+---------+---------+---------+---------+---------+---------+
|wc_cworst| -1.302| -0.146|0.817| -1.302| -0.135| -0.126|0.000|
|| -2203.9 |-144.786 |0.000| -2059.1 | -1.424| -5.871|0.000|
||4741|2801|0|1940|16|184|0|
||1.45e+05 |1.34e+05 |11510|1940|16|9982|0|
+--------------------+---------+---------+---------+---------+---------+---------+---------+
+----------------+-------------------------------+------------------+
||Real|Total|
|DRVs+------------------+------------+------------------|
||Nr nets(terms)| Worst Vio|Nr nets(terms)|
+----------------+------------------+------------+------------------+
|max_cap|0 (0)|0.000|0 (0)|
|max_tran|17 (59)|-0.216|222 (2000)|
|max_fanout|564 (564)|-87|587 (587)|
|max_length|4770 (4770)|-2306|4770 (4770)|
+----------------+------------------+------------+------------------+
Density: 64.588%

反标path violation再做PR,结果如下:
+--------------------+---------+---------+---------+---------+---------+---------+---------+
|Setup mode|all| reg2reg | in2reg| reg2out | in2out| clkgate | default |
+--------------------+---------+---------+---------+---------+---------+---------+---------+
|WNS (ns):| -1.165| -0.039|0.791| -1.165| -0.167| -0.030|0.000|
|TNS (ns):| -1868.0 | -10.727 |0.000| -1857.2 | -1.437| -2.185|0.000|
|Violating Paths:|2693|753|0|1940|15|145|0|
|All Paths:|1.45e+05 |1.34e+05 |11510|1940|16|9982|0|
+--------------------+---------+---------+---------+---------+---------+---------+---------+
|wc_cworst| -1.165| -0.039|0.791| -1.165| -0.167| -0.030|0.000|
|| -1868.0 | -10.727 |0.000| -1857.2 | -1.437| -2.185|0.000|
||2693|753|0|1940|15|145|0|
||1.45e+05 |1.34e+05 |11510|1940|16|9982|0|
+--------------------+---------+---------+---------+---------+---------+---------+---------+
+----------------+-------------------------------+------------------+
||Real|Total|
|DRVs+------------------+------------+------------------|
||Nr nets(terms)| Worst Vio|Nr nets(terms)|
+----------------+------------------+------------+------------------+
|max_cap|0 (0)|0.000|0 (0)|
|max_tran|11 (66)|-0.327|203 (1811)|
|max_fanout|607 (607)|-32|639 (639)|
|max_length|5102 (5102)|-2525|5102 (5102)|
+----------------+------------------+------------+------------------+
Density: 63.937%

从结果看,反标path violation的,结果要好于反标clock latency的。至少就我目前这个设计来说,是这个结果,不知道算不算个例。对于新的设计,貌似这两种方法,都可以试试,兴许某种会更好。

这个好贴应该收藏一下,希望还有更好的方案出来继续讨论。

大家讨论的那么激烈,我也凑个热闹
(1) 关于工具自动产生CTS的spec,这里我也顶Timme一下。一般来前端的人写SDC,基本都是从逻辑和timing的角度来说,对时钟的物理关注得相对少些,比如改从哪里分叉,从哪里断开。所以不太可能写出一个完美的sdc既适合STA有和时钟树很吻合的。
(2) 对于CCopt使用的几个关注点,个人认为有以下3点
a. initial virtual clock tree的结构,这也就是Timme提到的target_insertion_delay, skew group的控制.
b. hold time 的控制,ccopt 最大一个risk就是用得过量后,导致hold 无法收敛。这个在multicorner下尤为麻烦。所以不要太贪心。
c. timing ECO , 原来大家习惯去在clock tree上加减buffer来fix timing的方法,在ccopt过的design上就很难用了。

感觉很牛的样子,小白学习

学习中.............

Thanks, Its nice info...

刚用ccopt,遇到些问题。
1.发现在database里生成了latency.sdc.在postcts优化后,计算timing,会考虑这个latency.
并且有负的latency,这样对吗?
2.ccopt -cts是否会优化skew,还是象传统cts一样只做clock tree?

Copyright © 2017-2020 微波EDA网 版权所有

网站地图

Top