我们经常会遇到这样的情况，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的差异，包括hold。
这种差异表现形式是，从top来看timing，会有数量比较多，但是wns比较小的setup，hold的violation。
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是否一致？
我想，你应该有答案了吧？
