已解决-DC与PT的时序分析差异，请帮我分析

我在做完PT后，查看建立时间分析，对于同一路径，发现和DC报出的情况有很大差别，是不是由于PT更精确造成的差别，还是PT和DC两者的分析方法上有差别，在脚本中，PT中的相关约束设置和DC中的是一致的。通过对比，特别是器件的transition time差别较大会造成Increase time 变大，而且最后的library setup time,DC中的要比PT中的大很多，具体看下面的：
PT后setup time
Startpoint: tg_if_pif_cmd_reg_7_
(rising edge-triggered flip-flop clocked by CK)
Endpoint: tg_if_sif_data_reg_1_
(rising edge-triggered flip-flop clocked by CK)
Path Group: CK
Path Type: max
PointFanoutCapTransIncrPath
-----------------------------------------------------------------------------
clock CK (rise edge)0.400.000.00
clock network delay (ideal)3.003.00
tg_if_pif_cmd_reg_7_/CK (DFQRM2)0.400.003.00 r
tg_if_pif_cmd_reg_7_/Q (DFQRM2)0.490.573.57 f
tg_if_pif_cmd_7_ (net)40.22
U3001/Z (INVM4)0.800.534.10 r
n4327 (net)50.29
U4823/Z (ND4M2)0.660.334.43 f
n1239 (net)20.12
U3085/Z (ND2M4)0.990.685.11 r
n4581 (net)60.35
U4152/Z (CKINVM2)0.830.615.72 f
n4292 (net)30.17
U2926/Z (NR2M1)0.980.626.34 r
n3124 (net)10.06
U3133/Z (OAI21M4)0.540.326.65 f
tg_if_pif_next_rdlh (net) 40.23
U3307/Z (OR2M8)0.460.457.11 f
n2876 (net)120.79
U2724/Z (NR2M6)1.090.647.74 r
n2262 (net)80.43
U2911/Z (AOI222M1)0.510.388.12 f
n2283 (net)10.05
U4837/Z (ND4M1)0.730.528.64 r
n2274 (net)10.06
U4836/Z (NR2M2)0.400.298.93 f
n1202 (net)20.11
U4821/Z (OAI22B10M0)1.110.659.58 r
tg_if_sif_next_data[1] (net)
10.05
tg_if_sif_data_reg_1_/D (DFQRM2)1.110.009.58 r
data arrival time9.58
clock CK (rise edge)0.4020.0020.00
clock network delay (ideal)3.0023.00
clock uncertainty-0.1022.90
tg_if_sif_data_reg_1_/CK (DFQRM2)22.90 r
library setup time-0.7422.16
data required time22.16
-----------------------------------------------------------------------------
data required time22.16
data arrival time-9.58
-----------------------------------------------------------------------------
slack (MET)12.58
DC中的transition time都要比PT中大出2倍，这是什么原因呢?
DC后setup_timing
Startpoint: tg_if/pif/cmd_reg[7]
(rising edge-triggered flip-flop clocked by CK)
Endpoint: tg_if/sif/data_reg[1]
(rising edge-triggered flip-flop clocked by CK)
Path Group: CK
Path Type: max
Des/Clust/PortWire Load ModelLibrary
------------------------------------------------
tango_fhv_digitalwl50l180hv_wc
PointFanoutCapTransIncrPath
-------------------------------------------------------------------------------
clock CK (rise edge)0.000.00
clock network delay (ideal)3.003.00
tg_if/pif/cmd_reg[7]/CK (DFQRM2)0.400.003.00 r
tg_if/pif/cmd_reg[7]/Q (DFQRM2)1.081.424.42 f
tg_if/pif/cmd[7] (net)40.220.004.42 f
U3001/Z (INVM4)1.761.255.68 r
n4327 (net)50.290.005.68 r
U4823/Z (ND4M2)1.701.096.77 f
n1239 (net)20.120.006.77 f
U3085/Z (ND2M4)2.231.698.45 r
n4581 (net)60.340.008.45 r
U4152/Z (CKINVM2)1.911.6110.06 f
n4292 (net)30.170.0010.06 f
U2926/Z (NR2M1)2.321.6511.71 r
n3124 (net)10.060.0011.71 r
U3133/Z (OAI21M4)1.281.0112.72 f
tg_if/pif/next_rdlh (net)40.230.0012.72 f
U3307/Z (OR2M8)1.001.1313.84 f
n2876 (net)120.770.0013.84 f
U2724/Z (NR2M6)2.561.5715.41 r
n2262 (net)80.430.0015.41 r
U2911/Z (AOI222M1)1.301.2316.64 f
n2283 (net)10.050.0016.64 f
U4837/Z (ND4M1)1.691.35 17.99 r
n2274 (net)10.060.0017.99 r
U4836/Z (NR2M2)0.900.8218.81 f
n1202 (net)20.110.0018.81 f
U4821/Z (OAI22B10M0)2.741.7420.55 r
tg_if/sif/next_data[1] (net)
10.050.0020.55 r
tg_if/sif/data_reg[1]/D (DFQRM2)2.740.0020.55 r
data arrival time20.55
clock CK (rise edge)20.0020.00
clock network delay (ideal)3.0023.00
clock uncertainty-0.1022.90
tg_if/sif/data_reg[1]/CK (DFQRM2)0.0022.90 r
library setup time-2.1920.71
data required time20.71
-------------------------------------------------------------------------------
data required time20.71
data arrival time-20.55
-------------------------------------------------------------------------------
slack (MET)0.15
请帮我分析下，谢谢！

set_max_transition ?

记得有个命令可以显示工具是怎么计算迟延信息的，具体可以查一下manual。
怀疑是不是pvt条件不一样。

reportDelayCalculation

这个相差太离谱了，一定是哪里有问题。
wire load model，SDF，netlist都一样吗?

DC与PT的时序分析差异，紧急求助



谢谢。
我用report_delay_calculation观察了上面路径中的U3001 cell的情况，在PT和DC后做了对比，发现在建立时间的计算上，PT并没有用WC库，而是用BC库（具体为l180hv_bc.db），这不应该啊，为什么没有用WC库呢? 在pt.log中，report_design报出的信息也是正确的。
PT中：
pt_shell: report_delay_calculation -from U3001/A -to U3001/Z -max
****************************************
Report : delay_calculation
Design : digital
Version: D-2010.06-SP3
Date: Thu Dec 15 16:24:57 2011
****************************************
From pin: U3001/A
To pin:U3001/Z
Main Library Units:1ns1pF1kOhm
Library: 'l180hv_bc'
Library Units:1ns1pF1kOhm
Library Cell: 'INVM4'
arc sense:negative_unate
arc type:cell
Units:1ns1pF1kOhm

Rise Delay
cell delay = 0.528087
Table is indexed by
(X) input_pin_transition = 0.490917
(Y) output_net_total_cap = 0.29215

------省略
Cell Delay
rise:0.528087
fall:0.384058
------省略
Rise delay = 0.528087
Fall delay = 0.384058
Rise transition = 0.803341
Fall transition = 0.546333
DC中：
dc_shell: report_delay_calculation -from U3001/A -to U3001/Z -max
****************************************
Report : delay_calculation
Design : tango_fhv_digital
Version: D-2010.03-SP1
Date: Thu Dec 15 16:24:37 2011
****************************************
From pin:U3001/A
To pin:U3001/Z
Main Library Units:1ns1pF1kOhm

Operating Conditions: l180hv_wcLibrary: l180hv_wc
Wire Load Model Mode: top
DesignWire Load ModelLibrary
------------------------------------------------
digitalwl50l180hv_wc
Library: 'l180hv_wc'
Library Units:1ns1pF1kOhm
Library Cell: 'INVM4'
arc sense:negative_unate
arc type:cell

Rise Delay
cell delay = 1.25191
Table is indexed by
(X) input_pin_transition = 1.0817
(Y) output_net_total_cap = 0.287982
Relevant portion of lookup table:
(X)0.6704(X)1.2169
(Y)0.1754(Z)0.7772(Z)0.9732
(Y)0.2941(Z)1.1090(Z)1.3226
Z = A + B*X + C*Y + D*X*Y
A =0.0785B =0.3108
C =2.6125D =0.2723
Z = 1.25191
scaling result for operating conditions
multiplying by 1 gives 1.25191
Fall Delay
cell delay = 1.07996
Table is indexed by
(X) input_pin_transition = 2.45819
(Y) output_net_total_cap = 0.287982
Relevant portion of lookup table:
(X)1.9917(X)3.0009
(Y)0.1754(Z)0.7625(Z)0.9187
(Y)0.2941(Z)0.9992(Z)1.2028
Z = A + B*X + C*Y + D*X*Y
A =0.2432B =0.0851
C =1.2040D =0.3966
Z = 1.07996
scaling result for operating conditions
multiplying by 1 gives 1.07996
Cell Delay
rise:1.25191
fall:1.07996
Transition calculations

Transition rise
transition = 1.75641
Table is indexed by
(X) input_pin_transition = 1.0817
(Y) output_net_total_cap = 0.287982
Relevant portion of lookup table:
(X)0.6704(X)1.2169
(Y)0.1754(Z)1.0927(Z)1.2108
(Y)0.2941(Z)1.7165(Z)1.8112
Z = A + B*X + C*Y + D*X*Y
A = -0.0167B =0.2796
C =5.4982D = -0.3619
Z = 1.75641
scaling result for operating conditions
multiplying by 1 gives 1.75641

Transition fall
transition = 1.22039
Table is indexed by
(X) input_pin_transition = 2.45819
(Y) output_net_total_cap = 0.287982
Relevant portion of lookup table:
(X)1.9917(X)3.0009
(Y)0.1754(Z)0.8595(Z)1.0576
(Y)0.2941(Z)1.1342(Z)1.3525
Z = A + B*X + C*Y + D*X*Y
A =0.1215B =0.1667
C =1.9778D =0.1688
Z = 1.22039
scaling result for operating conditions
multiplying by 1 gives 1.22039
**********这里看到pt在分析建立时间的时候用的库不对，应该用WC库才对。各个方面我都做了检查，在pt脚本中没发现异常。其中部分脚本：
set search_path[list/data1/lib_all/l180hv_lib]
set link_path[list {*} l180hv_bc.db l180hv_typ.db l180hv_wc.db]
#-------------------------------------------------------
#read files
set active_designdigital
read_verilog ./syn_netlist/$active_design.v
current_design $active_design
#--------------------------------------------------------
#environment conditions
set_operating_conditions -min l180hv_bc -min_library l180hv_bc -max l180hv_wc -max_library l180hv_wc
set_wire_load_model -name "wl50" -library l180hv_wc -max
set_wire_load_model -name "wl10" -library l180hv_wc -min
set_wire_load_mode top
***************看了一下log文件，没有error。部分为：
Loading verilog file '/data1/hli/hv_prj/sta/post-dc/syn_netlist/digital.v'
Warning: Design 'digital_DW01_inc_0' (file '/data1/hli/hv_prj/sta/post-dc/syn_netlist/digital.v')
is already registered. Remove the design before rereading. (DBR-003)
Information: Inferring 1 clock-gating checks. (PTE-017)
Information: Checking 'no_input_delay'.
Information: Checking 'no_driving_cell'.
——————省略部分
Design AttributeValue
---------------------------------------------------------------------------
Operating Conditions:
analysis_typeon_chip_variation
operating_condition_min_namel180hv_bc//这里指向的lib是bc，正确。
process_min1
temperature_min-40
voltage_min1.98
tree_type_minbalanced_case
operating_condition_max_namel180hv_wc //这里指向的lib是wc，正确。
process_max1
temperature_max125
voltage_max1.62
tree_type_maxbalanced_case
Wire Load:(use report_wire_load for more information)
wire_load_modetop
wire_load_model_maxwl50
wire_load_model_library_maxl180hv_wc
wire_load_selection_type_maxuser-specified
wire_load_model_minwl10
wire_load_model_library_minl180hv_wc
wire_load_selection_type_minuser-specified
wire_load_selection_group_max--
wire_load_selection_group_min--
wire_load_min_block_size0
Design Rules:
max_capacitance--
min_capacitance--
max_fanout--
max_transition--
max_area--
Timing Ranges:
early_factor--
late_factor--
Pin Input Delays:
None specified.
Pin Output Delays:
None specified.
Fast Analysis:disabled
现在看pt用了bc库去分析setup time了，所以同一路径要比dc分析出来的arrive time要小很多。我自己不懈努力还是没有查出具体原因，请大家帮我分析分析，非常感谢！

要么ocv啊， 要么bc-wc啊， 别两个搞混了，
你用了 set_operating_condition -analysis_type XXXX么， 缺省是ocv模式，
单独搞个link library， 用ocv single corner做吧， 这样比较简单，
如 set link_path { *wc.db }----------- formax setup check
set link_path{ *bc.db }--------------formin hold check ,

kanbudong

非常感谢你的指导！
还是我对PT的认识还不够，做完DC，就将DC中的脚本改动了一些作为PT的脚本，大部分感觉是一样的，特别是link_path这里，没有追究它与DC link_lib的区别。通过这个问题我对PT的认识更加清楚一些。特别是PT分析中存在三种分析模式：single, bc_wc, OCV。为了节省时间PT可以进行bc_wc或者OCV的分析，同时分析出min delay 和max delay，前提要告诉PT分析min delay和max delay指定对应的lib（best-case lib 和worst-case lib）。之前我的问题是没有为PT分析min delay和max delay指明相应的lib，虽然在脚本中也写到：set_operating_conditions -min l180hv_bc -min_library l180hv_bc -max l180hv_wc -max_library l180hv_wc。但是link_path的对象不对，只能是worst-case lib，还有缺少了set_min_delay，该命令主要是在两种库之间建立max/min的关系，为后面PT同时进行min delay和max delay分析做好库的准备。对于PT的delay分析过程，PT的手册中说到：PrimeTime first checks the library cell in the maximum library, and then looks in the minimum library to see if a match exists. If a library cell with the same name, the same pins, and the same timing arcs exists in the minimum library, PrimeTime uses that timing information for minimum analysis.
现在正确的脚本如下：
set search_path[list/data1/lib_all/l180hv_lib]
set link_path[list {*} l180hv_wc.db]
#-------------------------------------------------------
#read files
set active_designdigital
read_verilog ./syn_netlist/$active_design.v
current_design $active_design
#--------------------------------------------------------
#environment conditions
set_min_library l180hv_wc.db -min_version l180hv_bc.db
set_operating_conditions -min l180hv_bc -min_library l180hv_bc -max l180hv_wc -max_library l180hv_wc
set_wire_load_model -name "wl50" -library l180hv_wc -max
set_wire_load_model -name "wl10" -library l180hv_wc -min
set_wire_load_mode top
------
------
这样PT分析的结果就和DC一致了。
另外PT根据上面的脚本分配给set_operating_conditions 分析模式为BC_WC（user guide中提到在set_operating_conditions 用到-min，-max，那么默认模式就是BC-WC），但是它的推荐模式为OCV。因为我试过加上-analysis_type bc_wc，PT会报出warning，BC_WC模式将在未来的版本中取消。原句：Warning: The BC_WC ananlysis mode will be phased out in future releases. (PT-009)
原因是BC_WC分析不够精确，没有覆盖最悲观的情况。
后面还是要深入的研读手册。
自己做个小结，也让其他同仁从中避免此种问题。

很详细，学习了

不知道在DC中要改成什么样子?是target_library ?set_min_library要不要加?
才可以两个库同时使用

不知道在DC中要改成什么样子?是target_library ?set_min_library要不要加?
才可以两个库同时使用
回：DC中 target_library 填入worst lib（最好悲观些）, link_library中把 best, typical, worst lib都填入用来分析setup和hold timing. set_min_library不用加。

请问为什么要设置set_min_library啊?

小编分析的非常详细了，有几个问题我想确定下。在dc中，我使用set_operation_condition -max max_lib -min min_lib
那么这样的分析时采用bc_wc分析吗?这样分析是否能够有如你所有的“覆盖最悲观的情况”。

小编最后的分析搞得我比较凌乱。
按理说一般的lib提供商会将BC和WC两种condition做在一个库里。当然也有分开做在不同的库里的。
而且，PT的分析模式默认是single吧我记得。就是说一次只能做一次条件分析，例如Max或者Min。
而Bc_WC模式则挑选两个corner来作分析。所以一次可以做最坏和最好两种分析。
另外set_min_delay是设置例外制约的和小编所说的应该没有关联吧

最悲观的情况我觉得应该是OCV模式的时候做的。例如做setup分析時clock path用BC，data path用WC，hold分析时则相反。
不知道我说的对不对求高手批评！

我也是不太清楚。
在dc中倒是有个命令是set_min_library，作用时在进行增量编译的时候，能够修复hold violation，但不违背setup violation。
set_operation_condition的max和min也可以优化设计。
不知道是不是说dc中只要用一个就可以?以及，用了哪个是对应bc_wc分析，而另外一个是OCV分析?

不是说DC中只要一个就可以了，而是由lib的提供商来决定的吧
如果两种条件做在一个裤里面就直接调用一次就行，如果BC和WC做在两个庫時就需要用到set_min_library这样的命令了。
揣测！求高手正解。

我的意思是在dc中是不是只要使用set_min_library和set_operation_condition中的一个就可以了，以及哪一个是针对WC_BC，哪一个是针对ocv。我一般在dc中就直接只用set_operation_condition，合理吗?
小编的意思是说，在pt中需要同时使用set_min_library和set_operation_condition，不知道我理解的对不对?
下述是引用小编的tcl，可以看到小编的脚本中是同时使用了这两个，请问小编这是在pt和dc中都要这么用的吗?
#environment conditions
set_min_library l180hv_wc.db -min_version l180hv_bc.db
set_operating_conditions -min l180hv_bc -min_library l180hv_bc -max l180hv_wc -max_library l180hv_wc
set_wire_load_model -name "wl50" -library l180hv_wc -max
set_wire_load_model -name "wl10" -library l180hv_wc -min
set_wire_load_mode top

1.我的意思是在dc中是不是只要使用set_min_library和set_operation_condition中的一个就可以了，以及哪一个是针对WC_BC，哪一个是针对ocv。我一般在dc中就直接只用set_operation_condition，合理吗?
答：首先你写错了，是set_operating_conditions而不是set_operation_condition，在DC中只要写set_operating_conditions就可以了，比如set_operating_conditions -max l180hv_wc -min l180hv_bc。这样DC就按照bc_wc方式来分析和优化时序的。在.synopsys_dc.setup中 已经写到 set link_library [list {*} l180hv_bc.db l180hv_typ.db l180hv_wc.db]，三种库已经读入到DC的内存中。两种operating conditions分别为 l180hv_wc和l180hv_bc是能够从内存中搜索到的。user guide中提到在set_operating_conditions 如果用到了-min，-max，那么默认模式就是BC-WC。只有再加入声明 -analysis_type OCV才是OCV的分析方式，例如set_operating_conditions -max l180hv_wc -min l180hv_bc -analysis_type OCV。
在DC后的PT分析中BC_WC和OCV两种分析方式结果是一致的。原因就在于还没有真实的版图，时钟时理想的，没有buffer等器件构成的时钟树。对比Best-case/worst-case简写：bc_wc。和On-chip variation 简写: OCV。在DC后的PT中因为时钟树是理想的，所以在时钟路径中没有额外器件，best-case operating condition和worst-case operating condition对于时钟的延迟是没有影响的。所以在DC后的PT中，bc_wc和OCV两种分析方式结果上没有差异。注意在PR后的PT中，因为加入了时钟树，即时钟路径中有器件，那么best-case operating condition和worst-case operating condition对于时钟路径就有不同的影响了，这种情况下，两种分析模式就不同了，OCV显然更加悲观。但是OCV由于太悲观了，在astro的user guide中并不推荐该种分析方式。但是在PT的user guide中推荐模式又是OCV，请大家注意，想必PT考虑到未来工艺的进步，时钟走线对时钟的影响越显著，未来OCV的分析方式会越来流行。
2.小编的意思是说，在pt中需要同时使用set_min_library和set_operation_condition，不知道我理解的对不对?
下述是引用小编的tcl，可以看到小编的脚本中是同时使用了这两个，请问小编这是在pt和dc中都要这么用的吗?
#environment conditions
set_min_library l180hv_wc.db -min_version l180hv_bc.db
set_operating_conditions -min l180hv_bc -min_library l180hv_bc -max l180hv_wc -max_library l180hv_wc
set_wire_load_model -name "wl50" -library l180hv_wc -max
set_wire_load_model -name "wl10" -library l180hv_wc -min
set_wire_load_mode top
答：在PT中是同时使用set_min_library和set_operating_conditions，前面的帖子已有介绍。这点不同于DC的是：PT的link_path是不同于DC的.synopsys_dc.setup中的link_library。仔细读下我前面的帖子，其依据取材于PT的user guide。方便看，我再重复写一下：之前我的问题是没有为PT分析min delay和max delay指明相应的lib，虽然在脚本中也写到：set_operating_conditions -min l180hv_bc -min_library l180hv_bc -max l180hv_wc -max_library l180hv_wc。但是link_path的对象不对，只能是worst-case lib，还有缺少了set_min_delay，该命令主要是在两种库之间建立max/min的关系，为后面PT同时进行min delay和max delay分析做好库的准备。对于PT的delay分析过程，PT的手册中说到：PrimeTime first checks the library cell in the maximum library, and then looks in the minimum library to see if a match exists. If a library cell with the same name, the same pins, and the same timing arcs exists in the minimum library, PrimeTime uses that timing information for minimum analysis.
有不足之处还请指出，谢谢。

谢谢小编，非常感谢您的帮助，我想总结下您的回答，请您帮忙指正我的错误
关于第一个问题
1.在使用dc时，默认是使用bc_wc模式，所以，我在dc的时候，只需要使用set_operating_conditions -min XXX-max XXX，此时使用的是bc_wc方式
如果需要OCV，只要在最有加上analysis_type即可
2.关于第二个问题
根据小编的方法，需要在pt中同时使用set_operation_conditions 和set_min_library才能达到bc_wc分析方式，set_operating_conditions和dc中使用一致，set_min_delay中加上-min_version为所用的bc分析库即可。
有个问题，pt中是不是也是默认使用bc_wc分析?如果要ocv分析，需要像dc那样加上-analysis_type?

关于第一个问题
1.在使用dc时，默认是使用bc_wc模式，所以，我在dc的时候，只需要使用set_operating_conditions -min XXX-max XXX，此时使用的是bc_wc方式
如果需要OCV，只要在最有加上analysis_type即可
答：是的。不过在DC中没必要使用OCV，因为时钟是理想的。只需bc_wc即可。
2.关于第二个问题
根据小编的方法，需要在pt中同时使用set_operation_conditions 和set_min_library才能达到bc_wc分析方式，set_operating_conditions和dc中使用一致，set_min_delay中加上-min_version为所用的bc分析库即可。
有个问题，pt中是不是也是默认使用bc_wc分析?如果要ocv分析，需要像dc那样加上-analysis_type?

答：在PT中设置set_operating_conditions -min XXX-max XXX 会使PT达到bc_wc分析方式，但还需设置好库的指定。设置link_path wc.db 和set_min_library wc.db -min_version(上面你误写成了set_min_delay了)是为bc_wc分析方式指明正确的库，就是用wc.db库去分析max_delay，用bc.db库去分析min_delay。根据PT的user guide，PT首先用link_path对应的库去分析max_delay，然后针对同一路径再去用-min_version对应的 bc.db库去分析min_delay，是这么一个过程。所以要设置好set_operating_conditions 和set_min_library，才能使PT实现你期望的bc_wc分析方式。
如果你这么写set_operating_conditions -min XXX-max XXX，那么PT默认使用的是bc_wc分析方式，如果要OCV分析，是要加上-analysis_type，这一点和DC是一样的。

很不錯的一篇文章！

你好，我最近在按照你的方法重做一次pt sta；我用的工艺是将pad和core分开的，他们分别有worst和best两个库
现在的设计是带pad的设计，那么我在set_min_library的时候是不是需要将pad和core的两个对应的worst库都放在 -max 的后面?还是只要core的就可以了?

很好，标记，学习下

mark一下

mark一下

学习中。

多谢小编，学习了

学习中！