We use LabVIEW DMA FIFOs for typical FPGA applications that acquire data to be sent to an RT target(Host). There are a lot of ways to use FIFOs for transporting data from the FPGA to the RT target. We will outline several of these options and present a generalized data transfer mechanism for synchronized DAQ on multiple chassis.

Let's start by outlining our requirements and then build then up a solution which considers several different options for transferring data from the FPGA to the host.

Outlining the Requirements

Requirements:

1. The system has a high channel count.


2. There are a variety of different data types in the channels being acquired.


3. Channels may be acquired from different loops that execute at different loop rates.


4. Channel data acquisition times must be synchronized across multiple chasses.

Schemes for Transferring Data

The DMA FIFO is the fundamental block for lossless transfer of data between an FPGA application and the host.

Using this building block, let’s discuss the progression of a generalized DAQ architecture starting with a single chassis implementation.

Single Channel Data Transfer

The simplest scheme for transferring channel data is when you’re acquiring data for a single channel.

In this scenario, you can write the data into the FIFO as it’s being acquired. As the host is acquiring data from the FPGA, it is guaranteed to be a sequential, ordered series of samples for that channel.

Multi-Channel Data Transfer

In most instances, we will want to acquire more than (1) channel of data, so the natural next step for this is to interleave the data that is being written to the FIFO. For a fixed channel list, this interleaved ordering can be pre-defined. That data can then be decimated using that ordering when it is read from the host.

Example FIFO ordering: 

[channel 1 – sample 1, channel 2-sample 1, ch3-s1, … , chN-s1],

[channel 1 – sample 2, channel 2-sample 2, ch3-s2, … , chN-s2],

… ,

[channel 1-sample N, channel 2-sample N, ch3-sN, …, chN-sN]

Differing Acquisition Rates

In the most generalized approach, it is not guaranteed that every channel will be acquired at the same rate. If you only have a few different acquisition rates, you could potentially use a separate FPGA-to-Host FIFO for each acquisition loop/rate.

If you can only use a single FIFO for transferring data or have more DAQ loop rates than FIFO channels, we would like to be able to use a single FIFO for acquiring data from all of the different sources/loops in our application.

In the example shown below, we have a 1Khz control loop that may contain some output channels or internal calculated channels that we would like to acquire as well as a more standard DAQ loop running at 5Khz.

Including Additional Information

We can no longer assume what the ordering of the channels written to the FIFO will be, so we need to include additional information along with each channel’s sample value to identify it on the Host. By setting the FIFO data type to be u64, we can pack additional information to be included with each channel.

In the example below, we can include a channel ID in addition to the channel data’s value so the Host can parse which value is associated with which channel ID.

What About Timing?

With the single channel acquisition or interleaved approach, we can infer the time delta between each sample. When capturing channels throughout a general FPGA application, we should have a strategy for capturing timing information with the samples we’re acquiring. One way to achieve this is to include a base clock value that is packed along with the channel ID and channel value:

Another option, if your application can tolerate less resolution per channel, would be to periodically send a special timestamp channel value at a regular interval. This unique timing channel can be used on the host side for determining when to aggregate a set of channel data. It can attach a single timestamp to all of the channel values received since the last timestamp value was received through the FIFO.

Considering Scale

The final step for this architecture is to consider how it scales with multiple FPGA chassis. In the previous section, we were able to generate a synchronized base clock value across all chassis. By using this synchronized base clock as the time stamp included with the channel values, we can achieve synchronized data acquisition across multiple chassis.

In the diagram below, you can see what this architecture might look like on the RT/Host side. Multiple parallel loops will be used for acquiring data from the FIFOs, Scaling the data, and then aggregating the data to be disseminated throughout the RT-Host application.

The last part of the architecture considers how to share data between chassis without involving the RT.

Stay tuned for synchronous data sharing between FPGA chassis using NI 9853 CAN module!

Learn more about DMC's FPGA programming expertise.

The post NI LabVIEW Part 2: Synchronized Data Acquisition across Distributed FPGA Chassis appeared first on DMC, Inc..

As a quick overview of what we’ll discuss, we’ll be working towards an architecture shown below. Part 1 of this series will review how to achieve timing synchronization between the FPGA chassis using National Instruments 9469 time sync modules. Part 2 will look at how to integrate synchronized data acquisition with an RT host application. Part 3 will review how to achieve data sharing between FPGA chassis using NI 9853 CAN modules.

Unfortunately, National Instruments hasn’t released the 60-slot mega chassis yet, so we’ll strive to achieve similar function and capabilities using multiple chassis with timing synchronization and data sharing. 

Part 1 of 3: Distributed FPGA Chassis Time Synchronization Using NI 9469 C Series Module

The first step to building up this architecture is to synchronize the clocks between the different FPGA chassis. We’ll achieve this using the NI 9469 time sync module that was designed specifically for synchronization requirements like this. 

The NI 9469 synchronization module is essentially a high-speed digital I/O module that encapsulates the underlying digital signals to provide a simple API for synchronization functionality.

In general, you configure the 9469 module to operate as a node in one of several “Single Master, Multiple Slave” topologies. Every chassis that you use will have one of these 9469 modules. A few of these different topologies are shown here:

The master chassis in this configuration can send a trigger (digital pulse) to one or more slaves, which upon receiving the triggers can perform some action(s) synchronously.

The API for the 9469 module includes two invoke nodes that are used in your FPGA code.

For Sending Triggers from a Master:

An example of this is shown below. Here, the base clock is divided into multiple different clock rates that are used throughout the FPGA application. The event divider VI counts the number of iterations it is called and outputs true on an interval that is wired into its input. Here, a divider of 1 yields the same frequency, 100 KHz. A divider of 20 yields 5Khz, etc. If we have multiple loops that will run at a particular frequency, then we can set multiple occurrences as in the 5Khz clock in this example. 

In addition to driving different loop rates, we will also be incrementing a base clock register. This base clock register can then be used for time stamping channel values, which will be described in Part 2: Synchronized Data Acquisition Across Distributed FPGA Chassis.

Since each chassis has its own copy of the base clock register, they are all incrementing off the same triggers from the master chassis. The base clock register values will always be the same across all chassis.

On initialization of the FPGA chassis, it is helpful to sync up the base clock registers via a procedure on RT. In general, a routine from the host application that follows the following steps will sync up the base clock registers on startup:

1. Disable all triggers
2. Reset base clock register to 0 on all chassis
3. Enable “Wait on Trigger” loops on all slave chassis
4. Enable “Send Triggers” loop on master chassis

We’ve now completed reviewing the core components of timing synchronization between chassis. In addition to what we’ve reviewed here, you can augment these components with additional fault handling:

1. If a chassis is missing trigger pulses, we need to make sure this is detected and that loops will continue to execute in absence of triggers being received from the master. You would need to switch to using the local clock in this scenario.
2. Use an additional trigger line for verifying the base clock trigger line. For example, if you send a trigger on the second trigger line once for every 1,000 triggers on your base clock trigger line, then you can count and ensure you’re always receiving 1,000 triggers between triggers you receive on that second trigger line.

That wraps it up for Part 1, stay tuned for Part 2: Synchronized Data Acquisition Across Distributed FPGA Chassis!

Learn more about DMC's FPGA programming expertise.

The post NI LabVIEW Part 1: Building Distributed and Synchronized FPGA Applications with Multiple C Series Chassis appeared first on DMC, Inc..

After several years of being a part of a great user group, Chicago brought home the hardware for the best user group of the year at NIWeek 2015 for the second consecutive year! 

Of course, you can’t have a Chicagoland User Group meeting at DMC without some sunshine, cold beers, and food on our rooftop! It was a great opportunity to socialize and get to know the diverse group of LabVIEW users from all around Chicago.

Learn more about DMC's LabVIEW Programming services.

The post Chicagoland LabVIEW User Group Meeting at DMC appeared first on DMC, Inc..

Some of my favorite parts of the technical sessions involved picking up the latest tips, tricks, and best practices. Learning the "why" behind design choices depending on the situation was useful to hear from other Alliance Members outside of DMC. From an in-depth discussion of designing applications with the Queued Message Handler architecture to the new capabilities of user events for 2013, there have been many additions to my tool box for solving problems using LabVIEW. The opportunity to interact with the NI developers that created many of the tools and APIs that are available was interesting as well.

One of NI's Technologies that was particularly interesting for standardizing test applications was TestStand. During a hands on session I used TestStand with a PXI controller, and I was able to get a good feel for its capabilities. Applications requiring test sequencing and scheduling, customized report generation, and data logging could potentially take advantage of this software and speed up development time. We'll definitely be on the lookout for future projects that could take advantage of this tool!

Overall, NI Week was a success, and I can't wait to try out what I've learned on my next LabVIEW project!

Check out other NI Week 2013 blog posts:

DMC at NI Week 2013

New FPGA Tools from NI and Xilinx at NI Week 2013

The post NI Week 2013 Recap appeared first on DMC, Inc..