LabVIEW FPGA – The Good, the Bad, and the Ugly

LabVIEW FPGA sample code

LabVIEW FPGA- The Good, the Bad, and the Ugly

F-P-G-A: to many software developers and integrators this is a four-letter word for a scary, dark place where monsters lurk

Introduction to LabVIEW FPGA

FPGA: to many developers and integrators this is a four-letter word for a scary, dark place where monsters lurk. I have been given an opportunity to learn FPGA, but not in the way that most FPGA developers use it. I am from the school of LabVIEW. This allowed me to add a whole new embedded tool (and sometimes a huge one) to my toolbox with very little brainpower investment. This has drastically increased the range of applications I can tackle. LabVIEW FPGA is a great tool, but not without its drawbacks, so let’s have a look at what some of the benefits, drawbacks, and just plain black holes there are.

The Good

Reduced project completion time

While LabVIEW has a barrier to entry, like any other language, the bottom line is that one of the things that it excels at is being able to generate useful code to acquire and analyze real-world data quickly. This applies to LabVIEW FPGA too as it is just an extension of the base G language (LabVIEW graphical programming language). National Instruments (NI) does a wonderful job of abstracting hardware description language (HDL) from the G developer so one can write G code very similar to regular LabVIEW and have a working FPGA application in minutes.

Of course, a larger, more complex application still requires experience and good techniques to make a LABVIEW FPGA application meet size and timing requirements. This is still significantly less than most FPGA developers invest in learning HDL.

Simple simulation

LABVIEW FPGA has several simulation tools that allow you to quickly simulate the operation of the FPGA design. One very powerful tool is the ability to directly copy and paste LabVIEW FPGA code into a Windows context and execute the code with little or no changes. This will not preserve timing, but it is incredibly useful when you need to test the behavior of a state machine or other timing-independent code. There are also some useful techniques that can allow you to simulate timing if it is critical.

You get to leverage the existing NI ecosystem

This is another great benefit of LabVIEW FPGA. NI has a large (internal and external) ecosystem of code behind LabVIEW and that is extended to LabVIEW FPGA. Many libraries that are available for use in Windows are also available in LabVIEW FPGA.

There is also a large offering of common communication protocols that are available on the LabVIEW Tools Network, such as SPI, I2C, and RS-232 as well as some encryption algorithms. These allow a developer to implement one of these in a matter of minutes and are right at your fingertips via VI Package Manager.

For every I/O module they sell, NI also provides lots of example code that can be easily replicated and modified to your needs.

Large algorithms are much easier to understand in dataflow, and far quicker to implement in LV FPGA (an FFT is an example of this)

As an extension of the ecosystem discussion, some code is just much easier to understand in LabVIEW FPGA. Here is an example of a loop that implements an FFT.

labview-fpga-fft-example

Most developers, G or not, could look at this code and tell what it is doing. It does require opening a configuration dialog, but that is also very easy to follow.

labview-fpga-fft-configuration-dialog-example

The Bad

Notable overhead on all operations

Because LabVIEW FPGA is an abstraction of HDL, it adds a fair amount of overhead to the resource usage of any FPGA design. As FPGAs get larger, this becomes less of an issue, but it can still have a very real impact on time to completion. LabVIEW FPGA still uses the same Xilinx compilation tools (ISE and Vivado) that any other Xilinx FPGA developer uses, an equivalent design done in LabVIEW FPGA will take longer to compile every time. Once or twice an extra 10-20 minutes does not present a problem, but a complex design that must be compiled 20-30+ times at the additional cost of 30 minutes per compile can add up to days of compiler time. While most of this time can usually be offset by doing other work during the compile time, if you (or a whole team) are waiting for a compile to finish to begin testing the fix on hardware, it can be a significant cost. Most of the time, it is not worth worrying too much about, but it is something that everyone involved should be aware of.

The other problem that this causes is that it allows you to get less done in a LabVIEW FPGA design vs. an equivalent HDL design when trying to pack more in to a design.

An example of this overhead would be in the implementation of a state machine, which is very common in LabVIEW code. A state machine in HDL can be recognized by the compiler and synthesized to a very specific set of flip-flops. In LabVIEW, a state machine is represented by a loop with a case structure that is evaluating an enum. The compiler is not going to recognize this as a state machine, but rather a collection of higher level objects that will use more resources in synthesis.

Dataflow might be challenging for those coming from a non-dataflow world

Of course, being a LabVIEW developer, I think in dataflow. That may not be so easy for those coming from the text-based world. If your code needs to be understood by a team of non-dataflow developers LabVIEW FPGA may (or may not) be harder for them to read than HDL.

You are a level removed from the Xilinx tools

Again, thinking of LabVIEW FPGA as an abstraction, NI does not provide nearly as much control of the FPGA design as when you are using the Xilinx tools directly. This means that many of the knobs that you might turn to constrain or optimize a design are just simply not available in LabVIEW FPGA. For 95% of LabVIEW FPGA developers this will not be a problem, but when you need those tools, it can be a significant hurdle. Notice that I used the word hurdle. In none of our designs was this a show-stopper, but in a couple of cases, we needed to engage NI applications engineers directly to help us solve layout issues.

Difficult to source control

All good programmers worth their salt use source control to protect and version their code. LabVIEW source files (VIs) are proprietary and binary and thus more difficult to source control. Viewpoint has created an add-on tool for LabVIEW that allows you to use SVN right in the LabVIEW IDE, but distributed version control (DVCS) tools like Git or Hg are very difficult to use with LabVIEW.

Some complex applications still require writing HDL

In some cases, you can’t get away without writing some amount of HDL. Viewpoint has completed some applications where the customer needed a custom physical connector or a specific LVDS driver on a FlexRIO Adapter Module (FAM), a unique Aurora configuration, or some combination of those. These specialized cases require the ability to write HDL for the FAM Component-Level IP (CLIP), which creates the interface between LabVIEW FPGA and the physical interface, or for the link layer protocol. It helps to have experienced developers in both LabVIEW FPGA and HDL.

The Ugly

Can only view within the LabVIEW tools

One major drawback to working with NI tools is that the file format is proprietary and can only be viewed and edited with LabVIEW, which has a non-negligible entry price in the thousands of dollars to start working with LabVIEW FPGA.

Next Steps

We’ve got over 700 LabVIEW FPGA projects under our belt. If you’d like to chat about your LabVIEW FPGA needs, you can reach out to chat here.

YES, HELP ME SOLVE MY LABVIEW FPGA PROBLEM »

If you want to know more about how we can help with test system development, see here.  If you want to see how we can help with your industrial embedded needs, see here. Also, here’s some additional resources to help you on your journey:

2018-10-09T10:30:00-05:00