LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Synchronization problem regarding FIFO buffers

Hello. I have a synchronization problem regarding FIFOs. I write my data with 10 MS/s, on 4 separate FIFO buffers of depth 32768 and width 64-bit. I save my data into a1.dat, a2.dat, a3.dat and a4.dat files. When I process these data in another labview VI, I realize that there is about 10-100 microsecond synchronization between each of these 4 FIFO buffers. How shall I overcome this problem? Thanks.

0 Kudos
Message 1 of 14
(3,361 Views)

Are we referring to DMA FIFOs? I am assuming you are transferring data from your FPGA target to a host and writing the buffer contents to file.

 

Are you writing to the FIFOs simulatenously in the same loop? It would be helpful for you to post a screenshot of your FPGA code showing your sampling and writing to FIFO. Unfortunately without seeing the code and having a better understanding of your program architecture, I don't have much to offer in the way of a solution. As soon as you can post screenshots of the code, I'll take a look and see if I can find where the problem is.

 

-Nick-

Nick C | Software Project Manager - LabVIEW Real-Time | National Instruments
0 Kudos
Message 2 of 14
(3,337 Views)

Yes, they are DMA FIFOs. Your assumption about transferring data from your FPGA target to a host and writing the buffer contents to file is correct. I am using PXI express 1082 with NI PXI-7952R FlexRIO FPGA Module.

 

FIFOs are in the same loop. 

Thank you for your immediate response.

Serdar

Download All
0 Kudos
Message 3 of 14
(3,330 Views)

Serdar,

 

The screenshots show the FIFOs on the host side of the project. I will need to see the FPGA code where you are writing elements to the FIFO to get an idea of why you are seeing un synchronized data

 

-Nick-

Nick C | Software Project Manager - LabVIEW Real-Time | National Instruments
0 Kudos
Message 4 of 14
(3,297 Views)

Hello Nick.
There is no code written for this project, there is a VI named Configure ADC and I am sending it in the attachment. I have taken this project few months ago, hence I am not sure whether this VI was written by the previous researcher or downloaded from NI library.
Thanks,

0 Kudos
Message 5 of 14
(3,284 Views)

What type of module are you sampling with? If the module does not sample simultaneously, this could be responsible for the delays. We cannot sample again until all 4 FIFOs have a sample written to them. What rate are you running the Timed Loop on the FPGA at? On the block diagram all I can see if a reference to a clock called "IO Module Clock 0"

 

Also, how are you able to determine that the samples are off? I don't see any benchmarking/timing code included here to indicate when the samples were taken

 

-Nick-

Nick C | Software Project Manager - LabVIEW Real-Time | National Instruments
0 Kudos
Message 6 of 14
(3,264 Views)
It is a IO Module for NI5751. The description is at the bottom. We have 40 MHz Onboard Clock and 200 MHz clock. Clocks are synchronized.  However effectively, we use 50 MHz for IO Module Clock 0. (I think it is "timed loop") Its properties are in the attachment.

We understand the unsynchronization with a different VI. In the figure an event occurs. Although all .dat files would aligned at the same time cursor, a4 lags a3 then a1 then a2. This VI works properly, I can show previous researcher's obtained data synchronously. This figure belongs to my new experiment.

Thank you for your concern.

Serdar

IO Module Description:

 

The NI 5751 is a 16 input, 14-bit, 50MSps NI FlexRIO adapter module. In addition to the 16 analog inputs, there are 8 digital inputs and 8 digital outputs.

Component Level IP Description:
This CLIP provides access to sixteen analog input channels, eight digital input lines, and eight digital output lines. This CLIP also contains a SPI interface to program the ADC registers.

In this CLIP, each sample clock cycle generates a sample from the analog input channels. Three clock sources are available and are selectable using the Sample Clock Select control. The default clock source is the 50 Mhz onboard oscillator. Other clock sources available are DStarA through IoModSyncClock and an external clock through the front panel SMB connector. Only external sample clock rates from 30 MHz to 50Mhz are supported with this CLIP. Each 14-bit sample is output to LabView as an I16. The 14-bit data is left justified and padded with 2 zeros in the LSBs. The data is clocked out of the CLIP on IoModClock0.

For more information on the CLIP I/O refer to the NI 5751 FlexRIO CLIP Node Wire Descriptions section of the User Guide.

Download All
0 Kudos
Message 7 of 14
(3,255 Views)

How are you determining the X axis "Time" values on that graph? There is no bemchmarking/timestamping info in the FPGA code that would indicate whether or not the samples were taken simulatneoulsy.

 

If you are taking a tick count/timestamp when you are reading the values out of the FIFOs, it is very possible they could execute with a small delay between when you read a sample, however, if you remove one sample from each FIFO, all those values should have been simultaneously sampled by the FPGA. 

 

If we are not on the same page, please let me know. I feel like you are under the impression that the samples are not being taken "simultaneously", but you have no benchmarking code implemented that could indicate this.

 

-Nick-

Nick C | Software Project Manager - LabVIEW Real-Time | National Instruments
0 Kudos
Message 8 of 14
(3,237 Views)

I am quite confused, what do you mean by removing one sample from each FIFO? Also there is no tick count/timestamp while I am writing to .dat files. (the only tick count is screenshot1.png that I sent before)
Thanks,

Serdar

0 Kudos
Message 9 of 14
(3,196 Views)

Serdar, 

 

A better solution to this problem is to build all the samples taken by the FPGA into an array, then put them in one FIFO. This ensures that each element (array) you pull from the FIFO on the host side were taken in the same loop execution on the FPGA. 

 

I was referring to the tick count as a benchmarking technique, still trying to figure out how you are determining what the delay in the samples is. 

 

Try using a single FIFO to pass the data back from the FPGA. I think you will find this will solve your problem, also it is less resource intensive than using a single FIFO for each channel.

 

-Nick-

Nick C | Software Project Manager - LabVIEW Real-Time | National Instruments
0 Kudos
Message 10 of 14
(3,179 Views)