How to modify delay cycles to enable reading in fifo generator?

[Cesar0182]

Greetings, tell you that I am implementing a SPI design in ISE 17.5 using an asynchronous fifo. The problem I am having is that there is a delay of 5 to 6 read clock cycles (rd_clk = 25 MHz) after writing the first data (wr_clk = 100 Mhz) so that the data written in the fifo is enabled to be read (because the empty signal is still 1). How can I enable reading a cycle of rd_clk after having written the first data? Any suggestions are welcome and thanks in advance.

 

[ads-ee]

Any asynchronous FIFO design will have an inherent latency of the EMPTY and FULL flags as the read and write pointers (address) needs to be sent between the clock domains.

There isn't any way to speed up the de-assertion of the EMPTY flag. The only way to get the EMPTY flag to appear sooner is change your design to use a synchronous FIFO. Where you would have wr_clk of 100 MHz but the read clock is also 100 MHz but is only enabled to read every 4th clock, so it reads at 25 MHz.

 

[dpaul]

Greetings, tell you that I am implementing a SPI design in ISE 17.5 using an asynchronous fifo.

On a side note, I didn't know that Xilinx has an ISE17.5 version.

btw - Did you try to use the FIFO signals read_count and write_count signals (you need to enable the use of these signals when you are configuring the FIFO core at the GUI)?

 

[Cesar0182]

thanks for answering @dpaul, sorry I meant ISE 14.5. Tell you that I don't have the read_count and write_count counters enabled, how could I use them to speed up the empty signal?

 

[ads-ee]

Having a read_count and write_count won't help speed up the empty flag as they are on different clock domains, if you enable them you will see that the two counts are typically 3-4 counts different depending on the read/write clock frequency relationship. This is inherent in the way an asynchronous FIFO operates as the address pointers need to be transferred across clock domains.

Like I wrote in my previous post, you can't improve the empty signal latency unless you change the design to use a synchronous FIFO design.

 

[dpaul]

@Cesar0182 ,
Like I wrote in my previous post, you can't improve the empty signal latency unless you change the design to use a synchronous FIFO design.
That's the answer. You have to accept the latency of the FIFO IP core else design your own FIFO.

 

[FvM]

The OP didn't tell, if the clocks are actually asynchronous. If so, there's still an option to run the read side on a synchronous multiple of the 25 MHz clock to speed up synchronizer operation.

 

[ads-ee]

The OP didn't tell, if the clocks are actually asynchronous. If so, there's still an option to run the read side on a synchronous multiple of the 25 MHz clock to speed up synchronizer operation.

Won't improve the situation unless you use a synchronous FIFO, then you run into the problem where you can't supply two different clocks (that may be synchronous but at different frequencies) to that FIFO.

Back in post #2 I already suggested the best way to deal with the two different clocks if they are actually synchronous to each other. Run the FIFO off the faster wr_clk and only generate FIFO read enables every 4th clock, then the you can use a synchronous FIFO implementation with its reduced empty flag latency.

 

[FvM]

I agree that synchronous solution is preferred. Running the asynchronous read logic at higher speed will nevertheless reduce the synchronizer latency by a respective factor.