primetime分析信号完整性的问题

陈涛

比较2条clock路径，可以看到2点不同
1）每个cell的延迟，原因还是无法确定，你读入了几个db文件？好在它们的差别大部分都被CRPR补了回来
2）clock path 最后几个buf不同是造成violation的主要原因

解决方法是
先找出1）的原因，如果还是有violation，就当是真的，修吧

yl5495

比较2条clock路径，可以看到2点不同
1）每个cell的延迟，原因还是无法确定，你读入了几个db文件？好在它们 ...
陈涛 发表于 2013-7-3 13:29

                               
登录/注册后可看大图

   我比较过正常primetime时序报告和使能信号完整性分析的时序报告：分析数据需要到达时间（data required time）时，跟不分析信号完整性时primetime所报时钟路径延迟单元时间相比，此时延迟单元延迟时间变长。例如同样的BUF4CK 单元，在前者报出延时为0.07ns，而后者分析信号完整性时，报出延时为0.11ns。也就是说两种情况下，相同cell的延迟时间不一样，所以分析SI时出现hold违反而不分析SI时时序实现收敛。请问版主，分析SI时这种情况怎么处理？

主要脚本如下：
# Turn on CRPR
set timing_remove_clock_reconvergence_pessimism true
set timing_dynamic_loop_breaking true
set timing_enable_preset_clear_arcs true
set si_enable_analysis true


set_operating_conditions -analysis_type on_chip_variation -max WCCOM -max_library lib_name
read_parasitics -keep_capacitive_coupling -format SPEF -verbose $be_dir/design_top.spef.max
其余就是读布局布线后的网表，SDC约束文件，其余采用系统默认设置。

陈涛

我也怀疑是SI的作用，但是为什么在report里面看不到，已经用了-crosstalk_delta选项了

你还是得告诉我，到底读入了那些db file，把它们列出来

yl5495

我也怀疑是SI的作用，但是为什么在report里面看不到，已经用了-crosstalk_delta选项了

你还是得告诉我， ...
陈涛 发表于 2013-7-3 13:51

                               
登录/注册后可看大图

分析max是SI就读了worst library，寄生参数spef文件 ，网表 ，时序约束文件。我们的lib 只有worst 和best 两个。
没有在读设么db文件啊。

陈涛

那就奇怪了，
先把它当真的，fix吧

PT关于SI的设定有很多，我都是copy以前积累下来的，没有全记下来，只记得还有timing window和一些阈值的设定不能少，你自己看看PT的设定，试试有什么变化

yl5495

那就奇怪了，
先把它当真的，fix吧

PT关于SI的设定有很多，我都是copy以前积累下来的，没有全记下来，只 ...
陈涛 发表于 2013-7-3 14:10

                               
登录/注册后可看大图

   好的，非常感谢热心帮助。violation 是50ps，如果考虑设置的uncertainty 200ps，是否可以认为实际电路没有违反呢？

陈涛

那要看200ps uncertainty是怎么来的

yl5495

那要看200ps uncertainty是怎么来的
陈涛 发表于 2013-7-3 22:43

                               
登录/注册后可看大图

是我在综合时序约束加的，由此产生的sdc文件给后端使用。做PT分析时当然也使用这个sdc文件。

陈涛

我说的意思是“根据什么定的200ps”

yl5495

我说的意思是“根据什么定的200ps”
陈涛 发表于 2013-7-4 08:49

                               
登录/注册后可看大图

最初是根据经验，之后后端布局布线后给出的时钟树时序报告中显示：

Operating Condition              worst
Clock global Skew                 0.061
Longest path delay               1.228
Shortest path delay              1.167


为了留比较大的margin，就没有做进一步修改。