pt中hold的lanch path delay 比icc中大差不多2倍左右
时间：10-02
整理：3721RD
点击：
大家好：
最近刚接触ICC不久， 遇到个新问题
smics 40nm
icc中mcmm ocv 情况下，对于一个path hold timing:
lanch path 是min的， capture path 是max clock latency;
pt中， 我现在是单跑一个corner, 与icc中的一致，不是mcmm，
但是
hold timing, 和icc中同一条path
lanch path 是min的， capture path 是max clock latency;,
使用report_clock_tming -type latency -hold -to xx/CK
这个时候report出来的结果差不多是icc中的2倍多
而report_clock_tming -type latency -setuo -to xx/CK
与icc中的基本一样的，
我想知道， 什么原因会让hold差这么多, 而setup两边基本一样?
最近刚接触ICC不久， 遇到个新问题
smics 40nm
icc中mcmm ocv 情况下，对于一个path hold timing:
lanch path 是min的， capture path 是max clock latency;
pt中， 我现在是单跑一个corner, 与icc中的一致，不是mcmm，
但是
hold timing, 和icc中同一条path
lanch path 是min的， capture path 是max clock latency;,
使用report_clock_tming -type latency -hold -to xx/CK
这个时候report出来的结果差不多是icc中的2倍多
而report_clock_tming -type latency -setuo -to xx/CK
与icc中的基本一样的，
我想知道， 什么原因会让hold差这么多, 而setup两边基本一样?
怎么配置mcmm的， 要求icc和pt必须一致， 单corner ocv
是我把这个也设置上去了
set_min_library $max_library -min
去掉， 就可以了
我倒，这个命令最好别用好吧，
为什么?那设置工作条件最好怎么设?