I need to capture some periodic ADC data interfaced with SOM FPGA, and process the captured ADC data in RT, but I am having trouble with getting/display the data from the beginning of the periodic data stream in RT. To simplify things, here is what I did:
In FPGA, a periodic trigger with a specific pulse width is generated in FPGA ; FPGA starts to capture the periodic data, and writes the data to target-to-host DMA FIFO in SCTL loop using external 10MHz clock from ADC. The writes to DMA FIFO is triggered by the periodic trigger pulse, and the write length is controlled by the pulse width. In RT, DMA FIFO.read reads out the data. However, the data read out is not always from the beginning of the trigger point, and sometime is moving. I guess this involves some sync on the timing of writing to DMA FIFO in FPGA and reading out from RT. But I have hard time to control/sync the data. Does anybody have experience in sync write/read of DMA FIFO between FPGA and RT. Thanks in advance!
By syncing the write/read of your DMA FIFO do you mean ensuring that you're starting the FIFO portion of your RT VI appropriately when data is available on the FIFO? If that's the case, you could consider using interrupts to tell the RT VI when the FPGA VI has begun writing the FIFO and it's appropriate to begin reading the FIFO.
In general, reading to and writing from a FIFO will be asynchronous. However, you may run into bad behavior with missing data if you try to write to a full FIFO or start reading old data.
If you're still experiencing these issues, the first thing I would check is whether you're timing out on a FIFO write or read. I also recommend verifying that you have all the expected data before the FIFO write. This will help confirm that the problem is indeed the FIFO operations and not something on the acquisition portion of the FPGA VI.
Additionally, it's possible that the data will seem to move off the expected trigger point if the RT VI is reading old data. You may want to verify that all the values are being read from the previous set of data before triggering and placing more on the FIFO. It might also be helpful to flush the FIFO if there are old unwanted values on the FIFO when you try to trigger a new acquisition.
Thanks for your reply! I didn't get a chance to read until today.
Since the FPGA of my application generates periodic triggers every 2.5ms or less (non-stop), the RT is not able to catch up reading all the data (10MHz sampling rate) in FIFO even if the FPGA DMA FIFO size is max-ed. Therefore, FIFO-write is always timing-out. But that's OK, this application allows some data loss between triggers. However, the RT has to catch up the beginning of the data from a trigger .
The RT is able to, most of the time, catch the data from the beginning. However, once a while, it will miss the beginning, and I guess the RT VI is reading old data that the data moves off the expected trigger point (like you said). But the RT reading from the beginning always recovers during the next trigger.
I am not able to flush the FPGA DMA FIFO. It is because the write to FIFO logic is in 10MHz SCTL loop. FIFO flush supports only peer-to-peer FIFO, which sbRIO 9651 does support. In addition, not sure if RT would be able to catch up the 2.5 ms frequent interrupts from FPGA.
FIFO flush supports only peer-to-peer FIFO, which sbRIO 9651 does support.
I haven't tried it, but I think flush works for target-to-host FIFO's. LV FPGA help says that it does.
Since I have to use SCTL for DMA FIFO write in FPGA, the FLUSH function seems not supported inside SCTL.
I do have my FIFO read on RT all the time and the data coming from FPGA has a specific length but I can make it shorter (but not shorter than 512). However, the data read from RT is not always the first data after the trigger.
The RT and FPGA FIFOs do not need to be synchronized. Recommendation:
1. Pulse comes in, start sending data to RT and start counter
2. When pulse ends, send value of counter to the RT. This could be done with another FIFO or as part of the data in its own FIFO. If the data 32 bits, then you can use the remaining 32 bits of a 64 bit FIFO for the size. When the value of the high 32 bits are zero you ignore it. When the high 32 bits have a value then you know (on the RT side) that the elements since the last non-zero high 32 bit values are part of a pulse.
I am using a similar approach to yours. Instead of a counter. I directly put the trigger signal into DMA FIFO and use that for the RT side. Most of time, I get data out right at the first one. However from time to time, I will get data out at the middle of the stream after the trigger but it recovers from the next trigger. That was my initial question...although I am able to (and the application is allowed to) exclude that miss-aligned data stream using case statement. I was hoping to get the data from each trigger.
By middle of the stream after the trigger do you mean you are missing values? Do you know where data is getting lost? Is the FIFO timing out?
I recommend having the FPGA generate known data to test this out. A counter takes up little FPGA fabric and is easy to error check.