PrimeTime分析同一条路径的时候为什么用不同的corner的delay信息
我现在有如下一个report
Startpoint: rx_elastic_buf/skp_set_reg
(rising edge-triggered flip-flop clocked by rx_cdr_clk_1)
Endpoint: rx_elastic_buf/asfifo_usb3/fifo_reg_15__10_
(rising edge-triggered flip-flop clocked by rx_cdr_clk_1)
Path Group: rx_cdr_clk_1
Path Type: max
PointIncrPath
------------------------------------------------------------------------------
clock rx_cdr_clk_1 (rise edge)0.900.90
clock network delay (propagated)0.74 *1.64
rx_elastic_buf/skp_set_reg/CK (DFFRX4)0.001.64 r
rx_elastic_buf/skp_set_reg/QN (DFFRX4)0.40 *2.05 r
U4201/Y (OAI2BB1X4)0.19 *2.24 r
toplevelASTtlrInst211/Y (NAND2BX4)0.08 *2.32 f
U2181ASTttcInst98/Y (BUFX20)0.14 *2.46 f
U2181ASTipoInst262/Y (BUFX8)0.14 *2.60 f
U4198/Y (NOR3X4)0.10 *2.70 r
U4198ASTttcInst75/Y (BUFX12)0.17 *2.88 r
rx_elastic_buf/asfifo_usb3/fifo_reg_15__10_/U3/Y (CLKMX2X2)
0.24 *3.12 f
rx_elastic_buf/asfifo_usb3/fifo_reg_15__10_/D (DFFHQX1)
0.00 *3.12 f
data arrival time3.12
clock rx_cdr_clk_1 (rise edge)2.702.70
clock network delay (propagated)0.35 *3.05
rx_elastic_buf/asfifo_usb3/fifo_reg_15__10_/CK (DFFHQX1)3.05 r
library setup time-0.20 *2.85
data required time2.85
------------------------------------------------------------------------------
data required time2.85
data arrival time-3.12
------------------------------------------------------------------------------
slack (VIOLATED)-0.27
我发现后面一个clock的delay用的值是best case，而前面一个clock是worst case
为什么会这样呢
对啊 ，工具肯定是从最悲观考虑的，你是不是load了max和min两个库?
同一个路径的同一个timing分析怎么会前面用worst后面用best呢?
你report一下你的design看下以下信息是不是正确的：
Operating Conditions:
analysis_typeon_chip_variation
operating_condition_min_nameBALANCED
process_min1
temperature_min110
voltage_min0.85
tree_type_minbalanced_case
operating_condition_max_nameBALANCED
process_max1
temperature_max110
voltage_max0.85
tree_type_maxbalanced_case
如果你的analysis_type是OCV方式，而你的库有不同的operate condition 比如两种bestcase和worsecase，你可以用report_lib 看下有几种operate condition：
Operating Conditions:
NameProcessTempVoltageTree Type
---------------------------------------------------------------------------
tt0p85v110c1.000110.0000.850balanced_case
如果只有一种，开OCV，那么lunchpath和capturepath都用这种，如果有两种，你还开了OCV，就会出现你这种情况，你这种情况，太悲观了，是不正确的。
不知道我说清楚没。
如果是两种case的库的话，load完库，可以用这个来控制，防止出现你那种情况。
set_operating_conditions # Set process, temperature, and voltage
[-analysis_type type](Analysis type:
Values: single, bc_wc, on_chip_variation)
[-library lib](Library to search)
[-max max_condition](Max operating condition name)
[-min min_condition](Min operating condition name)
[-max_library max_lib] (Library to search for max condition)
[-min_library min_lib] (Library to search for min condition)
[-object_list objects] (Cells and ports to set operating conditions on)
[condition](Single operating condition name)
可以把analysis_type 设置成BC_WC，应该就不会出现你刚才的现象了。
大致理解到了，感谢这么仔细的回答，学习中
你好，谢谢你的耐心解答，我大概理解你的意思，但是我试了一下你说的办法却不行，报错如下：
Error: value 'bc_wc' for option '-analysis_type' is not valid.Specify one of:
single, on_chip_variation (CMD-031)
我用的pt 2012版本
如果我改成2007版本，则没有这个问题，分析的路径也是正确的。
您知道为什么吗
你好，谢谢你的耐心解答，我大概理解你的意思，但是我试了一下你说的办法却不行，报错如下：
Error: value 'bc_wc' for option '-analysis_type' is not valid.Specify one of:
single, on_chip_variation (CMD-031)
我用的pt 2012版本
如果我改成2007版本，则没有这个问题，分析的路径也是正确的。
您知道为什么吗
我发现2012版本的pt不支持bc_wc模式了，只能用single模式，然后分别写不同的script来分析max和min了
对，现在基本上分析timing，Pt都是single corner ，规定一种lib，一种rc，一种sdc，setup/hold。都是单view。
大侠，想问你一下，我现在用primetime -SI 来分析crosstalk，我读入了Astro生成的 带有coupling capacitance信息的spef文件，但是分析出来的结果
crosstalk_delta的值都是零，这个是什么原因啊?
谢谢
先看下你的这个变量是不死true的，
printvar si_enable_analysis
如果是false的，就设为true
set si_enable_analysis true
然后看下你的spef有没有couple cap信息。
是否反标正确。
report_annotated_parasitics -check
另外我也是水货，一起学习吧。
学习了
学习了
学习一下。
学习一下。
是否是因為OCV的原因?
同一个timing_arc会有max/min不同的transtion，工具使用最悲观的考虑方式，计算setup的时候，launch clock使用max-transition计算timing，capture clock使用min_transition计算timing。
结果就是你看到的那样了
学习一下
dsfssfsdfsdfdsfdsfdsf