DC和PT

各位大侠：用encounter对设计自动布局布线，经优化后encounter分析显示的建立时间和保持时间都满足。但在版图后用PT对设计进行STA时发现保持时间有很多路径不满足（slcak=-0.66），建立时间满足。我该怎么去解决这么多保持时间不满足。有什么方法?如果保持时间不满足的路径数量少的话可以手工加BUFFER，但太多了。真不知道该怎么办?可以在DC中用语句set_fix_hold PLL_CLK来解决吗?真的很急呀！请高手帮忙下！非常感谢！

1）检查PT和encounter使用的SDC，spef，sdf是否一致
2）在encounter里面setOptMode -holdTarget 0.7，再做一次optDesign -hold

setOptMode -holdTarget 0.7
估计要插太多的delay cell，说不定就要爆了。

确实爆了。太多的space DRC。但可以把数值改小点。那请问你有什么高见?

高见没有。 呵呵
你这个EDI和PT的correlation的问题比较严重， 660ps很大了，觉得你还是应该先找找看为什么correlation有问题，不然EDI看不到violaton也是白搭

请问什么是EDI?我用的是SPEF反标的。spef直接由encounter产生的但不是QRC参数。不过如果用sdf反标的话，建立时间和保持时间都满足。哎，真无赖，
版图生成后用PT做STA，用于PT的tcl如下：
set search_path "."
set link_path "*fs90a_c_generic_core_ss2p25v125c.db fs90a_c_generic_core_tt2p5v25c.db coef_mem_ss.db coef_ram_wc.db data_ram_wc.db"
read_verilog /...eua2308_dap_ram_soc_12_01_30.v
current_design eua2308_dap_ram
link_design eua2308_dap_ram
set_min_library fs90a_c_generic_core_ss2p25v125c.db -min_version fs90a_c_generic_core_ff2p75vm40c.db
set_min_library data_ram_wc.db -min_version data_ram_bc.db
set_min_library coef_ram_wc.db -min_version coef_ram_bc.db
set_min_library coef_mem_ss.db -min_version coef_mem_ff.db
set_driving_cell -lib -cell DFFN -pin Q -no_design_rule [all_inputs] -library fs90a_c_generic_core_tt2p5v25c
set_wire_load_model -name enG50K -lib fs90a_c_generic_core_tt2p5v25c
set_wire_load_mode enclosed
set_operation_conditions -analysis_type on_chip_variation -min BBCOM -min fs90a_c_generic_core_ff2p75vm40c.db -max WWCOM -fs90a_c_generic_core_ss2p25v125c.db
create_clock_period 38 -waveform{0 19} PLL_CLK
set_load 5e-1[all_outputs]
set_drive 0 {PLL_CLK}
set_dont_touch_network {PLL_CLK}
set_propagated_clock [get_ports PLL_CLK]
set_clock_uncertainty -setup 0.3 [get_clocks PLL_CLK]
set_clock_uncertainty -hold 0.2 [get_clocks PLL_CLK]
set_input_delay 2 [remove_from_collection [all_inputs] [get_ports PLL_CLK]] -clock PLL_CLK
set_output_delay 1 [all_outputs] -clock PLL_CLK
然后执行read_parasticts /...eua2308_dap_ram12_01_30.spef语句结果出现以下
warning:unconnected hierarchy pin'eua2308_dap_u/eua2308_dap_control_u/no_cycle'is missing in the RC annotation for net
'eua2308_dap_u/eua2308_dap_control_u/no.cycle'
warning:unconnected hierarchy pin'eua2308_dap_u/eua2308_dap_control_u/sck_pos_edge'is missing in the RC annotation for net
'eua2308_dap_u/eua2308_dap_control_u/sck_pos_edge'
net typetotallumpedRC piRC networknot annotated
internal nets2193300216290
-driverless nets000231
-loadless nets00073
boundary/port nets180001800
-driverless nets0000
-loadless nets0000

221130021809304
再运行report_timing -delay min
report_timing -delay max
后出现warning
warning:some timing arcs have been disaabled for breaking timing loops or because of constant propagation
下面的相类似的warning很多，我只列了一个
warning:failed to compute c_effective for the timing arc(data_ram_wc/data_ram)data_ram_u/ck-->DO2(max_falling retain_rising)because the library data indicates a non_positive drive resistance
到底哪里有问题了。我还是解决不了。

我把hold target设为0.3优化encounter DRC满足。然后用PT做sta发现hold slack由以前的-0.66变为了-0.57.还是有效果的。但如果hold target设为0.7优化，就会出现很多 DRC，space 太小。难道现在只有重新布局或把面积增大?

找找为何不一致吧。

看看set_operating_condition那个设的对么。和ocv结合一起，有么有太严格?
另外，soce貌似默认是bc_wc， pt用ocv，可能也是不一致。 propagated clock了，uncertainty 值对么

我同意楼上的看法，你的OCV用的是min/max lib来做不同的launch/capture path delay计算，而soce通常用相同的lib*derate做OCV，也就是bcwc。 所以用soce计算出来的SDF在PT中没有问题，因为不用做delaycal，但是用SPEF就需要做delaycal了。
BTW，EDI就是Encounter Digital Implementation system 官方叫法

谢谢大家。问题确实在set_operation_conditions -analysis_type on_chip_variation -min BBCOM -min fs90a_c_generic_core_ff2p75vm40c.db -max WWCOM -fs90a_c_generic_core_ss2p25v125c.db 这里
把on_chip_variation 该为 bc_wc后用spef反标分析建立时间slack=0.93,保持时间slack=0.16;用sdf反标分析建立时间slcak=0.94,保持时间slack=0.30;相差不大。我以前就是用bc_wc的，但PT会出现警告，所以查了下资料看有人用on_chip_variation于是就改了下。都不明白是怎么回事。结果弄了我这么久。悲催。on_chip_variaton到底是怎么回事。对了。spef我是直接从encounter timing菜单下extract RC 产生的。我看很多人说要用QRC参数或者star xt软件提取才准确。

谢谢大家，果然是on_chip_variation的问题，改为wc_bc后，用spef分析和sdf分析建立时间和保持时间都满足，相差也很小。什么是on_chip_variation?

OCV算法认为同一个die上面会同时存在不同的operating condition。在做setup check时，对到达同一个cell的两条path，early path用min lib计算delay，late path用max lib计算。比如对一个FF，clock path是early path， data path是late path，ocv使clk相对早到，data相对晚到，就是采用最悲观的情况。
hold check反之。
OCV明显过于悲观了，大的design很难signoff，比较主流的是aocv（area ocv），die上面相近的地方用相近的lib，算法就比较复杂了。

aocv跑起来慢啊，你整个sta的interation要花多久，随便来一点eco不是要搞死人啊。

很好，学习了！

好像已在pt中批量的size_cell，再看report_timing。如果met，write_change-》tcl，应该可以再edi中source这个tcl，再eco place，eco route。最后在pt一下看是否fix

多谢分享

小编设置的是Encounter还是PT的operating condition为bc_wc?

（1） 先确定ocv setting一致
（2） 确认是否是delay calculation的差别，把EDI的spef 放到 pt里面报一下
这里面又有base delay和increment delay一致。

good question

随便看看

顶贴赚积分