CTS之后skew比较小，route之后变得比较大，怎么办？

是否存在非CTS专用的buffer在tree里面?

没有。再请问一下非CTS的buffer有什么影响呢?谢谢！

非CTS的buffer存在在tree里面，CTS后，它的状态也不是cts_fixed，所以位置会变，器件footprint的变动也比较大，另外不是clkbuf，delay也比较大。这需要具体看设计的情况判断，有的设计，这个存在是正常的，需要提前干预。
你这个看看longest path和shortest path出现在哪里，然后判断下。

真的么?为啥cts之后不是cts 专用buffer 就没有cts属性呢?

几十ps skew?太厉害了吧，多少reg，多少频率，
一般route后skew会有所飘动，但是只要不影响timing，多大的skew也无所谓，
以timingreport为准，

哦，哦。好的，谢谢小编！如果对timing有影响呢?应该怎么处理啊?谢谢！

1GHz，八百多reg。几十ps的skew很小吗?一般多少啊?

恩，好的，谢谢小编！我再看看。

800个reg 是有可能做到50ps以下的， 1Ghz，乖乖， 怪不得skew影响大呢，
超过50ps，时序就难了，

继续timing opt啊， postroute opt

你是不是Clock Tree没有用ＮＤＲ　ｒｕｌｅ　?　看下ｓｋｅｗ变换的原因，报下ｐｏｓｔｃｔｓ　跟ｐｏｓｔｒｏｕｔｅ的ｔｉｍｉｎｇ．

哦，您说的timing opt可以具体说说吗?谢谢！

用了ＮＤＲ　ｒｕｌｅ　

我看了一下，我的是reg to reg的path。route之后clock source 到reg1/CK的时间比route之前的长，是因为cell的delay增大了，但是clock source 到reg2/CK的时间比route之前的短了。菜鸟求教！

Two ways in EDI:
ckECO (FE-CTS flow)
ccopt_pro (beta feature for CCOPT, will be production in 15.1 or later)

Thank you！ I will try to fix.

Thank you！ I will try to fix.

开SI分析的?

cts之后clock tree难道不freeze吗 ? route之后的timing report， skew会变大，按理应该只有timing derate的影响而已

OCV 的话 postCTS也肯定带上OCV分析的啊。有shelding存在?或者信号SI的影响

是的。

Good awesome topic