实施可行性警告：时钟驱动太多寄存器

这看起来像旧的工具称为“门控时钟”。
用组合逻辑产生的时钟驱动边沿触发的翻转是个坏主意。
我不知道这些工具是否会在这些实例中自动插入BUFG，但即使它们确实如此，如果LUT输出出现毛刺，也会出现问题。
您需要了解LUT生成时钟的原因，并找到更好的时钟源或更改使用其边沿的逻辑。
-  Gabor
在原帖中查看解决方案



以下为原文

This looks like what the older tools called "gated clock."  It's a bad idea to drive an edge-triggered flop with a clock generated by combinatorial logic.  I don't know if the tools would automatically insert a BUFG in these instances, but even if they did you could get problems if the LUT output glitches.  You'll need to see why you have a clock generated by a LUT and wither find a better clock source or change the logic that uses its edges.
-- GaborView solution in original post

这看起来像旧的工具称为“门控时钟”。
用组合逻辑产生的时钟驱动边沿触发的翻转是个坏主意。
我不知道这些工具是否会在这些实例中自动插入BUFG，但即使它们确实如此，如果LUT输出出现毛刺，也会出现问题。
您需要了解LUT生成时钟的原因，并找到更好的时钟源或更改使用其边沿的逻辑。
-  Gabor



以下为原文

This looks like what the older tools called "gated clock."  It's a bad idea to drive an edge-triggered flop with a clock generated by combinatorial logic.  I don't know if the tools would automatically insert a BUFG in these instances, but even if they did you could get problems if the LUT output glitches.  You'll need to see why you have a clock generated by a LUT and wither find a better clock source or change the logic that uses its edges.
-- Gabor

嗨Gabor，
我也有类似的问题。
我正在使用第三方的edn文件。
网表有一个时钟输出，我可以用来驱动其他逻辑/模块。
我发现当我打开合成结果时，我看到时钟输出和实际MMCM clock_out之间的单输入一输出LUT。
但是在实现结果中，有时候这个LUT得到了优化，有时则没有。
如果没有，我收到的警告如下：
[放置30-568] A LUT'flash_test_i / dma_ip_0 / inst / adb3_target_pcie_v7x8_0 / i_0'正在驱动4549个寄存器的时钟引脚。
这可能会导致大量的保留时间违规。
最初涉及的几个寄存器是：flash_test_i / axi_interconnect_1 / s00_couplers / auto_cc / inst / gen_clock_conv.gen_async_conv.asyncfifo_axi / inst_fifo_gen / gaxi_full_lite.gwrite_ch.gwdch2.axi_wdch / grf.rf / rstblk / ngwrdrst.grst.g7serrst.wr_rst_reg_reg [1] {FDPE
} flash_test_i / axi_interconnect_1 / s00_couplers / auto_cc / inst / gen_clock_conv.gen_async_conv.asyncfifo_axi / inst_fifo_gen / gaxi_full_lite.gwrite_ch.gwdch2.axi_wdch / grf.rf / rstblk / ngwrdrst.grst.g7serrst.wr_rst_reg_reg [0] {FDPE} flash_test_i / axi_interconnect_1 /
s00_couplers / auto_cc / inst / gen_clock_conv.gen_async_conv.asyncfifo_axi / inst_fifo_gen / gaxi_full_lite.gwrite_ch.gwdch2.axi_wdch / grf.rf / rstblk / ngwrdrst.grst.g7serrst.wr_rst_asreg_reg {FDPE} flash_test_i / axi_interconnect_1 / s00_couplers / auto_cc / inst / gen_clock_conv。
gen_async_conv.asyncfifo_axi / inst_fifo_gen / gaxi_full_lite.gwrite_ch.gwdch2.axi_wdch / grf.rf / rstblk / ngwrdrst.grst.g7serrst.wr_rst_asreg_d2_reg {埃塞俄比亚联邦民主共和国} flash_test_i / axi_interconnect_1 / s00_couplers / auto_cc /安装/ gen_clock_conv.gen_async_conv.a
syncfifo_axi / inst_fifo_gen / gaxi_full_lite.gwrite_ch.gwdch2.axi_wdch / grf.rf / rstblk / ngwrdrst.grst.g7serrst.wr_rst_asreg_d1_reg {FDRE}
而设计无法满足时机要求。
我还没想到它在哪种情况下还没有进行优化。
我使用的版本是Vivado 2014.2。
我正在使用IP打包器来开发设计。



以下为原文

Hi Gabor,
 
I am having similar problem too. I am using an edn file from the third party. There is a clock output from the netlist that I can use to drive other logics/modules. What I found is that when I open the synthesis result, I see a one-input-one-output LUT between the clock output and the actual MMCM clock_out. But in implementatoin result, sometimes this LUT got optimized out, sometimes it doesn't. And when it doesn't, I got the warning like:
 
[Place 30-568] A LUT 'flash_test_i/dma_ip_0/inst/adb3_target_pcie_v7x8_0/i_0' is driving clock pin of 4549 registers. This could lead to large hold time violations. First few involved registers are:
flash_test_i/axi_interconnect_1/s00_couplers/auto_cc/inst/gen_clock_conv.gen_async_conv.asyncfifo_axi/inst_fifo_gen/gaxi_full_lite.gwrite_ch.gwdch2.axi_wdch/grf.rf/rstblk/ngwrdrst.grst.g7serrst.wr_rst_reg_reg[1] {FDPE}
flash_test_i/axi_interconnect_1/s00_couplers/auto_cc/inst/gen_clock_conv.gen_async_conv.asyncfifo_axi/inst_fifo_gen/gaxi_full_lite.gwrite_ch.gwdch2.axi_wdch/grf.rf/rstblk/ngwrdrst.grst.g7serrst.wr_rst_reg_reg[0] {FDPE}
flash_test_i/axi_interconnect_1/s00_couplers/auto_cc/inst/gen_clock_conv.gen_async_conv.asyncfifo_axi/inst_fifo_gen/gaxi_full_lite.gwrite_ch.gwdch2.axi_wdch/grf.rf/rstblk/ngwrdrst.grst.g7serrst.wr_rst_asreg_reg {FDPE}
flash_test_i/axi_interconnect_1/s00_couplers/auto_cc/inst/gen_clock_conv.gen_async_conv.asyncfifo_axi/inst_fifo_gen/gaxi_full_lite.gwrite_ch.gwdch2.axi_wdch/grf.rf/rstblk/ngwrdrst.grst.g7serrst.wr_rst_asreg_d2_reg {FDRE}
flash_test_i/axi_interconnect_1/s00_couplers/auto_cc/inst/gen_clock_conv.gen_async_conv.asyncfifo_axi/inst_fifo_gen/gaxi_full_lite.gwrite_ch.gwdch2.axi_wdch/grf.rf/rstblk/ngwrdrst.grst.g7serrst.wr_rst_asreg_d1_reg {FDRE}
 
And the design couldn't meet timing. I haven't figured out in which case it is not optimized out yet. The version I am using is Vivado 2014.2. I am using IP packager to develop the design.

顺便说一下，我设计中的LUT没有做任何事情，我认为它只是一个缓冲区。
那里没有时钟启用。



以下为原文

BTW, the LUT in my design doesn't do anything, it is just a buffer I think. And there is no clock enable there.

您可能希望为此问题启动一个新线程，可能在Vivado论坛中。
我唯一的想法是你可以在用于将第三方模块连接到时钟负载的线路上放置BUFFER_TYPE = NONE属性。
但是我不确定这在Vivado中是否仍然有效。
我仍然主要使用ISE。
-  Gabor



以下为原文

You may want to start a new thread for this issue, perhaps in the Vivado forum.  My only thought is that you could place a BUFFER_TYPE = NONE attribute on the wire you use to connect the third-party module to the clock loads.  However I'm not sure if that is still valid in Vivado.  I'm still mostly using ISE.
-- Gabor