FPGA FIFO BUG?

[PGH]

Sorry.  2nd try, this time with attachments.

Hello all,

I believe I have found a bug in the Block Memory implementation of FIFO's on the FPGA, that shows up in single cycle timed loops.

It seems that there is a delay of 3 clock ticks (in this case) between the time any data goes in to the empty FIFO (fifo write) and it re-emerges from the fifo (fifo read).  The problem goes away if I use flip-flops for the FIFO.  But for a large FIFO, this is not a real option.  The problem also "goes away" in emulation mode.

I am attaching a screen shot of "fpga_fifo_bug.vi" to illustrate the issue.  I am also attaching the vi itself.

I hope you users or NI can set me straight, if I'm doing something wrong, or if its really a bug, I hope that NI will fix it soon.

Sincerely,

Peter H.

[jdigiova]

This is not a bug.  As stated in the FIFO Property help documentation, using Block memory with a local FIFO may take up to 6 clock cycles for data to be available on the read.  You must monitor the Full and Empty outputs to determine when the data is ready.

Regards,

Joseph D.

[PGH]

Thanks Joseph,  that was very helpful.

I guess one could say that there is a bug in the FPGA simulator, in the sense that it does not incorporate the several clock tick delay in the memory block type FIFO.  That's something that could be fixed.  Another thing that would help is a cautionary message in the FIFO configuration window.

---Peter H.

[jdigiova]

I have passed your feedback on to the appropriate people. Thank you for your suggestions and helping make LabVIEW FPGA even better.

Regards,

Joseph D.

[Oli_Wachno]

Hi all,

does this behaviour also hold true for the 7.1(.1) version? I have a u32x32 FIFO in block RAM that is sometimes quite unreliable.... 😞

Regards

Oliver

[Berto]

Hi Oliver,

From what I'm seeing, the 6 cycle latency was fixed in LabVIEW FPGA 8.0.  So you will be having that behavior in 7.1.1 unfortunately.

Perhaps we could get you on the upgrade path to 8.2 -- the project functionality is excellent for FPGA / RT Host applications.

Thanks,
mike

[PGH]

Oliver,

The FIFO latency problem I am having is with Laview FPGA 8.0.0

I don't think upgrading from 7 to 8 would help you as far this problem goes.  But I can say that the overall experience with Labview FPGA is much better under 8 than it was under 7.

---Peter

[Intaris]

OK, first, I apologise for the level of Thread revival I am indulging in here....

I am having a problem understanding some behaviour of my current FPGA code with Block RAM FIFOs communicating between different clock regions.

I output my data to a device and read it in immediately.  I see a latency of approximately 32 output cycles.  While I have certain amounts of pipelining in place which can result in a certain amount of delays, I'm a bit lost when it comes to explaining the rest.

Then I saw in the help for Block RAM FIFOs that there can be a latency of 5 or 6 read / write cycles before the value written to the FIFO comes out the other end.

Seeing how I am using one FIFO TO my devide and one FIFO FROM my device, this latency would be doubled in my case.

How much of my observed delay between output and input can be explained by utilising FIFOs (Block RAM, 14-bit and 16-bit with built-in control)?

What is the current status of this latency in LV 2012 SP1?

Shane

[Dragis]

What specifically do you mean by outputting data to/from a device? If you are using DMA or other off-chip communication the latency will be much longer than 5 to 6 cycles. 

[Intaris]

No, theres no dma involved. The data goes to a dac via a CLIP and is then read in again from ADC again via CLIP. All communication is FPGA level only.

The CLIP IO is registered on input and output, so that explains SOME delay.  But the total delay seems a bit large.