LabVIEW
FPGA: interleaved dma fifo "shuffles" inputs
Solved!
I'm using a DMA FIFO to transfer acquired data from a FPGA (NI 5783 in a NI 7931R) to the RT host. I acquire 3 inputs and would like to stream the data. I have read in whitepapers that the best practice to do so is using a interleaving scheme.
However, when reading out the data on the RT host, I notice that data got shuffled on the way, e.g. data from DA input 3 is now input 1. The RT host reads out three elements of data per time, as suggested in the white paper, therefore I can exclude having made a mistake on the readout side. I suppose I made a mistake on the FPGA side, yet I cannot find it.
I attached the FPGA vi in question, perhaps you can have a look and notice anything stupid. Also, please find below screenshots of said vi. there you can see two loops.
The first loop acquires data and does sort of a "continuos average" in a FPGA gentle manner using bitshifts. Since this is a single cycle timed loop, I cannot feed multiple elements into an DMA FIFO. Therefore, I only feed an acquisition buffer.
The second loop then reads out the acquisition buffer and writes the data into the DMA. If the DMA is full, it is flushed before writing the next element (this is desired).
I doubt that the data is not shuffled.
What happens is that the moment you get a time out or flush the stream, you have no idea where you start again. So the stream is 1,2,3,1,2,3, and that seems to stay that way. But the moment you get a timeout or flush, there is no telling where you continue. So you might get 3,1,2,3,1,2, 3.
If you're careful, you should be able to get in sync again. First stop the pushing of data, then flush on RT, then start waiting for data, and then start.
Alternatively, and much safer AFAIC (but less scalable) you could build an U64 instead of an array. Then put the U64 on the buffer. This will guarantee the data integrity. EDIT: It will also obsolete the 2nd loop, I think.
Search LabVIEW like a graph!
@TomD3 wrote:
@wiebe@CARYA: thanks for your reply. I understand: flushing the DMA might take some time. During that time, the first Buffer-FIFO might overflow. Three elements at once will be written into the Buffer-FIFO, while another three elements will pop out into the nirvana. Therefore, they should not shuffle.
Also, readout is always three elements at once.
I think it's a bit different. It's not about the flush taking time. When you flush, there's no telling where the steam is cut off. Same for a time out, unless the number of elements is a multiple of 3, the point where the stream is broken is not an exact number of elements. The read and write are out of sync.
@TomD3 wrote:
I now tried another approach: i got rid of the Buffer-FIFO and the second loop. In the single-cycle-timed loop, I filled the FIFO using shift registers, one element per tick... Let's see where that goes.
That will probably do some good, as you eliminate a layer. It won't solve time out problems, unless you stop the pushing, flush on both sides, then start reading and then start pushing.
I'd still go for integer packing over multiple elements, but suit yourself. I've been burned by this kind of problem a few times... Simpler is better.
@TomD3 wrote:
I can see the ease and simplicity of going to U64. Just afraid that at some point I would like to cram more data into that DMA - as you say, it is not perfectly scalable....
On modern FPGAs, there are a few DMA channels. If you can make 3, that would make things a lot easier as well.
@deceased wrote:
I believe the DMA FIFO channels are 32 bits wide, unless this has changed on more recent targets.
Maybe internally. I've used 64 bit DMA FIFOs a long time ago.
@deceased wrote:
If you have 2 16 bit values, in terms of performance, its best to bit pack them into a single 32 bit number.
Yes, check out Join Numbers function. Join A and B, and C and 0, Join the results, to get one U64. Use Split Numbers to get them back...
@deceased wrote:
In this case, combining 3 16 bit values into a 64 bit number would make the FPGA actually split the number into (2x32bit) and trigger 2 writes (transparent to the user), so you wont gain much if anything.
The FIFO will simply pass 64 bit integers. It would make life a hole lot easier.
@deceased wrote:
On these modern FPGAs you will have 16 DMA channels anyway, you should need to interleave less.
That might be best. I'm not sure if compile times should be a concern. I'm not sure how much a DMA FIFO adds in terms of slices\gates. It might not be too bad...After all, the total amount of buffered data will be the same.
