推文中的數(shù)據(jù)來自于Synopsys官方的ICC2 Lab 為了更容易看到工具做的useful skew的效果，這里故意在下面的path上設(shè)置了很大（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階段，我們的時(shí)鐘是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。那么如何確認(rèn)呢？ 我們可以通過下面的命令來導(dǎo)出tcl腳本： write_script -force



腳本會被導(dǎo)入到wscript目錄下相應(yīng)scenario的tcl中：

wscript/scenario_func.ss_125c.tcl

從中可以看到launch clk path和capture clk path都做了late skew，且相應(yīng)的命令有set_clock_latency和set_clock_balance_points，前者讓工具能看到做完late skew之后的timing情況，后者會指導(dǎo)后續(xù)的CTS引擎在tree上墊長相應(yīng)offset的latency。比如-offset -0.14則相應(yīng)sink的tree會故意做長0.14ns，這個和Innovus的行為類似就不詳細(xì)講解了。

審核編輯：劉清