在pt中，lunch和capture clock path上同一cell的delay不同[已解决]

sjtusonic

我没有设derate，仅读入max corner的库。
报-rise_from pclk -rise_to pclk -path full_clock_expanded的路径。
发现在时钟path的一个buffer在lunch和capture的clock path上的delay不同。
lunch的delay较大（此时计算setup check）

请问各位大牛，除了derate和库的因素外，还有什么会导致这一不同呢？

陈涛

cell rise/fall edge
PBA

sjtusonic

回复 2# 陈涛    

cell rise/fall edge PBA

------------------
感谢陈版主的解答。

我这里r/f极性也是相同的。
估计是第二个原因导致的吧。
PBA是Path-Based Analysis的缩写吗？ 这个概念我不太清楚，它是如何影响delay的呢？

muylor

transition 不同。
计算capture时用min transition， lunch用max transition。
transition是从input port上propagate的。
实际情况是相同的path应该有相同的delay
PT中的解决方法是有一个变量会尽量减小这种delay差，默认是false。
set timing_clock_reconvergence_pessimism true

陈涛

SI也会影响delay
可以在report_timing里面多用些option，把那些影响都报出来

陈涛

回复 3# sjtusonic


    有一贴讨论过PBA，你去搜一下

sjtusonic

哇哈哈，论坛里面都是宝啊，链接过来慢慢消化：）

后端面试--每日一题（059）：
http://bbs.eetop.cn/viewthread.p ... F%C8%D5%D2%BB%CC%E2

[求助] 麻烦陈涛大大再详细讲讲关于PT中PBA分析的问题：
http://bbs.eetop.cn/viewthread.php?tid=320693&highlight=PBA

muylor

这个不是PBA的问题，PBA是说，默认情况下一条Path上每个Cell都用其输入中最差的slew来计算delay造成总的delay很悲观，与实际不符，从而提出的重新分析用合理的slew计算delay。
这里是说同一条path 在两次计算delay时得出不同的值。这个在PT中也有一个概念交CRP：Clock  Reconvergence Pessimism。也是一种过分悲观的结果（其实就是tool算法没有详细区分计算造成的）。
欢迎继续讨论。

icfbicfb

pba缺省是不开的， 除非设置些选项，report_timing -recalu 还差不多，

而且pba是帮助relax slack的，只会使得timing更好，

sjtusonic

经我这两天检查，发现我设计里面clock path的不同包含了3个方面：
1-就是陈版主所说的PBA
我的path在默认条件下使用的GraphBasedAnalysis，对同一个and门的A->Y，launch和capture算出的transition就不同。设置PBA后可达到一致
2-相关pin的影响
比如一个mux，path经过mux/A->mux/Y，但当B的值不同时，A到Y的延迟和Y的tran均会不同。
通过设置case_analysis来消除
3-crosstalk
crosstalk会让launch和capture都变坏，通过设置si_option可以将这块消除

经过以上三部分的消除，launch和capture的公共路径上的延迟等时序信息终于一致！