DMA FIFO from FPGA to RT host gets full

[nathand]

Can you upload your code? Your explanation of what you're seeing will make more sense if we can see the code too.

[PatrickR]

The FPGA code would be useful.  Do you have any triggering logic and/or sample tracking logic  in your reading routines?   If all the FPGA code does is read from the I/O lines, its going to fill up the FIFO buffer pretty quickly.   And the timing will be pretty poor (which you might not care about)

I would also recommend the FPGA code be in some type of loop - preferably a single cycle timed loop.   Then you give a signal through a front panel control (which can be read/written to from the host side) to tell it to begin reading.   You won't have to open and close up the FPGA reference, which I have found to be slow especially if there is an I/O module involved.

[CoastalLabVIEWER]

I'll get the software uploaded tomorrow.  I'm not sure why it has taken me this long to realize this, but somehow on the Host VI reading from the FIFO some of my data is swapping places.  That is I'm packing a U64 number that is my timestamp along with a U64 that is position data into the FIFO on the FPGA, then unpacking with Decimate 1D Array on the Host side.  I see now that where I expect all of my timestamps to be in one array and all positions in another has some of the data swapping places.  It doesn't appear to be random, rather it is chunks.  Of a 10,000 sample run if 71 timestamps are holding position data, 71 positions are holding time stamp data.  At least, this appears to be the case that it's equal numbers in each array for the few points I've captured.

Again, I'll get the code updated tomorrow.  I don't have any sophisticated triggering.  When I open the reference on the host side the FPGA begins.  I did add code to the FPGA side to check how much space is available in the FIFO, if it is full then I skip adding anymore to it.  This hasn't made a difference in the behavior I'm seeing.

[CoastalLabVIEWER]

The drive home from work gave me some time to think about this and I now realize what is happening.

On my host side read I'm taking all the data the FIFO has rather than a fixed number, and to be sure there is no guarantee that the last item I get out is either my time stamp or my position data.  I decimate the array each iteration of a while loop while I build up my Host VI samples and because of the odd number of samples they'll get put into the wrong shift registers.

So, I'm thinking about either setting up a Host -> Target communication to only read when I say so to give me time to clear the buffers and only read out even numbers of FIFO items or I'm contemplating switching from 2 U64s over to a single U64 and use half the bits for position (my SSI probe only actually needs 24) and the other 32 bits for the time stamp.  This way I'll always get them out the Host side together and then I'll just spilt the U64 into the U32s once there.

As usual, once I resort to putting the question on the forum it's only a matter of time before I figure out the problem anyway.  Thanks for taking the time to read and offer your help!

[PatrickR]

Yeah, unless theres a reason to be super efficient and pack your data, I would just go 1 record -> 1 sample.   Also, when I pack data s I've always used interleave as opposed to decimate

Would having some sort of trigger, and doing this in a timed loop eliminate the need for a timestamp?   Or is the timing non-uniform ?

[CoastalLabVIEWER]

---

@PatrickR wrote:

Would having some sort of trigger, and doing this in a timed loop eliminate the need for a timestamp?   Or is the timing non-uniform ?

---

For us this was a matter of "where do we solve this problem".  At the moment, the data lines coming back from the probe can be so noisy that it causes bits to flip and will give us readings that aren't physically possible with the probe.  If we just let this reading go through at the fixed dt of the timed loop then we'd have to post process to filter out these bad readings.  Instead, we detect bad readings in the FPGA and we read the probe again until we get known good data.  The probe has a fixed cycle time so it isn't like we can read multiple times within 1 timed loop iteration and keep the known dt.  Instead, we read until we get a good reading and then time stamp that good reading against a free running counter.  Our sample rate (1khz) is slow enough compared to the free running microsecond that we don't mind a little bit of jitter in the single/tens of microsecond range.

We intend to get our noise issues solved but it's likely we may still need post processing and will be kicking myself thinking how I would have avoided losing the time on this particular self inflicted wound.  Regardless,  it's certainly helped my learning.