在线咨询
eetop公众号 创芯大讲堂 创芯人才网
切换到宽版

EETOP 创芯网论坛 (原名:电子顶级开发网)

手机号码,快捷登录

手机号码,快捷登录

找回密码

  登录   注册  

快捷导航
搜帖子
查看: 3445|回复: 6

[求助] 关于 pt 和icc在较大fanout下net阻值相差较大导致transition time不同的问题

[复制链接]
发表于 2015-4-10 09:42:36 | 显示全部楼层 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有账号?注册

x
想请教各位,在做前端设计工作中,经常遇到icc所报时序无违例而pt存在违例的现象。经过追查发现在出现延时差别较大的net上大多是fanout较大的路径,但这些fanout的数值都是15以下。同时在报告中相应的net的电容值相同而电阻值差别较大,导致transition time差别较大,相应的icc和pt查表后得到incr也就有了差别。这种情况怎么解决,是icc检查出的阻值正确还是pt?还是二者在阻值计算上有什么参数设置需要统一?不胜感谢!
发表于 2015-4-10 14:20:51 | 显示全部楼层
PT是 sign off工具,一切以PT为准
 楼主| 发表于 2015-4-11 19:51:30 | 显示全部楼层
回复 2# richardxingxing
肯定以pt为准,但是在有大数值的fanout较多的路径里延时的结果会差很多,有时候甚至会达到将近1ns,这对设计是致命的误差,dv的检查基本没有参考价值,只有icc的时序检查才会对设计进行必要修正,如果在icc检查的阶段时序违例查不出来,只能靠echo修正的话,那就可能出现拆东墙补西墙的行为,个人认为synopsys应该解决pt,icc,starrc这三款软件时序检查差别较大的问题。总拿一切以pt为准治标不治本,修改和检查软件的算法都不统一,怎么进行精确的时序检查。还是继续向大家求助,希望遇到类似情况的朋友能多谈一谈。多谢。
发表于 2015-4-11 20:27:16 | 显示全部楼层
是RC提不准还是Delay Calculation不准?比如StarRC是只负责提RC的,PT是只负责Delay Calculation的。Transition不仅跟总R/总C有关,还跟分段数有关,理论上分段越多Transition越好。

单纯R提不准是不可思议的,手算都能很准。
 楼主| 发表于 2015-4-12 16:12:08 | 显示全部楼层
回复 4# Timme


    感觉两个维度都有问题。ICC提出的spef文件和STARRC提出的spef文件在PT里报出的路径延时差别差不多,但是和icc自己直接报出的时序报告相比就差很大。然后让icc和pt分别报告net就会出现C值相同而R值差的很多。有时候达到几十倍的差别。由于我是做前端的所以对icc提取spef文件所用的单元库源文件格式是否和starrc使用的相同就不得而知了。如果他们使用的是相同格式的单元库源文件,那只能说icc的计算方法有问题。如果源文件格式不同,那就是单元库参数有问题。可不可以这么理解?还有,就是fanout的参数问题,我们也想分级但是客户要求不让,因为相对应的软件不是我们做的。至少现在来看最明显的差别就是R值相差巨大。
发表于 2015-4-12 17:08:04 | 显示全部楼层


ICC提出的spef文件和STARRC提出的spef文件在PT里报出的路径延时差别差不多,说明ICC的RC抽取没问题。ICC的Delay Calculation引擎是可以设置的,有elmore/AWE/arnoldi,这里的设置是否跟PT一致呢?
 楼主| 发表于 2015-4-13 15:34:49 | 显示全部楼层
回复 6# Timme

尝试过修改calculation的算法,但是结果相差不大。现在初步判定的结果是我们在用max库对hold进行时序检查或者min库对setup进行时序检查会出现这种问题。这种非正常情况的时序检查可能不在软件或者单元库的处理范围内。
您需要登录后才可以回帖 登录 | 注册

本版积分规则

关闭

站长推荐 上一条 /2 下一条


小黑屋| 手机版| 关于我们| 联系我们| 在线咨询| 隐私声明| EETOP 创芯网
( 京ICP备:10050787号 京公网安备:11010502037710 )

GMT+8, 2024-12-23 08:12 , Processed in 0.021315 second(s), 8 queries , Gzip On, Redis On.

eetop公众号 创芯大讲堂 创芯人才网
快速回复 返回顶部 返回列表