推文中的數據來自于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的行為類似就不詳細講解了。

審核編輯：劉清