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

Q: How has instrumentation and automated test changed in the last few 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 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 are already mature. 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 that drive this change include high-speed PCI buses, multi-core processor technology, and FPGA technology. 

Q: What benefits can multi-core processing provide to engineers creating test systems? 

Starkloff: Processor manufacturers have introduced multi-core processors that integrate multiple CPUs on a single chip, and this multi-core processor technology has 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 multi-threaded code, and hyperthreading also provides the possibility of more efficient use of CPU resources. The combination of the above two technologies will enable 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 parallelization of an application source code, 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 era 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 at the top of the multicore-ready software stack? 

Starkloff Answer: Engineers looking for faster test methods or better loop rates in control applications need to consider how they want to execute parallel applications and how to take advantage of the performance gains offered by multicore 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 includes the LabVIEW Real-Time Standard Module and multicore support that trickles down. LabVIEW 8.5 adds many features that enhance multithreading performance based on the 1998 release of LabVIEW 5.0. The 

biggest advantage of using LabVIEW for application development is that LabVIEW is an intuitive, graphical programming language. The dataflow nature of LabVIEW means that any time there is a branch or parallel sequence on the block diagram, the underlying LabVIEW compiler attempts to create a thread for executing code in parallel. The graphical language of LabVIEW is designed with some degree of parallelism in mind. LabVIEW 8.5 extends the automatic multithreading capabilities available on desktop systems to enable real-time systems to be developed on multicore real-time hardware with SMP support. 

Question: What impact will the combination of multicore parallel processing and buses like PCI Express have on test systems? 

Starkloff Answer: Engineers often have special test requirements such as high-performance measurement tasks, signal processing and customized signal analysis. PCI Express makes it possible. This solution built on PCI Express bus technology replaces fixed, vendor-defined solutions. The bandwidth and underlying specifications of the PC bus have rapidly evolved 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 back to the main PC processor for real-time processing and test analysis. Combined with parallel programming and multicore processors, engineers can also increase system performance and the number of data processing channels in their test systems. If PCI Express, LabVIEW 8.5 and multicore processors are combined, not only can the test throughput be increased, but the use of virtual instruments can be expanded to new application areas. For example, high-speed digital test, intermediate frequency data streaming, multi-channel data acquisition, and full-speed image acquisition. With these readily available computer technologies, engineers can choose from a variety of solutions, including large and expensive vendor-defined solutions. For example, Eaton, an industrial product manufacturer, was able to quadruple 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? 

Answer: 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 number of instrument and controller configurations. USB is increasingly favored for portable, fast-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, ease of use, and tradeoffs associated with each bus before deciding which bus is ideal for an application. National Instruments provides detailed information on its website, ni.com, that can help engineers learn about these tradeoffs. Engineers also need to consider a hybrid bus approach that includes a wide range of instrument control bus options so that engineers can maximize system performance and flexibility and take advantage of the system. A computer-based instrumentation platform, such as PXI, is recommended for use in a hybrid test system. Overall system performance can be maximized by eliminating the potential for bus bottlenecks on low-bandwidth, high-latency buses such as Ethernet. 

Question: How do you think instrumentation and automated test 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 the device, perform inline processing 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 well suited for multicore applications and is also ideal for leveraging the advantages of FPGA technology. 

When FPGAs are used in standalone instruments, engineers cannot reprogram these instruments, which is a critical requirement for automated test. Of course, there are many advantages to running different processes on a main dual-core processor. For example, FPGAs are very suitable for in-line 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 programming details of FPGAs with system-level tools can overcome this limitation. For example, LabVIEW FPGA can directly implement a portable FPGA and synthesize the necessary hardware 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 or FPGA to choose the best execution performance. 

Question: What does graphical system design mean for test? 

Starkloff: For years, National Instruments has been spreading virtual instrumentation, a concept that could revolutionize industry development. Engineers can use virtual instruments to create user-defined systems that meet specific needs. Graphical system design pushes virtual instruments further, and it also brings 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 soon as possible.