在线咨询
eetop公众号 创芯大讲堂 创芯人才网
切换到宽版

EETOP 创芯网论坛 (原名:电子顶级开发网)

手机号码,快捷登录

手机号码,快捷登录

找回密码

  登录   注册  

快捷导航
搜帖子
查看: 13515|回复: 11

[求助] set_clock_latency

[复制链接]
发表于 2014-3-19 20:56:54 | 显示全部楼层 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有账号?注册

x
我在时序分析的时候遇到点问题想不通,希望路过的各位大神指点一二~~
我在做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


然后DC的综合结果,关于clock组的Setup时序分析也没有出现violation,但是将综合后的结果拿去icc做布局布线之后,报出同一条路径上时序却出现了违例,我将两个报告对比了一下,发现了一个问题,在DC的时序报告上,设定的networrk latency在AT 和RT时都计算了,所以,时序分析的时候,路径上没有出现违例,但是在icc中,分析的时候只有在AT的路径上加了network latency ,而在RT路径的计算时,这个值并没有计算进去,这样导致了时序出现违例。我不明白icc中路径上的时序分析是怎么计算的,这个问题应该怎么解决???????
发表于 2014-3-19 22:14:50 | 显示全部楼层
什么阶段的报告,cts之前还是之后,贴报告看看
 楼主| 发表于 2014-3-20 09:08:16 | 显示全部楼层
回复 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,并没有计算进去,我就是这不理解。
发表于 2014-3-20 11:43:54 | 显示全部楼层
因为你用 OCV 去检查
其实根本就不需要 set_clock_latency, ideal 就让它为0,不是 ideal 就让 tool 去计算真实的 delay
 楼主| 发表于 2014-3-20 14:34:46 | 显示全部楼层
回复 4# zero_0


  也就是说在DC的时候,就不去设定这个值,只用指定uncertainty就可以了,在icc中,CTS之后有这个值了,就直接按真实的值去计算??那两个不同时钟域分析的时候,也不需要设定这个值吗???比如,在input组的时候,可能start point的控制时钟是clk ,而endpoint 的控制时钟是clk_image,这两个时钟在定义的时候,由于周期的不同,会设定不同的network latency的值,是不是这种情况也可以统统不设定这个值了,直接按照ideal来做?
发表于 2014-3-20 15:53:53 | 显示全部楼层
在陈大的置顶帖 “数字后端 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去掉
发表于 2014-8-12 20:29:16 | 显示全部楼层
学习了
发表于 2015-11-10 14:09:18 | 显示全部楼层
回复 6# zero_0


    请问做完cts之后,如何去掉network_latency呢? 是需要什么设置吗? 目前我刚做完时钟树。等待跑的时候看到帖子了就想问问哈。
发表于 2015-11-10 14:30:29 | 显示全部楼层
6楼答案很牛逼,
发表于 2015-11-10 19:22:42 | 显示全部楼层
回复 8# yi4105635


    propagated clock 会覆盖掉ideal clock 的 network latency。
    可以用 remove_clock_latency
您需要登录后才可以回帖 登录 | 注册

本版积分规则

关闭

站长推荐 上一条 /1 下一条


小黑屋| 手机版| 关于我们| 联系我们| 在线咨询| 隐私声明| EETOP 创芯网
( 京ICP备:10050787号 京公网安备:11010502037710 )

GMT+8, 2024-11-15 00:36 , Processed in 0.026700 second(s), 9 queries , Gzip On, Redis On.

eetop公众号 创芯大讲堂 创芯人才网
快速回复 返回顶部 返回列表