11-27-2019 12:16 AM
I have a FIFO created using the FIFO Generator IP core with asymmetric aspect ratios. Write width is 256 bits, Read width is 32 bits. The input of the FIFO is connected to MIG.
My data is a simple counter. I probed the input and output of the FIFO and it seems like the output of the FIFO is missing some data and sometimes the order gets shuffled. I am not sure why this is the case, I have a FIFO with write width 32 bits and read width 256 bits and that seems to work just fine.
Here's a snippet of the output of the FIFO:
And here's a snippet of the same sequence of counts on the input of the FIFO:
Thank you! :)
11-27-2019 12:49 AM
From your snippet post, we cannot see the input data of the FIFO clearly, could you post the more detailed screenshot with clk and other FIFO control signals?
11-27-2019 01:12 AM
Thanks for the reply! The input data snippet has the 256 bits input in the highlighted portion (basically the sequence 046,047,048,049,04a,04b,04c,04d) corresponding to the output data snippet which goes from 048 to 04b and back 04a and so on.
I probed them using an ILA so I'm not sure how I would be able to get you the screenshot of the clock. Write clock is 100MHz and Read clock is 100.8MHz. If you can let me know what would be the best way to show you the clock, I can do it.
11-27-2019 02:44 AM
Strange.... is data always in the same wrong order? Are clocks over the spec? what is reading from the FIFO?
11-27-2019 05:39 AM
11-27-2019 03:02 PM
Thank you for the replies. Firstly, thanks @drjohnsmith I added a 2-ff synchroniser for the output to be synchronised with the ILA's clock. The problem still persists though.
@archangel-lightworks : the data is not always in the same wrong order. I analysed one complete read and the order of the data does not seem to have any particular order as far as I can see (pictures below). The read clock is 100.8MHz and write clock is 100MHz and the ILA's clock is 100MHz and I believe that is within spec?? A block throttled pipe module that connects to the Frontpanel API of Opal Kelly is reading from the FIFO. (http://assets00.opalkelly.com/library/FrontPanel-UM.pdf page 59 okBTPipeOut)
Here is screenshot of all the skips/shuffled order of data:
Other settings on my FIFO generator are Independent clocks Block RAM, Write Depth => 256 (read depth => 2048), Reset Synchronisation is enabled, Multiple Programmable Threshold Constants at Assert => 256 and Negate => 1024. Attached is my state machine for reading data (just 3 states that check if the fifo is empty or not empty and one for reset).
Any suggesetions would be great! :)
11-27-2019 04:19 PM
@drjohnsmith is right. The read ILA needs to be on the read clock. The 2-ff synchronizer will essentially eliminate metastability at the input of the ILA, but the two clocks will always be walking through each other. You will never know the timing between the read and when the data is on the ILA. Also, you need to check which clock the empty is generated with, read clock or write clock and how many clocks it takes for the empty to be asserted. You may be occasionally trying to read an empty FIFO.
11-27-2019 06:41 PM
Hi @bruce_karaffa ,
Thanks for pointing that out. But the output that is connected to my pc via a USB also shows similar skipping in the counter value. I believe that would not be due to my ILA clock. This is where I actually started and back tracked to the issue in this post and wasn't sure why this was happening.
About the prog_empty status flag, I remember it being associated with the read clock?? And so I used it in a state machine with the read clock. Would that be the right thing to do?
I toggle read_enable signal high only when the fifo is not prog_empty(1024) and low when prog_empty (256). Total fifo depth is 2048. I hope that's the the correct logic.
11-27-2019 06:41 PM
I think it's likely a problem caused by two async clock domains.
You can insert the ila capture directly the BRAM ports(include all signals: portA we en addr din and dout, all these signals should be in the PortA clock domain; and same signals in the portB in portB clock domain, you can set ila clock domain in the setup debug). When you get these waveform, I think you can see the problem more clearly.