在CTS阶段该如何做才能将skew做到最小？或者说该如何优化skew？
我用的是.35的工艺，时钟频率是10M，DC综合阶段的uncertainty设置为1，在pre_CTS时set_clock_uncertainty 0.8 [get_clocks clk_in]，有大神跟我说过：CTS之后的skew最好小于200ps，所以我认为我的clock_tree需要进行skew_opt，但其结果如下：
Sourcing optimizations from "skew_opt.tcl":
--> sourcing set_clock_latency
--> sourcing set_inter_clock_delay_options
Warning: Clock clk_in already defined as part of balance group settings (CTS-800)
skew_opt completed successfully.
进行skew_opt之后的结果还是与之前的一样。然后我将clock_tree移除在做CTS之前将clock_latency移除，可是skew结果还是一样。我想请问各位大神：在CTS阶段该如何做才能将skew做到最小?或者说该如何优化skew?
对于一个10M的case， 0.8的skew有什么好怕的，go下去看sta再说吧
STA分析时hold time violation有2ns，大神说肯定是我clock_tree没做好
skew做到周期的10%以内即可
我的hold time violation为2ns是不是有点大啊?会不会跟clock_tree有关啊?有人说，其遇到的hold最多为0.09ns
不见得，你先看看-2的hold vio path的clock skew是多少。
也就是看寄存器CP端的clock_propagated是多少是吗?slack为-1.56ns时，其值是2.33ns
是看lauch path的clock network delay 和 capture path的clock network delay的差值，根据你之前的描述，这个差值应该是小于0.89，你还是贴一个report出来看比较清楚。
skew不是主要的，如果你真想调skew，可以将skew设置一个具体的值就好了，比如100ps，timing才是王道
============= Clock Tree Summary ==============
ClockSinksCTBuffers ClkCellsSkewLongestPath TotalDRCBufferArea
-----------------------------------------------------------------------------------
clk_in8061681710.9383.189219403.988
uut_filter/M2/clk_1
12324240.1030.79002399.040
uut_filter/M2/clk_2
12317170.0890.66301605.240
当skew如上时，STA部分结果如下：
pt_shell> report_timing -delay_type min
****************************************
Report : timing
-path_type full
-delay_type min
-max_paths 1
Design : Digital
Version: C-2009.06-SP3
Date: Thu Sep 29 12:07:22 2016
****************************************
Startpoint: rst_n1 (input port clocked by clk_in)
Endpoint: uut_Reset_Synchronizer/rst_n_reg
(removal check against rising-edge clock clk_in)
Path Group: **async_default**
Path Type: min
PointIncrPath
------------------------------------------------------------------------------
clock clk_in (rise edge)0.000.00
clock network delay (propagated)0.000.00
input external delay1.001.00 r
rst_n1 (in)0.22 &1.22 r
uut_Reset_Synchronizer/rst_n1 (Reset_Synchronizer)0.00 &1.22 r
uut_Reset_Synchronizer/U10/Z (an02d1)0.22 &1.44 r
uut_Reset_Synchronizer/rst_n_reg/CDN (dfcrq1)0.00 &1.44 r
data arrival time1.44
clock clk_in (rise edge)0.000.00
clock network delay (propagated)2.352.35
uut_Reset_Synchronizer/rst_n_reg/CP (dfcrq1)2.35 r
library removal time0.452.79
data required time2.79
------------------------------------------------------------------------------
data required time2.79
data arrival time-1.44
------------------------------------------------------------------------------
slack (VIOLATED)-1.35
意思是在set_clock_tree时将skew设为一个小值而不是默认值0对吗?这是为什么?
set_clock_tree时将skew保持为默认值0时做完CTS 时的报告如下：
============= Clock Tree Summary ==============
ClockSinksCTBuffers ClkCellsSkewLongestPath TotalDRCBufferArea
-----------------------------------------------------------------------------------
clk_in8061681710.9383.189219403.988
uut_filter/M2/clk_1
12324240.1030.79002399.040
uut_filter/M2/clk_2
12317170.0890.66301605.240
set_clock_tree时将skew设为0.1时,其余option与之前保持不变做完CTS 时的报告如下：
============= Clock Tree Summary ==============
ClockSinksCTBuffers ClkCellsSkewLongestPath TotalDRCBufferArea
-----------------------------------------------------------------------------------
clk_in8081881910.9253.513223390.625
uut_filter/M2/clk_1
12322220.0650.49702540.160
uut_filter/M2/clk_2
12324240.0680.47002681.280
skew确实有减小，但效果不是很好。0比0.1更小，为什么工具做出来的结果反而更差?
Startpoint: rst_n1 (input port clocked by clk_in)
input delay 改大点不就可以了 你改成2.4 input delay 试试
其外部的延时只有线延时，加长或加宽就可以了。修复hold的常用方法知道，现在不确定的是我的clock_tree到底有没有问题?
妳的clk_in 有兩個 DRC violation 在 clock network 沒解, max_cap 或 max_tran 看有無 clock cell driving 不夠應該要 sizing up.
所谓tree 是否 balance ，是看两个talk 的register ，不是看一个input port 和 register
那条路径中的rst是我整个底层模块输入，只通过线连接到整个设计的输入端口啊
这个不是我想问的重点，谢谢解答
所以 为了满足要求 ，你应该去调整rst线上的延迟的，而不是因为一条input to reg 的path 去调整整个 cts 。
那大牛告诉我说，hold violation为2ns是clock_tree的问题是否不成立?
假如inout 有2ns hold violations 呢?也是tree的问题?
真想去优化skew的话，还是去分析一下clock tree上为什么会有这么大的skew， 是因为时钟结构引起的还是设置的问题