clock network delay很大的问题

下面是其中的一条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

FanoutIncrPath

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

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_delay5.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的情况，找不出原因了，求大神给点建议，谢谢了。

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

怎么看他们是不是同步时钟呢?

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

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

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很长的原因，避免下次犯同样的问题或者疏漏。设计犯错很正常，但同样的问题反复犯就不正常。

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

• 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

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

上面你说的几点都不是问题所在，现在我打算插入一个BUFFER试试。谢谢你的建议。