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的差异。
这种差异表现为,从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