STA Timing Report分析

xjg@hmes

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。

xjg@hmes

补充：CRPR 设定的是same_transition，所以这里crpr没起作用

陈涛

拉近2个FF的距离，重做CTS，减小skew

xjg@hmes

回复 3# 陈涛


   谢谢涛哥的回复。这类违例的path有近200条，全部手动拉近FF的距离吗？CTS时的skew已经做到0.15ns了，现在的skew是加上clock route和derating之后的skew。

陈涛

"skew在clock route前0.15ns, clock route后0.5ns左右，加上derating之后，skew变为1.6ns"
这个现象比较奇怪，
1）查clock route的结果，选用RC小的metal，
2）CRPR 设定是否可以去掉same_transition的条件？

xjg@hmes

回复 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吗？

陈涛

only "usefull skew" can help

xjg@hmes

回复 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反转，很奇怪，不知版主有何高见，请指点，谢谢！

陈涛

你的clk不是很快，为什么会有min pulese width？
clk反转是设计上的原因，可以向前端确认，其实这条path的重要问题就是只有半个周期的时间

xjg@hmes

问题解决方法：
减小latency，进而减小derating的影响。
usefull skew也可以解决但是如果违例量很大，就不太好实现。