ICC和PT结果差异
针对某个cell的delay，两个软件的报告都不一样。
所以有两个问题请教大家，
1，report_delay_calculation这个命令，里面的A B C D四个因子，是什么意思?怎么得到的?
2，这样的结果可能是什么原因造成的?
不是吧，没人帮忙
LZ，请确认下面几个问题
1. 用的spef文件是否一样?
2.如果一样，那么得到的结果是正常的，PR的tools看到的Timing跟Signoff的tool看到的是有出入的。
如果LZ有兴趣，可以拿SDF来反标一下，看下，有有趣的事情发生。
1）Library Compiler 里面的 CMOS Nonlinear Delay Model Calculation 一节具体介绍ABCD是怎么来的
2）检查条件设定的是否一样
一般ICC會over constrain 去fix timing , 所以PT的更乐观我覺得很合理.
因為兩個的delay_calculation不一樣,ICC是求快,PT求準,
所以兩個的correlation 就很重要.
和synopsys的培训师讲的类似
还有就是sign off的sdc与P&R用的sdc是否一致，这也是个问题
PS：你是台湾同胞吗?
多谢楼上各位。
icc和pt的lib一致，scaling factor以及timing derate一致。
现在的现象是针对某一cell，ICC和PT报出来的delay不一致。（所以我认为应该不是sdc的问题）关于cell的delay应该是来自lib的吧。而我发现两个报告的tran和cap是不一致的，这个应该就是导致cell delay不同的原因。
那么这两个东东不一样的原因呢?如果是因为算法不一致，我觉得不应该差这么多（20M的时钟，timing的结果相差在1ns。）
相差1ns有点大啊
看下会不会是CRPR的原因。
先看ClockSkew.
有误差是正常的。
但是1ns的误差有些大。
icc 与pt correlation我没有做过，不好评论。
crpr没有问题。1ns的误差是在路径上一点一点积累起来的（比如前面说到的cell的cap和tran不一致）。由于这条路径很长，所以累积到最后偏差很大。
不知道这种情况大家遇到过没有?
谢谢分享
If you design is not below 0.11um, I thank it is ok.
But your desing is 90nm or 65nm ..., you should check the RC correlation between ICC and PT.
谢谢，很尴尬的说，恰好是0.11、、、、、幸好时序不紧张。
是不是pt用的nxtgrd和icc用的tlu+不一致呀
小编，这个问题是什么原因啊?我现在也遇到了，谢谢！