增加clock latency的后果？

xilinx_zhao

1.我把clock network latency 增加以后, synthesis以后发现timing 变好了，area 和power都变大了。这是怎么个情况？

2.我把 clock source latency  增加以后，synthesis以后发现timing没变，这又是怎么个情况？

yin_wt

network latency 应该是指你的delay insertion 可以大些， 假设的clock skew 宽松些

xilinx_zhao

So?

network latency 应该是指你的delay insertion 可以大些， 假设的clock skew 宽松些
yin_wt 发表于 2012-9-27 13:37

                               
登录/注册后可看大图

joemool

假设你的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的话会出现什么情况呢？

729050850

各位需要考虑一下32nm之后，如果还用这种延长clock path来侥幸balance skew的话会出现什么情况呢？

我猜测， 为了平衡SKEW,  线会绕远  是吗，

liuada001

同意楼上观点，32nm以后线间距更小，插入过多的buf会使得绕线变长，cross talk的影响反而会使timing更差。个人猜测，欢迎指正。

xilinx_zhao

版主，但是我的这是synthesis，还没有CTS呢

假设你的clock source是A
clock network latency约束的是A点到clock sink的delay，当你释放这个约束，意味 ...
joemool 发表于 2012-9-27 18:10

                               
登录/注册后可看大图

joemool

各位需要考虑一下32nm之后，如果还用这种延长clock path来侥幸balance skew的话会出现什么情况呢？

我猜 ...
729050850 发表于 2012-9-27 23:34

                               
登录/注册后可看大图

是的，如果用传统的CTS方法的话，确实需要这么做，那么请想想线宽变窄，OCV更严重，要求的RC抽取更精确。此时，path变长的话等于增加了更大的不确定性。特别在32nm之下，这种不确定性将使得skew根本不可能满足。意味着，你如何使用传统方法去CTS，也没有办法实现balanced skew。

joemool

版主，但是我的这是synthesis，还没有CTS呢
xilinx_zhao 发表于 2012-9-28 02:09

                               
登录/注册后可看大图

   不好意思，我望文生义了。 不过，这是个很好的议题，毕竟这是前端和后端都很严峻的事。

SKILLER

加大network delay，时钟延时变大了，相对于我们只关注的setup slack而言，肯定是有利的，所以timing是变好了，虽然是综合，但是也有wlm，这种加大network delay，意味着virtual wire length 和power也增加吧！