clock network delay很大的问题

tirasf

下面是其中的一条path的timing report:

Startpoint:SD_BRIDGE_TOP/U_SDIO_SIDE/r_rd_data_reg_301_0

                (rising edge-triggeredflip-flop clocked by MAINCLK_2)

Endpoint:SD_BRIDGE_TOP/U_AXI_SIDE/r_out_rd_data_reg_45__r_out_rd_data_reg_46_0

                (rising edge-triggeredflip-flop clocked by CLK_STU_AXI_ST)

Path Group: CLK_STU_AXI_ST

Path Type: max

Point                                                                                             

Fanout       Incr       Path

------------------------------------------------------------------------------------------------------------------------------------

  clock network delay(propagated)
8.050
8.050

  SD_BRIDGE_TOP/U_SDIO_SIDE/r_rd_data_reg_301_0/CK(SDFFRPQ_X0P5M_A8TH)
0.000
8.050 r

  SD_BRIDGE_TOP/U_SDIO_SIDE/r_rd_data_reg_301_0/Q(SDFFRPQ_X0P5M_A8TH)
0.389 &
8.439 r

  SD_BRIDGE_TOP/U_SDIO_SIDE/rd_data[301](net)

3

  SD_BRIDGE_TOP/U_AXI_SIDE/Syn1st461/B1(AOI22_X1M_A8TH)
0.012 &
8.451 r

  SD_BRIDGE_TOP/U_AXI_SIDE/Syn1st461/Y(AOI22_X1M_A8TH)

0.105 &
8.556 f

  SD_BRIDGE_TOP/U_AXI_SIDE/n300(net)
1

  SD_BRIDGE_TOP/U_AXI_SIDE/Syn1st464/B(NAND4_X1M_A8TL)
0.000 &
8.556 f

  SD_BRIDGE_TOP/U_AXI_SIDE/Syn1st464/Y(NAND4_X1M_A8TL)
0.126 &
8.682 r

  SD_BRIDGE_TOP/U_AXI_SIDE/N177(net)
1

   SD_BRIDGE_TOP/U_AXI_SIDE/r_out_rd_data_reg_45__r_out_rd_data_reg_46_0/D0(SDFFRPQ2BMULT21_X1M_A8TR_C34)
0.011 &
8.693 r

data arrival time

8.693

max_delay                                                                                                                                     5.050
5.050

clock network delay(propagated)

0.581
5.631

clock reconvergence pessimism
0.000
5.631

inter-clock uncertainty

-0.352
5.279

library setup time
-0.101
5.178

data required time

5.178

--------------------------------------------------------------------------------------------------------------------------------------

data required time
5.178

data arrival time
-8.693

--------------------------------------------------------------------------------------------------------------------------------------

  slack(VIOLATED)
-3.515

我自己也看了clock tree的情况，找不出原因了，求大神给点建议，谢谢了。

nature19900303

感觉你这是两个时钟，一个是MAINCLK_2，另一个是CLK_STU_AXI_ST，如果这两个不是同步时钟的话，应该set_false_path。
或者你其中一个时钟set_clock_latency?
仔细检查一下，应该不至于直接由8ns的delay吧

tirasf

回复 2# nature19900303
怎么看他们是不是同步时钟呢？

tirasf

回复 2# nature19900303


上面是clock MAINCLK_2 的clock tree 的情况，是不是没有长上tree?

nature19900303

回复 3# tirasf

一个时钟分频成其他时钟，使用create_generated_clock定义的话，源时钟以及分频时钟都属于同步时钟。也就是说各个时钟之间具有固定的相位关系。

nature19900303

回复 4# tirasf

skew那么大，肯定是不对的，可能是你的时钟约束有问题。你把各个时钟的关系画个图，然后把你的时钟约束贴出来看看。

tirasf

回复 6# nature19900303
时钟MAINCLK_2和CLK_STU_AXI_ST之间没有关系

ikey

回复 7# tirasf


     clock tree 没有做平，skew很大，不正常。     首先，trace clock tree 结构，根据报告，找出哪些子tree做长或没做tree，可以在EDI (Innovus) 先用这个命令： > ckSynthesis -forceReconvergent -check -trace cts.trace 或者 > reportClockTree-report cts.trace (<---Innovus可能用不了这个命令)。


    其次，分析是什么原因使得tree做长，是不是clock spec file里面没有正确合理设置GlobalLeafPin？还是GlobalThroughpin/UnsyncPin？
    然后，分析netlist中clock tree structure，并结合constraint中有关create_clock和create_generated_clock是如何定义clock，判断clock spec file是否合理的在该断的时候断，不该断的地方断，同时需要分析design的要求，是不是不该让tool穿的timing path，比如不是STA 需要check的timing path是否设置了set_disable_timing or set_false_path，如果不该穿的path让tool去穿，会使得clock tree做的很长。
    最后，需要总结这次skew很长的原因，避免下次犯同样的问题或者疏漏。设计犯错很正常，但同样的问题反复犯就不正常。

nature19900303

回复 7# tirasf


   你的时钟的约束是有问题的：

• CLK_STU_AXI_ST并没有create_clock;
• CLK_STU_SDIF2_DIV的master和source不是同一个时钟，你确认一下是否正确？
• 下面一堆set_clock_uncertainty的设置有问题，都去掉吧
  set_clock_uncertainty -setup 0.2 [get_clocks MAINCLK_2] ；这样
• 没有关系的时钟之间设置false_path

tirasf

回复 8# ikey
表示没有用过EDI，你说的这些我会去check,谢谢你。