cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
rbsexton
Visitor
Visitor
340 Views
Registered: ‎05-09-2019

Vivado inserts LUT into FIFO clock path on Zynq

I'm having difficulty with a design that uses an independent clock FIFO.   I've attached the slow side of the clock to a global clock net running at a Lower frequency than the primary interface.    I had previously used a programmable divider for the low speed interface, but I removed that to get cleaner synthesis.    The IP works in the field.

What I'm seeing is that Vivado is reporting that a LUT is generating a lot of warnings: 

 

A LUT 'debug_engine/u_debug/u_fifo_to_dut_i_1' is driving clock pin of 100 registers. This could lead to large hold time violations. First few involved registers are:
	debug_engine/u_debug/u_fifo_from_dut/U0/inst_fifo_gen/gconvfifo.rf/grf.rf/gntv_or_sync_fifo.gl0.wr/wpntr/gic0.gc0.count_reg[8]

The part that makes no sense to me is that the clock pins in question are are supposed to be hooked up to a regional clock derived from a global clock:

 

  BUFR buf_debug(.O(clk_dut), .I(clk_dut_base), .CE(1'b1), .CLR(1'b0)); // 

Here the FIFO clocks: 

 

        debug_fifo u_fifo_from_dut(
                .rst(fifo_reset_sr[7]),
                .rd_clk(clk_bus),
                .wr_clk(!clk_dut),
....

When I open the implemented design, I see a lut (u_fifo_to_dut_i_1) that I didn't create.  I also didn't create it implicitly.  

VivadoExtraLUT.png

My only theory is that some low-speed side IO's were brought over to the high side for debugging purposes.  I connected those to the high side, just in case.  The problem persists.    

The FIFO in question is negative edge triggered.   The data sheet for the FIFO says that I can do this by inverting the input clock and it will be 'absorbed' into the destination flops.  My other theory is that the absorption isn't happening.

 

 

0 Kudos
0 Replies