PT进行时序分析的疑问
[img]file:///C:\Users\Administrator\AppData\Roaming\Tencent\Users\751546104\QQ\WinTemp\RichOle\{VE%H[4}I[VRZN}NMR9]SI0.jpg[/img]
[img]file:///C:\Users\Administrator\AppData\Roaming\Tencent\Users\751546104\QQ\WinTemp\RichOle\{VE%H[4}I[VRZN}NMR9]SI0.jpg[/img]
图片不清楚啊
我不太会传这个图片，我来简单说一下吧在ICC和PT的分析都是采用的OCV。在ICC的分析中报出的这条路径有0.3036的违例clock rpad_clk (rise edge)0.00000.0000
clock network delay (propagated)4.11194.1119
hhsoc/datapath_ip/pro_top/source_fifo/source_fifo_u1/RFTP512X15M2_inst/CLKA (RFTP512X15M2)
0.00004.1119 r1.62
hhsoc/datapath_ip/pro_top/source_fifo/source_fifo_u1/RFTP512X15M2_inst/DAOUT[14] (RFTP512X15M2)
2.7177 6.8296 r1.62
hhsoc/datapath_ip/pro_top/source_fifo/source_fifo_u1/U251/Z (INVHD2X)
0.1638 &6.9934 f1.62
hhsoc/datapath_ip/pro_top/source_fifo/source_fifo_u1/U237/Z (NAND2HD1X)
0.2056 &7.1990 r1.62
hhsoc/datapath_ip/pro_top/source_fifo/source_fifo_u1/U238/Z (NAND2B1HD4X)
0.1231 &7.3221 f1.62
但是同样的路径在PT中报出的是1.36的余量
clock rpad_clk (rise edge)0.00000.0000
clock source latency0.00000.0000
rpad_clk (in)2.12710.00000.0000 &0.0000 r
ipad_1_28/PAD (PISW_2)0.00000.0000 &0.0000 r
ipad_1_28/ipad/P (PLBI2F)0.00050.0002 &0.0002 r
ipad_1_28/ipad/D (PLBI2F)0.33370.30961.6686 &1.6688 r
ipad_1_28/C (PISW_2)0.00000.0000 &1.6688 r
BUFCLKHD40X_G2B1I1/Z (BUFCLKHD40X)
0.27600.20340.3196 &1.9885 r
BUFCLKHD20X_G2B3I1/Z (BUFCLKHD12X)
0.26560.30090.3861 &2.3745 r
BUFCLKHD8X_G2B4I2/Z (BUFCLKHD8X)0.26160.41380.3579 &2.7324 r
hhsoc/clk_cts_9_1 (hhsoc_test_1)0.00000.0000 &2.7324 r
hhsoc/BUFCLKHD4X_G2B5I7/Z (BUFCLKHD4X)
0.09760.30630.3910 &3.1234 r
hhsoc/datapath_ip/clk_cts_9_50 (datapath_test_1)
0.00000.0000 &3.1234 r
hhsoc/datapath_ip/BUFCLKHD8X_G2B6I9/Z (BUFCLKHD8X)
0.18070.29240.3018 &3.4252 r
hhsoc/datapath_ip/BUFCLKHD3X_G2B7I14/Z (BUFCLKHD3X)
0.08160.33360.3436 &3.7688 r
hhsoc/datapath_ip/BUFCLKHD8X_G2B8I1634/Z (BUFCLKHD8X)
0.13550.25840.2696 &4.0384 r
hhsoc/datapath_ip/pro_top/clk_100_cts_1_23 (pro_top_test_1)
0.00000.0000 &4.0384 r
hhsoc/datapath_ip/pro_top/source_fifo/rd_clk_cts_5_1 (ahead_source_fifo_test_1)
0.00000.0000 &4.0384 r
hhsoc/datapath_ip/pro_top/source_fifo/source_fifo_u1/rd_clk_cts_3_1 (source_fifo_dw15_aw9_DELAY1_n511_max_size512_N1_test_1)
0.00000.0000 &4.0384 r
hhsoc/datapath_ip/pro_top/source_fifo/source_fifo_u1/RFTP512X15M2_inst/CLKA (RFTP512X15M2)
0.27260.0383 &4.0766 r
hhsoc/datapath_ip/pro_top/source_fifo/source_fifo_u1/RFTP512X15M2_inst/DAOUT[14] (RFTP512X15M2) <-
0.02110.07411.6996 &5.7762 f
我对比了一下，其他的STD都有很小的差别，但是这个存储器的相差了1.08的差别，很奇怪这个差别的原因?
ICC里对RC的估算不是很准，你可以分别在icc和pt里报一下那个差别很大的cell的input transition 和output loading，我估计是icc里估算的transition或loading的值超出了cell lib里timing table的范围，所以导致icc里这个cell的delay异常大。
我报了一下，cap 坐在两个里面是一样的，但是ICC里面的transition 是0.1232，PT里面只有0.074，这个transition 的值会受到什么的影响吗?为什么会有这么大的差别?
影响transition的因素很多，diver strength，loading cap，noise等都会影响transition。你报timing report的时候把input，net，transition都报出来，这样好分析。
在ICC里把这个transition问题修掉应该就没violation了。
点击是可以放大的
transition 是由这个 cell 的 driver 的 （input transition 和 output loading） 查表得到的
report 把参数加全了再报应该能看出来了，或者report_delay_calculation
报了一下，发现了PT里面关于这个存储计算的时候用的library是best_lib，我检查了一下存储器的db没有调用错，直接用的是ICC里面的db文件。那是不是我的设置出现问题?我设置的命令如下
set memlibs "SPROM2048X32_SMIRFTP16X15M2RASP8192X16M16SPRAM1KX32_SMICIRFTP64X9M2RFTP256X17M2RADP256X8MRASP512X97M2SPRAM4KX32_SMICIRFTP1024X11M2RASP1024X10M16RASP128X8MRADP2080X18M16RFTP256X15M2RFTP32X16M2RFTP128X10M2RFTP512X15M2RASP4096X21M16SPRAM128X18_SMIRFTP64X20M2RASP256X19RFTP1024X9M2RFTP16X29M2RFTP1024X8M4RFTP128X9M2"
read_parasitics -format SPEF $spef_dir/hhsoc.max.SPEF
set_operating_conditions \
-analysis_type on_chip_variation \
-library smic18_ss \
-max worst \
-min worst
foreach lib $memlibs {
set_min_library /home/xy/soc_icc_2/db/${lib}_worst.db -non
}
set_min_library smic18io_line_ss.db -non
查link_library设置，顺便确定一下OCV的含义吧
学到了！
紫薯布丁
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。
。