set_clock_latency

妞儿

我在时序分析的时候遇到点问题想不通，希望路过的各位大神指点一二~~
我在做DC的时候，对时钟的设定如下：
create_clock [get_ports clk] -period 10 -name clk
set_clock_latency -source 0.0 clk
set_clock_latency -max 1.2 clk
set_clock_transition 0.3 clk
set_clock_uncertainty 0.4 clk
set_ideal_network clk


然后ＤＣ的综合结果，关于clock组的Setup时序分析也没有出现violation，但是将综合后的结果拿去icc做布局布线之后，报出同一条路径上时序却出现了违例，我将两个报告对比了一下，发现了一个问题，在DC的时序报告上，设定的networrk latency在AT 和RT时都计算了，所以，时序分析的时候，路径上没有出现违例，但是在icc中，分析的时候只有在AT的路径上加了network latency ，而在RT路径的计算时，这个值并没有计算进去，这样导致了时序出现违例。我不明白icc中路径上的时序分析是怎么计算的，这个问题应该怎么解决？？？？？？？

分特

什么阶段的报告，cts之前还是之后，贴报告看看

妞儿

回复 2# 分特


   恩，是cts之前的，只进行了预布局的，这是预布局之后的报告  Startpoint: datapath_ip/pro_top/sdram_write_master_inst_address_master_for_ready_reg_1_
              (rising edge-triggered flip-flop clocked by clk)
  Endpoint: datapath_ip/wishbone_master_ip1_wraddr_reg_reg_31_
            (rising edge-triggered flip-flop clocked by clk)
  Scenario: func_worst_corner
  Path Group: clk
  Path Type: max

  Point                                                   Incr       Path      Voltage
  ------------------------------------------------------------------------------------
  clock clk (rise edge)                                   0.00       0.00      
  clock network delay (ideal)                             1.20       1.20      
  datapath_ip/pro_top/sdram_write_master_inst_address_master_for_ready_reg_1_/CK (FFSDRHD1X)
                                                          0.00 #     1.20 r    1.62
  datapath_ip/pro_top/sdram_write_master_inst_address_master_for_ready_reg_1_/Q (FFSDRHD1X)
                                                          0.67       1.87 f    1.62
  datapath_ip/pro_top/U1065/Z (NOR2HD1X)                  0.23       2.10 r    1.62
  datapath_ip/pro_top/U500/Z (NOR2B1HD1X)                 0.31       2.40 r    1.62
  datapath_ip/pro_top/U624/Z (NOR2B1HD2X)                 0.25       2.65 r    1.62
  datapath_ip/pro_top/U623/Z (NOR2B1HD2X)                 0.23       2.89 r    1.62
  datapath_ip/pro_top/U808/Z (NOR2B1HD2X)                 0.23       3.12 r    1.62
  datapath_ip/pro_top/U807/Z (NOR2B1HD2X)                 0.23       3.35 r    1.62
  datapath_ip/pro_top/U806/Z (NOR2B1HD2X)                 0.23       3.58 r    1.62
  datapath_ip/pro_top/U805/Z (NOR2B1HD2X)                 0.23       3.82 r    1.62
  datapath_ip/pro_top/U804/Z (NOR2B1HD2X)                 0.23       4.05 r    1.62
  datapath_ip/pro_top/U1064/Z (NOR2B1HD2X)                0.33       4.38 r    1.62
  datapath_ip/pro_top/U3422/Z (NOR2B1HD1X)                0.23       4.60 r    1.62
  datapath_ip/pro_top/U1063/Z (NOR2B1HD1X)                0.35       4.95 r    1.62
  datapath_ip/pro_top/U1062/Z (NOR2B1HD1X)                0.48       5.43 r    1.62
  datapath_ip/pro_top/U1061/Z (NOR2B1HD1X)                0.50       5.93 r    1.62
  datapath_ip/pro_top/U1060/Z (NOR2B1HD1X)                0.50       6.43 r    1.62
  datapath_ip/pro_top/U1059/Z (NOR2B1HD1X)                0.50       6.94 r    1.62
  datapath_ip/pro_top/U1058/Z (NOR2B1HD1X)                0.41       7.34 r    1.62
  datapath_ip/pro_top/U1057/Z (NOR2B1HD1X)                0.39       7.73 r    1.62
  datapath_ip/pro_top/U1056/Z (NOR2B1HD1X)                0.32       8.05 r    1.62
  datapath_ip/pro_top/U1055/Z (NOR2B1HD1X)                0.30       8.35 r    1.62
  datapath_ip/pro_top/U1054/Z (NOR2B1HD1X)                0.29       8.64 r    1.62
  datapath_ip/pro_top/U1053/Z (NOR2B1HD1X)                0.30       8.94 r    1.62
  datapath_ip/pro_top/U1052/Z (NOR2B1HD1X)                0.31       9.24 r    1.62
  datapath_ip/pro_top/U1051/Z (NOR2B1HD2X)                0.26       9.50 r    1.62
  datapath_ip/pro_top/U381/Z (INVHDPX)                    0.11       9.61 f    1.62
  datapath_ip/pro_top/U2304/Z (NOR2HD2X)                  0.14       9.75 r    1.62
  datapath_ip/pro_top/U3441/Z (NAND2B1HD1X)               0.16       9.91 f    1.62
  datapath_ip/pro_top/U3386/Z (OAI21HD1X)                 0.17      10.08 r    1.62
  datapath_ip/pro_top/U3385/Z (OAI31HDLX)                 0.15      10.23 f    1.62
  datapath_ip/pro_top/U3384/Z (AND2HD1X)                  0.24      10.46 f    1.62
  datapath_ip/pro_top/bus_baseaddr_w[31] (pro_top)        0.00      10.46 f    1.62
  datapath_ip/U4025/Z (AOI22HD1X)                         0.19      10.65 r    1.62
  datapath_ip/wishbone_master_ip1_wraddr_reg_reg_31_/D (FFSDSHD1X)
                                                          0.00      10.65 r    1.62
  data arrival time                                                 10.65      

  clock clk (rise edge)                                   8.90       8.90      
clock network delay (ideal)                             0.00       8.90      
  clock uncertainty                                      -0.40       8.50      
  datapath_ip/wishbone_master_ip1_wraddr_reg_reg_31_/CK (FFSDSHD1X)
                                                          0.00       8.50 r   
  library setup time                                     -0.26       8.24      
  data required time                                                 8.24      
  ------------------------------------------------------------------------------------
  data required time                                                 8.24      
  data arrival time                                                -10.65      
  ------------------------------------------------------------------------------------
  slack (VIOLATED)                                                  -2.41      


在计算RT的时候，network latency 为0，并没有计算进去，我就是这不理解。

zero_0

因为你用 OCV 去检查
其实根本就不需要 set_clock_latency, ideal 就让它为0，不是 ideal 就让 tool 去计算真实的 delay

妞儿

回复 4# zero_0


  也就是说在DC的时候，就不去设定这个值，只用指定uncertainty就可以了，在icc中，CTS之后有这个值了，就直接按真实的值去计算？?那两个不同时钟域分析的时候，也不需要设定这个值吗？？？比如，在input组的时候，可能start point的控制时钟是clk ,而endpoint 的控制时钟是clk_image，这两个时钟在定义的时候，由于周期的不同，会设定不同的network latency的值，是不是这种情况也可以统统不设定这个值了，直接按照ideal来做？

zero_0

在陈大的置顶帖 “数字后端 FAQ” 就有说明了：

Q1.7 什么时候需要设置latency？
      latency分为source latency 和 network latency 两种。 source latency是源时钟自带的，network latency就是CTS后的clock tree insertion delay。
      在综合时，一般不需要latency，
      除非,
      已知不同clock带有不同的source latency，并且它们之间有时序要求
      预知不同clock会有不同的clock tree insertion delay，不想平衡它们，但是要满足他们之间的时序要求

      做完CTS后，要把network latency去掉

jjun2500

学习了

yi4105635

回复 6# zero_0


    请问做完cts之后，如何去掉network_latency呢？ 是需要什么设置吗？ 目前我刚做完时钟树。等待跑的时候看到帖子了就想问问哈。

y23angchen

6楼答案很牛逼，

zero_0

回复 8# yi4105635


    propagated clock 会覆盖掉ideal clock 的 network latency。
    可以用 remove_clock_latency