LabVIEW FPGA: 4 to 1 data flow via FIFO

[etgohomeok]

Hello,

I am working on an application with a FlexRIO system wherein I have pixels coming in from a 4-tap camera (and therefore I have 4 pixels coming in per clock cycle). The camera is part of a spectrometer and the pixels are not equally spaced in the domain that I need to analyze them, so I need to resample them using a linear interpolation. I therefore need to be able to process the pixels one by one. I am attaching a screenshot of some LabVIEW code that represents what I am trying to do.

The top loop represents the data acquisition, with four pixels coming in per cycle in a 40MHz SCTL. Below is a loop that tries to read the pixels one at a time in a 160MHz SCTL. The 160MHz is a derived clock from the 40MHz main clock. I output the number of pixels written in the top loop and the number read in the bottom loop. These numbers should be equal, and they are when I run the code as a simulation. However, when I compile the code and run it on the actual FPGA, the number written is much higher than the number read.

The FIFO is a target-scoped FIFO with a size of over 16,000 elements and both the Read and Write interfaces are set to "Never Arbitrate."

I was wondering if anyone could help me identify what I'm doing wrong in the example code I've attached.

Cheers!

[a_clucker]

Hi etgohomeok,

I've looked over your code, and everything looks like it should be running fine. As a debugging technique, can you check to see how often / if the bottom loop is timing out? I doubt the read function would time out that often, but it is possible. You could just make another shift register with an int to record how often this is timing out. Theoretically, (timeouts) + (normal reads) ~= (values written). 

Thanks,

Andrew

[Dragis]

The code in the top loop is attempting to write 4 values into the same FIFO each clock cycle. Since you are using Never Arbitrate, the system is going to assume the code will never do this and simply or the values coming from all the writes together so the diagram ends up pushing garbage into the FIFOs most likely. 

This is one of the areas where the simulation will succeed because it will obey the data flow rules of LabVIEW when executing the Writes to the FIFO. There is currently nothing in place to detect this situation and report an error.

To fix this, you either need to either create 4 FIFOs to push into each cycle, pack the data into a cluster or array and pass the whole value into the FIFO, or use some other similar scheme.

[etgohomeok]

The 160MHz loop was timing out very frequently (over 50% of the time).

I've moved forward with a workaround that has the 40MHz loop write to four separate FIFOs and the 160MHz loop cycles between the four (similar to Dragis' suggestion) and it seems to work OK.