LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

FIFO - slow write/ fast read, Problem?

Hello everyone,

I have two questions about FIFO in LabVIEW FPGA. When the clock of FIFO writing side(70Mhz) is slower than the clock of reading side(80Mhz), then the reading side will indicate Timeout signal. But I can still read out data continuously.

My questions:

Is there data loss in reading side?

Or even if there is a timeout signal, the reading side will still wait writing side until data is readable?

Thanks

0 Kudos
Message 1 of 12
(4,946 Views)

See https://zone.ni.com/reference/en-XX/help/371599P-01/lvfpgaconcepts/fpga_interface_options/

 

I recommend you right-click and switch them to work in handshaking mode.  This way it is easier to know when you have valid data.

 

Depending on the size of the FIFO and burstiness of the data you should still be able to transfer data without loss from one loop to another even if the receiver is slower.


Certified LabVIEW Architect, Certified Professional Instructor
ALE Consultants

Introduction to LabVIEW FPGA for RF, Radar, and Electronic Warfare Applications
Message 2 of 12
(4,882 Views)

If you use the Timeout mode as you are at the moment, then both sides (fast consumer, slow producer) will continue to work with no problems.

However, when "timeout?" is true, the data is the default-default data value (0 for numbers, false for boolean, etc). Probably you don't want to do anything with this, so consider a Case Structure around any downstream processing (if simple).

 

You can also use the Handshaking mode as suggested above if you prefer, I don't know if that would be better or not in your situation. I typically find the simple timeout sufficient, but I don't have complicated processing downstream from my acquisition on FPGA currently (after the data is passing into the FIFO write).


GCentral
0 Kudos
Message 3 of 12
(4,859 Views)

Hello Terry,

you mean even if the receiver is faster? In my case is receiver faster.

0 Kudos
Message 4 of 12
(4,831 Views)

Hello cbutcher,

thanks for your reply. When "timeout?" is true, I can still receive the data from output. They seems like not the default value, because they keep changing continuously.

0 Kudos
Message 5 of 12
(4,826 Views)

@johnsnow34 wrote:

Hello cbutcher,

thanks for your reply. When "timeout?" is true, I can still receive the data from output. They seems like not the default value, because they keep changing continuously.


Sorry - my mistake. The link here (FIFO Read) shows that the element is undefined if timeout is true. 


GCentral
0 Kudos
Message 6 of 12
(4,813 Views)

Hello cbutcher,

I found this is strange. Help document says:"If Timed Out? is TRUE, Element is undefined and no read occurs."

But read actually still keep going. One of read channels is frame clock of ADC. In this channel the read data is regular and meet the character of frame clock. It does not seem to be undefined.

0 Kudos
Message 7 of 12
(4,805 Views)

Even if the receiver is faster.


Certified LabVIEW Architect, Certified Professional Instructor
ALE Consultants

Introduction to LabVIEW FPGA for RF, Radar, and Electronic Warfare Applications
0 Kudos
Message 8 of 12
(4,799 Views)

If timeout is true you ignore that value and wait for the next cycle.

 


Certified LabVIEW Architect, Certified Professional Instructor
ALE Consultants

Introduction to LabVIEW FPGA for RF, Radar, and Electronic Warfare Applications
0 Kudos
Message 9 of 12
(4,797 Views)

@cbutcher wrote:

@johnsnow34 wrote:

Hello cbutcher,

thanks for your reply. When "timeout?" is true, I can still receive the data from output. They seems like not the default value, because they keep changing continuously.


Sorry - my mistake. The link here (FIFO Read) shows that the element is undefined if timeout is true. 


My experience is that the FIFO will simply output the last valid value (most likely the most resource-efficient method). If your code may produce a timeout, your MUST interpret the Timeout and handle accordingly.  I use a messaging-based communication on FPGA and have been stung by this before. I defined "0" to be no-op, but that doesn't really help in this case.

 

Respect the timeout and all will be OK.

0 Kudos
Message 10 of 12
(4,774 Views)