在CTS阶段该如何做才能将skew做到最小？或者说该如何优化skew?

1027199631

各位大神好！小女子在ICC中进行CTS之后report_clock_tree -summary结果如下：

我用的是.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?

d_zhou

对于一个10M的case， 0.8的skew有什么好怕的，go下去看sta再说吧

1027199631

回复 2# d_zhou

STA分析时hold time violation有2ns，大神说肯定是我clock_tree没做好

uszhj

skew做到周期的10%以内即可

1027199631

回复 4# uszhj

我的hold time violation为2ns是不是有点大啊？会不会跟clock_tree有关啊？有人说，其遇到的hold最多为0.09ns

d_zhou

回复 3# 1027199631


   不见得，你先看看-2的hold vio path的clock skew是多少。

1027199631

回复 6# d_zhou

也就是看寄存器CP端的clock_propagated是多少是吗？slack为-1.56ns时，其值是2.33ns

d_zhou

回复 7# 1027199631


   是看lauch path的clock network delay 和 capture path的clock network delay的差值，根据你之前的描述，这个差值应该是小于0.89，   你还是贴一个report出来看比较清楚。

zhanggd

skew不是主要的，如果你真想调skew，可以将skew设置一个具体的值就好了，比如100ps，timing才是王道

1027199631

回复 8# d_zhou

============= Clock Tree Summary ==============

Clock     Sinks     CTBuffers ClkCells  Skew      LongestPath TotalDRC   BufferArea

-----------------------------------------------------------------------------------

clk_in    806       168       171       0.938     3.189       2          19403.988

uut_filter/M2/clk_1

          123       24        24        0.103     0.790       0          2399.040  

uut_filter/M2/clk_2

          123       17        17        0.089     0.663       0          1605.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

  Point                                                   Incr       Path

  ------------------------------------------------------------------------------

  clock clk_in (rise edge)                                0.00       0.00

  clock network delay (propagated)                        0.00       0.00

  input external delay                                    1.00       1.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 time                                                  1.44

  clock clk_in (rise edge)                                0.00       0.00

  clock network delay (propagated)                        2.35       2.35

  uut_Reset_Synchronizer/rst_n_reg/CP (dfcrq1)                       2.35 r

  library removal time                                    0.45       2.79

  data required time                                                 2.79

  ------------------------------------------------------------------------------

  data required time                                                 2.79

  data arrival time                                                 -1.44

  ------------------------------------------------------------------------------

  slack (VIOLATED)                                                  -1.35