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

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

手机号码,快捷登录

手机号码,快捷登录

找回密码

  登录   注册  

快捷导航
搜帖子
查看: 9520|回复: 24

[求助] PrimeTime分析同一条路径的时候为什么用不同的corner的delay信息

[复制链接]
发表于 2013-3-22 12:18:13 | 显示全部楼层 |阅读模式

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

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

x
求助,大侠
我现在有如下一个report
Startpoint: rx_elastic_buf/skp_set_reg
               (rising edge-triggered flip-flop clocked by rx_cdr_clk_1)
  Endpoint: rx_elastic_buf/asfifo_usb3/fifo_reg_15__10_
               (rising edge-triggered flip-flop clocked by rx_cdr_clk_1)
  Path Group: rx_cdr_clk_1
  Path Type: max

  Point                                                   Incr       Path
  ------------------------------------------------------------------------------
  clock rx_cdr_clk_1 (rise edge)                          0.90       0.90
  clock network delay (propagated)                        0.74 *     1.64
  rx_elastic_buf/skp_set_reg/CK (DFFRX4)                  0.00       1.64 r
  rx_elastic_buf/skp_set_reg/QN (DFFRX4)                  0.40 *     2.05 r
  U4201/Y (OAI2BB1X4)                                     0.19 *     2.24 r
  toplevelASTtlrInst211/Y (NAND2BX4)                      0.08 *     2.32 f
  U2181ASTttcInst98/Y (BUFX20)                            0.14 *     2.46 f
  U2181ASTipoInst262/Y (BUFX8)                            0.14 *     2.60 f
  U4198/Y (NOR3X4)                                        0.10 *     2.70 r
  U4198ASTttcInst75/Y (BUFX12)                            0.17 *     2.88 r
  rx_elastic_buf/asfifo_usb3/fifo_reg_15__10_/U3/Y (CLKMX2X2)
                                                          0.24 *     3.12 f
  rx_elastic_buf/asfifo_usb3/fifo_reg_15__10_/D (DFFHQX1)
                                                          0.00 *     3.12 f
  data arrival time                                                  3.12

  clock rx_cdr_clk_1 (rise edge)                          2.70       2.70
  clock network delay (propagated)                        0.35 *     3.05
  rx_elastic_buf/asfifo_usb3/fifo_reg_15__10_/CK (DFFHQX1)           3.05 r
  library setup time                                     -0.20 *     2.85
  data required time                                                 2.85
  ------------------------------------------------------------------------------
  data required time                                                 2.85
  data arrival time                                                 -3.12
  ------------------------------------------------------------------------------
  slack (VIOLATED)                                                  -0.27

我发现后面一个clock的delay用的值是best case,而前面一个clock是worst case
为什么会这样呢
发表于 2013-3-22 13:28:48 | 显示全部楼层
对啊 ,工具肯定是从最悲观考虑的,你是不是load了max和min两个库?
 楼主| 发表于 2013-3-22 14:14:30 | 显示全部楼层
回复 2# smartyaya


    同一个路径的同一个timing分析怎么会前面用worst后面用best呢?
发表于 2013-3-22 16:18:18 | 显示全部楼层
你report一下你的design看下以下信息是不是正确的:
Operating Conditions:
  analysis_type                          on_chip_variation
  operating_condition_min_name           BALANCED
  process_min                            1
  temperature_min                        110
  voltage_min                            0.85
  tree_type_min                          balanced_case

  operating_condition_max_name           BALANCED
  process_max                            1
  temperature_max                        110
  voltage_max                            0.85
  tree_type_max                          balanced_case
发表于 2013-3-22 16:24:50 | 显示全部楼层
如果你的analysis_type是OCV方式,而你的库有不同的operate condition 比如两种bestcase和worsecase,你可以用report_lib 看下有几种operate condition:
Operating Conditions:

   Name                Process     Temp        Voltage     Tree Type
   ---------------------------------------------------------------------------
   tt0p85v110c           1.000     110.000       0.850     balanced_case

如果只有一种,开OCV,那么lunchpath和capturepath都用这种,如果有两种,你还开了OCV,就会出现你这种情况,你这种情况,太悲观了,是不正确的。
发表于 2013-3-22 16:25:45 | 显示全部楼层
不知道我说清楚没。
发表于 2013-3-22 16:31:43 | 显示全部楼层
如果是两种case的库的话,load完库,可以用这个来控制,防止出现你那种情况。
set_operating_conditions # Set process, temperature, and voltage
   [-analysis_type type]  (Analysis type:
                           Values: single, bc_wc, on_chip_variation)
   [-library lib]         (Library to search)
   [-max max_condition]   (Max operating condition name)
   [-min min_condition]   (Min operating condition name)
   [-max_library max_lib] (Library to search for max condition)
   [-min_library min_lib] (Library to search for min condition)
   [-object_list objects] (Cells and ports to set operating conditions on)
   [condition]            (Single operating condition name)
发表于 2013-3-22 16:33:32 | 显示全部楼层
可以把analysis_type 设置成BC_WC,应该就不会出现你刚才的现象了。。
发表于 2013-3-24 13:00:26 | 显示全部楼层
大致理解到了,感谢这么仔细的回答,学习中
 楼主| 发表于 2013-3-25 09:00:25 | 显示全部楼层
你好,谢谢你的耐心解答,我大概理解你的意思,但是我试了一下你说的办法却不行,报错如下:
Error: value 'bc_wc' for option '-analysis_type' is not valid.  Specify one of:
        single, on_chip_variation (CMD-031)
我用的pt 2012版本

如果我改成2007版本,则没有这个问题,分析的路径也是正确的。
您知道为什么吗
您需要登录后才可以回帖 登录 | 注册

本版积分规则

关闭

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


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

GMT+8, 2024-11-22 03:48 , Processed in 0.025012 second(s), 8 queries , Gzip On, Redis On.

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