icc和PT对时序检查的差异

在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 的表现不一样呢 ?诧异。

我自己先顶一下啊。大部分的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