求助设计中有大量reg2reg的结构，中间没有任何组合逻辑，如何快速有效的fix hold？
我现在有一个100万的instance的设计，其中有20多万个reg，有很多流水线的结构，这样导致很多前一级的reg/Q直接接到了下一级的reg/D，类似于scan chain的接法，导致了大量的hold path，类似的path 有将近9万条，如果算上reg/Q --> reg/SI的话，有25万条，有什么方法能快速有效的fix hold?现在我的clk skew 有150ps ,是否需要降低?如果需要降低，方法是什么呢?
现在有一种方法是直接加 delay cell在hold path 上面，有建议是加三明治结构（buf+dly+buf),请问这个结构是必须的吗?还是可以直接加dly cell，我现在的工艺是tsmc40g。
hold工具修不掉，也只能手动加buffer了，可以加delay cell的，如果violation太大的话，
手动eco 加吧
亲，跪求tsmc40g那个库啊！~能不能给我发一份，太谢谢您了！~dreamylife@126.com
建议小编在Clock上下手，如果这些Path有共同的Clock Path的话。 9W条Path的确比较多，在Data Path上修，估计代价会比较大！
Hold 的Violation比较大吗?
先Check下SDC是否合理先。
是不是clock的ocv大了点，如果是共同clock的话，有DFF CK->Q的延时，不会有太多的hold vio吧
十来万条都手动修，好多呀。
我今天看了path，的确很难，
就是mali 400里面的path，
都是一个flop的Q到下一个flop的D的这种path，直接连接，没有任何logic，就像
Q到SI的scan path一样，
hold violation当然大了，明摆着有啊，
margin + clock skew 已经 就100ps了
这种hold path肯定有，但我觉得不应该有9W条之多，
像这样的DFFA/Q->DFFB/D的path，
大部分path的DFFA和DFFB应该place在一起，DFFA/CK和DFFB/CK应该也接在同一个CKBUF上，
这样clock skew很小了，margin应该10ps左右吧，DFFA/CLK ->DFFA/Q->DFFB/D的延时，应该可以保证hold问题不大
会出现hold vio的地方一般是DFFA/CK和DFFB/CK没有接在同一个CKBUF的地方，它们之间有一定的clock skew，ocv也有一些回不来，如果一个CKBUF驱动20个DFF/CK,应该有1w个左右这样的vio，这些就需要手动eco来修了
分析的太透彻了， 厉害！
现在是 edi的clock tree skew特大，也有100ps 左右，
+ margin = 150ps了，
edi的 如何减小skew，有啥好方法吗
在时钟树文件里设置skew，可以解决一部分吧
小编过奖了，encounter我用的不熟，
ICC里有ocv aware的setting， set_clock_tree_options -ocv_clustering true
我想encounter cts应该也有类似设置。
我翻了一下UG，好像ckECO可以在cts后优化这类vio， 你可以试试看
听讲！学习学习！
多谢，-ocv_clustering true
是干啥的，没用过，
ckECO用过了，没啥用，还是100~200ps，
set_clock_tree_options -ocv_clustering true是ICC的cts的option，主要是减小critical path的local skew，对global skew没太大用
主要原理是使critical path的DFF/CK端尽量拥有更多的common CLKBUF，这样即使ocv存在（set_timing_derate），CRPR也能返回的更多，timing也更容易meet
我看了一下文档，ckECO -localSkew应该也有类似的作用，不过我没试过
对于这个20wDFF，hold vio的最大值应该没多大变化，但是数量会少很多
另外如果design比较大的话，100~200ps的global skew，我觉得不是特别大，
关键是critical path的两个DFF的local skew要小
多谢，我试下
Usage: ckECO [-help] [-clk <string>] [-report <string>] [-useSpecFileCellsOnly]
[-dontFixAddedBuffers] [-localSkew] [-num <integer>] [-fixDRVOnly]
[-spreadTriggerEdgeDelay] [-area] [-reduceTNS <string>]
[-preRoute| -clkRouteOnly| -postRoute| -postCTS ]
-help# Prints out the command usage
-clk <string>#(string, optional)
-preRoute# (bool, optional)
-clkRouteOnly# (bool, optional)
-postRoute# (bool, optional)
-postCTS# (bool, optional)
-report <string># (string, optional)
-useSpecFileCellsOnly# (bool, optional)
-dontFixAddedBuffers# (bool, optional)
-localSkew# (bool, optional)
-num <integer># (int, optional)
-fixDRVOnly# (bool, optional)
-spreadTriggerEdgeDelay# (bool, optional)
-area# (bool, optional)
-reduceTNS <string># [ none | hold ](string, optional)
遇到同样的问题，学习
mark............................
set_clock_tree_options -ocv_clustering true是ICC的cts的option，主要是减小critical path的local skew，对global skew没太大用
主要原理是使critical path的DFF/CK端尽量拥有更多的common CLKBUF，这样即使ocv存在（set_timing_derate），CRPR也能返回的更多，timing也更容易meet