block与top的时序差异分析，建议收藏

我们经常会遇到这样的情况，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是否一致？

我想，你应该有答案了吧？