电子说
推文中的数据来自于Synopsys官方的ICC2 Lab 为了更容易看到工具做的useful skew的效果,这里故意在下面的path上设置了很大(2.5ns)的path margin,这里是在Place阶段启用的CCD:
current_scenario func.ss_125c
set_path_margin -setup -to [get_pins I_BLENDER_1/s2_op*_reg[*]/D] 2.5
set_path_margin -setup -to [get_pins I_BLENDER_1/s4_op*_reg[*]/D] 2.5
set_app_options -name place_opt.flow.enable_ccd -value true
Place之后的timing report:
icc2_shell> report_timing -to [get_pins I_BLENDER_1/s4_op*_reg[*]/D]
Place阶段,我们的时钟是ideal的,但是却能看到无论是launch clock path还是capture clock path上的network latency都不是0,分别是0.02和0.14,而这个clock在sdc里面的latency是0: report_clocks -skew
所以可知它们肯定是工具做了CCD引入的latency,且launch clk path和capture clk path都做了late skew。那么如何确认呢? 我们可以通过下面的命令来导出tcl脚本: write_script -force
脚本会被导入到wscript目录下相应scenario的tcl中:
wscript/scenario_func.ss_125c.tcl
从中可以看到launch clk path和capture clk path都做了late skew,且相应的命令有set_clock_latency和set_clock_balance_points,前者让工具能看到做完late skew之后的timing情况,后者会指导后续的CTS引擎在tree上垫长相应offset的latency。比如-offset -0.14则相应sink的tree会故意做长0.14ns,这个和Innovus的行为类似就不详细讲解了。
审核编辑:刘清
全部0条评论
快来发表一下你的评论吧 !