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

想请教各位，在做前端设计工作中，经常遇到icc所报时序无违例而pt存在违例的现象。经过追查发现在出现延时差别较大的net上大多是fanout较大的路径，但这些fanout的数值都是15以下。同时在报告中相应的net的电容值相同而电阻值差别较大，导致transition time差别较大，相应的icc和pt查表后得到incr也就有了差别。这种情况怎么解决，是icc检查出的阻值正确还是pt?还是二者在阻值计算上有什么参数设置需要统一?不胜感谢！

PT是 sign off工具，一切以PT为准

肯定以pt为准，但是在有大数值的fanout较多的路径里延时的结果会差很多，有时候甚至会达到将近1ns，这对设计是致命的误差，dv的检查基本没有参考价值，只有icc的时序检查才会对设计进行必要修正，如果在icc检查的阶段时序违例查不出来，只能靠echo修正的话，那就可能出现拆东墙补西墙的行为，个人认为synopsys应该解决pt，icc，starrc这三款软件时序检查差别较大的问题。总拿一切以pt为准治标不治本，修改和检查软件的算法都不统一，怎么进行精确的时序检查。还是继续向大家求助，希望遇到类似情况的朋友能多谈一谈。多谢。

是RC提不准还是Delay Calculation不准?比如StarRC是只负责提RC的，PT是只负责Delay Calculation的。Transition不仅跟总R/总C有关，还跟分段数有关，理论上分段越多Transition越好。
单纯R提不准是不可思议的，手算都能很准。

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

ICC提出的spef文件和STARRC提出的spef文件在PT里报出的路径延时差别差不多，说明ICC的RC抽取没问题。ICC的Delay Calculation引擎是可以设置的，有elmore/AWE/arnoldi，这里的设置是否跟PT一致呢?

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