增加clock latency的后果？
2.我把 clock source latency增加以后，synthesis以后发现timing没变，这又是怎么个情况?
network latency 应该是指你的delay insertion 可以大些， 假设的clock skew 宽松些
So?
假设你的clock source是A
clock network latency约束的是A点到clock sink的delay，当你释放这个约束，意味着CTS可以有更长的clock path来平衡达到DFF的skew，所以tool会插入更多的buffer或者inverter来balance skew，当然timing就变好啦，但是这样却付出了power和area的代价，因为driver cell变多了嘛。
这里，在65nm以前，这么做似乎是对timing有利，有时也确实这样去improve timing的。
但是，各位需要考虑一下32nm之后，如果还用这种延长clock path来侥幸balance skew的话会出现什么情况呢?
各位需要考虑一下32nm之后，如果还用这种延长clock path来侥幸balance skew的话会出现什么情况呢?
我猜测， 为了平衡SKEW,线会绕远是吗，
同意楼上观点，32nm以后线间距更小，插入过多的buf会使得绕线变长，cross talk的影响反而会使timing更差。个人猜测，欢迎指正。
小编，但是我的这是synthesis，还没有CTS呢
是的，如果用传统的CTS方法的话，确实需要这么做，那么请想想线宽变窄，OCV更严重，要求的RC抽取更精确。此时，path变长的话等于增加了更大的不确定性。特别在32nm之下，这种不确定性将使得skew根本不可能满足。意味着，你如何使用传统方法去CTS，也没有办法实现balanced skew。
不好意思，我望文生义了。 不过，这是个很好的议题，毕竟这是前端和后端都很严峻的事。
加大network delay，时钟延时变大了，相对于我们只关注的setup slack而言，肯定是有利的，所以timing是变好了，虽然是综合，但是也有wlm，这种加大network delay，意味着virtual wire length 和power也增加吧！
在综合时，增加 clock network latency 会改变以下path的timing
1）IO
2）不同clock network latency的path的timing
相同clock network latency的FF之间的timing的变化非常有限
clock source latency的情况与2）的原理相同
综合的时候 时钟不都是理想时钟么 怎么会有CLOCKNETWORK LATENCY 求解答
可以硬加一个CLOCKNETWORK LATENCY
学习了哈
为什么会绕更远，可以通过加buffer来实现啊
插buffer后每段线不一定变长，cross talk不一定会更严重
因为是用来延长clock latency，所以工具会把新添加进来的clk buf 放到离reg 稍远的地方，然后绕线，通过这样的方式增加整条clock path上的delay。
小编您好，我不太同意您说的改变 clock network latency 会影响IO path的timing
对于IO path的timing，我们是通过set_input_delay和set_output_delay来约束的，这实际上是假设了综合的模块外面有一个FF来做launch或者capture。但是DC进行分析的时候默认情况下input_daley和output_delay是考虑了 clock latency的，也就是说，假设的这个FF的 clock latency也会跟着改变，这样是不会影响 IO path 的timing的。如下图：
您觉得这样分析对么?