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

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

手机号码,快捷登录

手机号码,快捷登录

找回密码

  登录   注册  

快捷导航
搜帖子
查看: 18221|回复: 36

[求助] STA Timing Report分析

[复制链接]
发表于 2013-4-3 17:24:51 | 显示全部楼层 |阅读模式

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

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

x
本帖最后由 xjg@hmes 于 2013-4-3 17:34 编辑

Startpoint: rxRX/*/FE1_reg
               (rising edge-triggered flip-flop clocked by RXCK_LB_EXT)
  Endpoint: rxRX/*/r_CDERR_LEN_reg_reg_11_
               (rising edge-triggered flip-flop clocked by RDCK_LB_EXT_SEL')
  Path Group: RDCK_LB_EXT_SEL
  Path Type: max
  Scenario: USER_SETUP_11_CMAX_HOT

  Point                                                      Incr       Path
  ---------------------------------------------------------------------------------
  clock RXCK_LB_EXT (rise edge)                              0.00       0.00
  clock network delay (propagated)                           8.82       8.82
  rxRX/*/FE1_reg/CP (F2QX4)                                  0.00       8.82 r
  rxRX/*/FE1_reg/Q (F2QX4)                                   0.19 &     9.01 r
  rxRX/*/U4/Z (IVX1)                                         0.05 &     9.06 f
  rxRX/*/U3/Z (NR2X1)                                        0.14 &     9.19 r
  rxRX/*/Z (IVX6)                                            0.11 &     9.30 f
  rxRX/*/Z (ND2X12)                                          0.07 &     9.38 r
  rxRX/*/add_place_opt_381/Z (IVX12)                         0.05 &     9.43 f
  rxRX/*/add_post_place_optX2_154/Z (IVX16)                  0.04 &     9.47 r
  rxRX/*/add_post_place_optX2_153/Z (IVX16)                  0.05 &     9.52 f
  rxRX/*/add_place_opt_376/Z (IVX16)                         0.11 &     9.63 r
  rxRX/*/add_place_opt_277/Z (NIVX16)                        0.14 &     9.77 r
  rxRX/*/U115/Z (ND2IX1)                                     0.10 &     9.87 r
  rxRX/*/U117/Z (ND2X1)                                      0.24 &    10.11 f
  rxRX/*/r_CDERR_LEN_reg_reg_11_/D (FD1EQX4)                 0.03 &    10.13 f
  data arrival time                                                    10.13


clock RDCK_LB_EXT_SEL' (rise edge)                       1.98       1.98
  clock network delay (propagated)                           7.18       9.16
  clock reconvergence pessimism                              0.00       9.16
  rxRX/*/r_CDERR_LEN_reg_reg_11_/CP (FD1EQX4)                9.16 r
  library setup time                                         -0.35       8.81
  data required time                                                    8.81
  ---------------------------------------------------------------------------------
  data required time                                                    8.81
  data arrival time                                                   -10.13
  ---------------------------------------------------------------------------------
  slack (VIOLATED)                                                     -1.32

derating要求:-late 1.146 -early 1.0  

请教高手有何良方解决这个violation?

1、skew在clock route前0.15ns,clock route后

0.5ns左右,加上derating之后,skew变为1.6ns。所以setup违例

这个latency已经是调试过最小的一个。

2、usefull skew的方法暂不考虑

3、RDCK_LB_EXT_SEL' 是clock翻转吧,与前端沟通不能设muilti-cycle。

 楼主| 发表于 2013-4-3 17:27:57 | 显示全部楼层
补充:CRPR 设定的是same_transition,所以这里crpr没起作用
发表于 2013-4-3 21:47:45 | 显示全部楼层
拉近2个FF的距离,重做CTS,减小skew
 楼主| 发表于 2013-4-4 08:19:32 | 显示全部楼层
回复 3# 陈涛


   谢谢涛哥的回复。这类违例的path有近200条,全部手动拉近FF的距离吗?CTS时的skew已经做到0.15ns了,现在的skew是加上clock route和derating之后的skew。
发表于 2013-4-4 09:03:05 | 显示全部楼层
"skew在clock route前0.15ns, clock route后0.5ns左右,加上derating之后,skew变为1.6ns"
这个现象比较奇怪,
1)查clock route的结果,选用RC小的metal,
2)CRPR 设定是否可以去掉same_transition的条件?
 楼主| 发表于 2013-4-4 09:11:55 | 显示全部楼层
回复 5# 陈涛

谢谢您的回复。crpr的设定是客户要求,不能改变。
clock route已经选用高层rc较小的layer,clock route完skew0.5还能接受,关键是derating的影响。
这种timing path即使我在cts时skew做到0ns,因为7ns的latency,加上derating计算后skew也是1ns左右。
Pre CTS也考虑了derating的margin去优化的。
ICC CTS时能考虑derating去做CTS吗?
发表于 2013-4-4 09:18:29 | 显示全部楼层
only "usefull skew" can help
 楼主| 发表于 2013-4-4 10:37:26 | 显示全部楼层
本帖最后由 xjg@hmes 于 2013-4-4 10:40 编辑

回复 7# 陈涛


   谢谢版主指点。usefull skew我也用过,但是带来两个其他问题。
1、normal setup使用usefull skew修完后,scan capture的setup和normal hold出现较大违例
2、min pulse width出现违例。使用的都是INV,因为一个INV的delay在worst条件下大概0.08ns
左右,如果加1ns的delay需要10个INV左右。开始我考虑用少量INV加上net delay,这样报出大量
的min pulse width违例;后来我改用cell delay(不考虑net delay),min pulese width违例减小一点,但是还是存在。
所以 ,我的前提是暂时不考虑uesfull skew的方法。想从其他方面着手,例如减小latency、考虑OCV的CTS、PreCTS考虑OCV加margin的优化等方法,都无济于事,真的很无奈。。。
另外,FF lib中记载是rise edge查的,现在timing report中出现clock反转,很奇怪,不知版主有何高见,请指点,谢谢!
发表于 2013-4-4 11:28:42 | 显示全部楼层
你的clk不是很快,为什么会有min pulese width?
clk反转是设计上的原因,可以向前端确认,其实这条path的重要问题就是只有半个周期的时间
 楼主| 发表于 2013-6-4 15:58:28 | 显示全部楼层
问题解决方法:
减小latency,进而减小derating的影响。
usefull skew也可以解决但是如果违例量很大,就不太好实现。
您需要登录后才可以回帖 登录 | 注册

本版积分规则

关闭

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

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

GMT+8, 2024-11-6 00:43 , Processed in 0.023241 second(s), 8 queries , Gzip On, Redis On.

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