我们经常会遇到这样的情况，block把timing修干净之后，交给做顶层的同事，结果会发现，仍然会有很多新的违例。
这个现象比较常见，但是其中的原因其实比较复杂。
为了把这个问题解释清楚，我们先做几个假设。
假设：
top的spef不是flatten抽取的，而是调用的各个block的spef，这样避免了工具精度的问题。
top与block之间完全做好了隔离，不存在top到block之间的耦合电容。
只考虑intra clock的情况，不考虑inter-clock的情况。因为顶层的路径不同，clock latency必然不同，那么导致inter clock timing不一致也是合理的。
两者constraint一致
1
基于以上假设，是不是top看顶层看模块级的timing与模块级自己来看应该一致了呢？
这里我们要考虑clock上的noise的影响。
这里的noise指的是delta delay。
delta delay比较有意思，你会发现，无论是launch path， 还是capture path， 它都是往悲观的方向上偏。
比如，如果是setup check，launch path的delta delay都是正值，而capture path的delta delay都是负值。
而对于hold，则正好相反。
block看不到顶层部分的clock tree。所以block会偏乐观，也就合理了。
但是，对于setup和hold的影响是有差异的。
2
我们知道，setup check属于非同边沿check，因此，CRPR是无法消除noise的影响的。
所以对于同一个clock，setup会变差也情有可原。
但是hold check是属于同边沿check，CRPR完全可以把顶层的noise的影响抵消。
因此，理论上，对于hold check来说，top看到的timing就该和block一致。
是这样吗？
3
并不是。
虽然我们不考虑inter-clock的timing check，但是对于不同clock之间的noise的影响还是需要考虑的。
由于top与block看到的不同clock之间的latency的差异，会导致timing window的变化。
要知道，对于同步逻辑，timing windlow直接影响到noise的计算。
所以由于不同clock之间noise的影响，也会导致top与block之间timing的差异。
这种差异表现为，从top来看timing，会有很多比较小的setup，hold的违例。
4
基于以上假设，对于setup check，会有clock network的delta delay的影响，不同clock的timing window的影响。
而对于hold check，则是timing window的影响。
而这些影响，导致top看到的timing与block之间的timing的差异。
5
我们再增加一个假设，
如果block内部的clock都是异步的关系，对于hold check，top与block是否一致？
即使block 内部clock都是异步关系，top和block 看到的hold violation肯定也不同。
原文链接：https://zhuanlan.zhihu.com/p/153455038
网友评论