首页 > 为什么只在CTS后fix hold violation?
头像
小棉袄lov
编辑于 2021-04-21 19:07
+ 关注

为什么只在CTS后fix hold violation?

为什么只在CTS后fix hold violation?

关于setup和hold需要满足以下两个约束条件:

Setup: Tlaunch + Tck2q + Tlogic + Tuncertainty&margin <=  Tcapture + Tcycle - Tsetup
Hold: Tlaunch + Tck2q + Tlogic + Thold >= Tcapture + Tuncertainty&margin
Tlaunch和Tcapture分别为数据路径和时路径,或者叫数据发射路径和时钟捕获路径
这个数学优化问题的目标函数就是最小的功耗和面积,即通过EDA工具计算,在满足时序约束条件下实现最小功耗和面积开销的物理设计
理论上,只要在最终timing sign off的时候,满足这两个约束条件即可。但是,为什么在物理实现的所有阶段都会分析setup,却只在CTS 之后分析hold?

大佬说,只有在CTS之后clock skew定下来,修hold 才有意义。但是从公式上看,setup time也和clock skew相关啊,莫非hold是后端工程师的二女儿?

当然不是,在实际设计中理想的skew为0,只有在CTS之后分析clock skew才有意义。
对于setup 分析,相比时钟周期Tcycle和最大数据路径逻辑延时Tlogic,clock skew影响有限。设置clock uncertainty足够cover住CTS之后的skew。对所有时钟端口都设置一个最大的uncertainty,简化了工程师和EDA工具的很多工作。

对于hold分析,和时钟周期Tcycle无关。hold分析和skew的关系更加密切,并且理想情况下skew为0,一般是不会存在hold violation的。
在CTS之后,有实际计算的skew值之后就可以分析hold和setup。此时修复hold和setup问题都可以从data path和clock path上着手。从公式上看,存在hold和setup打架的情况(参见设计中可能会同时发生setup和hold的violation么?),所以修复hold问题时,需要给setup留有足够的余量,反之亦然。
在CTS之前,由于clock skew不定,fix hold violation是没有意义的,因为hold和clock skew很密切。但是CTS之前,我们通过设置clock skew的预估值,是足够分析setup的。

虽说在物理设计流程中,setup优先级更好,实际上hold violation比setup violation更关键、更危险。

根据上述公式,在芯片tape out之后还可更改时钟周期以满足setup条件。如果发生hold violation,情况会更加糟糕。

本文参考这篇帖子:https://zhuanlan.zhihu.com/p/114752119,写的很好,文中内容也是摘自于这篇帖子,转载请注明原作


全部评论

(0) 回帖
加载中...
话题 回帖

推荐话题

相关热帖

近期热帖

近期精华帖

热门推荐