How LabVIEW, Multicore Technology, and FPGA Technology Change Automated Test

Editor's Note: Eric Starkloff, director of product marketing for modular instruments and instrument control at National Instruments, joins us to discuss some of the changes affecting instrumentation and automated test, and how NI 's LabVIEW , multicore processor technology, and field-programmable gate array ( FPGA ) technology are driving the next generation of test technology.

Question: What changes have taken place in the field of instrumentation technology and automated testing in recent years?

Starkloff: We are now in a software-defined world. The devices we use every day, such as smartphones, set-top boxes, and even cars, are all based on the development of embedded software systems. For test engineers, testing these complex devices with reduced development time and budget has brought them challenges. Now, test managers and engineers are using modular instrumentation and software-defined architectures to meet these challenges and trends.

The concept of user-defined instruments or test systems is not new. In fact, user-defined instruments have been around for more than 20 years in the form of virtual instruments. The technologies that are driving these trends have matured. It is these technologies that can bring this new software-defined model to the top. Referring to Web 2.0, the difference between software-defined instrumentation and previous instrumentation can be called instrumentation 2.0. The key technologies driving this change include high-speed PCI buses, multi-core processor technology, and FPGA technology.

Question: What benefits can multicore processing provide to engineers creating test systems?

Starkloff replied: Processor manufacturers have proposed multi-core processors that integrate multiple CPUs on a single chip. This multi-core processor technology has now become a key technology for improving the execution performance of PC-based applications. Hyperthreading has also been proposed as one of the supports for improving multithreaded code, and hyperthreading also provides the possibility of more efficient use of CPU resources. The combination of the above two technologies will make it possible for engineers to develop high-density processing and high-throughput applications, and the performance of these two applications will be improved when they are executed in a parallel manner.

Since the execution performance of multi-core processing is directly dependent on the parallelism in which an application's source code is written, software development is a challenge for engineers who want to develop for multi-core processors. Dual-core and multi-core processors have brought a great impact on the software development world, and this impact has begun more than ten years ago when object-oriented programming was introduced. For software developers, this impact is like what Herb Sutter (a well-known C++ expert) wrote, "The free lunch is over!". Traditional sequential programming methods are no longer applicable, so software developers need new programming models, such as LabVIEW's graphical parallel programming, to fully utilize the potential performance of parallel hardware systems.

Question: What puts LabVIEW on the upper level of multicore-ready software?

Starkloff answered: Engineers looking for faster test methods or better cycle frequencies in control applications need to consider how they will execute parallel applications and how to take advantage of the performance gains offered by multi-core processors. With LabVIEW, engineers have an ideal software environment for writing parallel programs because of its dataflow-based programming language and the software stack that supports multi-core support with LabVIEW Real-Time Standard Modules and downward penetration. LabVIEW 8.5 adds many features that enhance multi-threaded performance based on LabVIEW 5.0, which was released in 1998.

The biggest advantage of using LabVIEW for application development is that LabVIEW is an intuitive, graphical programming language. The data flow nature of LabVIEW means that whenever there is a branch or parallel sequence on the block diagram, the underlying LabVIEW compiler attempts to create a thread for parallel execution of code. The graphical language of LabVIEW itself considers a certain degree of parallelization. LabVIEW8.5 expands the automatic multithreading capabilities that can be applied in desktop systems, so that real-time systems can be developed on multi-core real-time hardware with SMP support.

Question: How does combining multicore parallel processing with buses like PCI Express affect test systems?

Starkloff: Engineers often have special test needs such as high-performance measurement tasks, signal processing and customized signal analysis. PCI Express makes it possible. This solution based on PCI Express bus technology replaces fixed, vendor-defined solutions. The bandwidth and underlying specifications of the PC bus have evolved rapidly since 15 years ago. From ISA to PCI and now PCI Express, a fast, dedicated channel is established between the instrument and the processor. This enables engineers to reload their raw test data into the main PC processor for real-time processing and test analysis. Combined with parallel programming and multi-core processors, engineers can also increase system performance and the number of data processing channels in their test systems. If PCI Express, LabVIEW8.5 and multi-core processors are combined, not only can the test throughput be increased, but the application of virtual instruments can be extended to new application areas. For example, high-speed digital test, intermediate frequency data streaming, multi-channel data acquisition, and full-speed image acquisition. Using these off-the-shelf computer technologies, engineers can choose between large and expensive vendor-defined and other solutions. For example, Eaton, an industrial product manufacturer, successfully quadrupled the number of channels in its test system by migrating its LabVIEW -based system to a quad-core system.

Question: What is the future of instrument control buses such as GPIB, Ethernet, and USB?

Starkloff Answers: GPIB , Ethernet, and USB are all options for computer-based instrument control. GPIB remains the most commonly used bus for instrument control, primarily because of its proven performance, good connectivity, and a large base of instrument and controller configurations. USB is increasingly favored for portable, quick-to-setup benchtop applications, while Ethernet is favored for highly distributed instrumentation systems that do not require accurate system timing and synchronization.

Each instrument control bus has its own advantages depending on your application type and the features available on your instrument. It is important to fully understand the technology, usability, and tradeoffs of each bus before deciding which bus is ideal for an application. National Instruments provides detailed information on its website, ni.com, to help engineers understand these tradeoffs. Engineers also need to consider a hybrid bus approach that includes a variety of instrument control bus options so that engineers can maximize system performance and flexibility and use the system. A computer-based instrument platform, such as PXI, is recommended for use in a hybrid test system. Overall system performance can be maximized by eliminating the bus bottlenecks that may occur with low-bandwidth, high-latency buses such as Ethernet.

Question: How do you think the use of instrumentation and automated testing will change in the next few years?

Starkloff: One of the most promising technologies in this area is the FPGA. Using FPGAs, engineers can define the behavior of hardware systems on devices, performing inline or distributed processing. FPGAs also enable faster execution due to their inherent parallelism and reliable execution. The parallel nature of LabVIEW's graphical data flow is ideal for multicore applications, which is also ideal for the advantages of FPGA technology. When FPGAs are applied to standalone instruments, engineers cannot reprogram these instruments, which is a key requirement for automated test. Of course, there are many advantages to performing different processing on a main dual-core processor. For example, FPGAs are very suitable for inline analysis such as simple sampling on point-to-point I/O. However, performing complex modulation on a main processor will produce better results. This is because complex modulation processes require a lot of floating-point operations. In addition, although FPGAs have compilation capabilities and flexibility when performing automated test, these functions must be described using hardware description languages ​​such as Verilog or VHDL , which use low-level syntax to describe hardware behavior. Most test engineers are not very proficient in these tools.

Abstracting the FPGA programming details with system-level tools will overcome this shortcoming. For example, LabVIEW FPGA can be used to implement a portable FPGA and integrate the necessary hardware directly using a LabVIEW program. The ideal way to develop a distributed processing system is to use a dedicated development environment such as LabVIEW, which can quickly split the processing process between the main processor and the FPGA to select the best execution performance.

Question: What does graphical system design mean for testing?

Starkloff: For years, National Instruments has been promoting virtual instrumentation, a concept that has revolutionized industry. Engineers can use virtual instruments to create user-defined systems that meet specific needs. Graphical system design has pushed virtual instrumentation further, giving engineers the opportunity to develop their common I/O, signal processing, and analysis algorithms on a single platform using the LabVIEW graphical development environment and standard FPGA hardware. This approach can help engineers quickly develop common measurement functions in their systems and enable them to become instrument designers as quickly as possible.