icc和PT对时序检查的差异
时间:10-02
整理:3721RD
点击:
在icc里面我用report_timing 检查hold time,显示出了launch clock 的propagated clock network latency 以及capture clock latency,然后我用report_clock_timing(加-hold选项,好像default是按照setup报的)进一步检查launtch clock 和capture clock的propagated clock network latency是否报得正确,显示出与report_timing是一致的。
[10:46:38] liu guoqi: 同样的case,我在primetiming 里做用样的操作,这时候report_timing中launtch clock network latency 是按照hold来报的,capture clock network latency却是按照setup来报的,导致我时序violated.
[10:47:49] liu guoqi: 为啥icc 和 primetime 的表现不一样呢 ?诧异。
[10:46:38] liu guoqi: 同样的case,我在primetiming 里做用样的操作,这时候report_timing中launtch clock network latency 是按照hold来报的,capture clock network latency却是按照setup来报的,导致我时序violated.
[10:47:49] liu guoqi: 为啥icc 和 primetime 的表现不一样呢 ?诧异。
我自己先顶一下啊。大部分的hold time错误很大程度是有propagted clock 后的 clock skew所导致的。我现在的项目在icc下所有的timing均满足,但是转移到primetime下做sta,发现上面我提到的问题。无法解释。
帮顶,一样的疑惑
学习一下!
icc用tlu
pt用的是starrc
结果肯定不一样
RC 一样吗? sdc? derating? MCMM?... 原因不明
记得以前看过资料中描述ICC和PT trace clock的方式好像不同
一个是从clock source开始,一个是从leaf开始,不知道和您说这个有没有关系
如果觉得有小编可以查看clock的path详细,再查阅一下相关资料看看
另外这里还有一篇帖子小编看一下是否需要:
http://www.eetop.cn/blog/html/17/967917-39067.html
额。这篇是小编您的blog
可以检查PT下面几项,
1)读入的lib,是否有多个corner
2)operating_condition是否为wc_bc,改用ocv比较好
我目前遇到的问题是,PT无任何时序错误,而ICC在某个scenario下由于skew过大而hold违反。
1)PT读入lib有多个corner
2)operating_conditions 是ocv