The Software Architecture of the NI PXIe-5644R

1. An Open, LabVIEW, Software-Designed Instrument
2. Key Tenets of a Software-Designed Instrument
3. Specifics of the NI PXIe-5644R Vector Signal Transceiver
4. Conclusion

An Open, LabVIEW, Software-Designed Instrument

     Test and measurement vendors have been building hardware for decades. They have analyzed customer requirements, prioritized the common ones, and made business decisions on the features in which to invest. Before PC technology, vendors completely defined hardware functionality. Without physically altering the instrument, there was no way to change its behavior, or add or remove features. The advent of common interface buses such as GPIB, and virtual instrumentation software, such as NI LabVIEW, has ushered in a revolution in test system functionality. By accessing the raw measurement data from their hardware, engineers and scientists could customize their measurements and automate their systems in ways not previously possible. As a result, PC software is arguably the primary driver in increasing test system performance over the last decade. Yet even with this software flexibility, the capabilities of the instrumentation hardware are still defined by vendors through the firmware running on the device, and the software APIs they create to interact with it. Occasionally vendors may add functionality through firmware updates, or present more options through API extensions, but the vendor completely controls these enhancements.

      Enter software-designed instrumentation. Software-designed instruments eliminate the barriers of vendor-defined instruments in that their host interface and firmware are completely open, able to be customized by the user for a given application. This extends the software concepts of virtual instrumentation beyond the PC application layer, through the host interface, over the bus, all the way to the pins of the instrument. When software-designed instruments are built with system design software tools such as LabVIEW and LabVIEW FPGA, software customization is not limited to a select few driver software or firmware developers, but rather open to any engineer or scientist familiar with dataflow programming. And these customizations need not be overly complex. Something as simple as adding a combinatorial trigger on two signals, not possible with vendor-defined instruments and fixed APIs, can mean the difference between capturing only relevant data and unnecessarily parsing through endless waveforms, or worse, missing an event altogether. Progressing beyond simple triggers, more advanced ones with time or frequency-domain masks and thresholds are potential customizations that provide better access to pertinent data. Interfacing with and controlling the device under test can reduce the need for additional hardware in a test system. Implementing measurements on the instrumentation hardware can vastly reduce test times, or enable real-time, continuous measurements so that the instrument is always measuring and nothing is missed because of a limited acquisition length. Waveforms for generation or comparison data can be synthesized on the hardware, reducing download times and providing better coverage. Entire test systems can be sequenced through customized instrumentation, with the software-designed instrument acting as a hardware-based execution engine. Or by completely customizing a software-designed instrument, a user can end up with something no longer resembling the instrument they started with. It is now specifically tailored for their application.

Key Tenets of a Software-Designed Instrument

     Although the concept of a software-designed instrument may be compelling, its true utility and the potential to realize benefits through customization depend heavily on its implementation. When done right, a software-designed instrument delivers all the value of vendor-defined instruments, while providing the potential for valuable user customization as well. The following sections list the key tenets of a software-designed instrument.

Open Source

Unlike a vendor-defined instrument which has compiled firmware and software, the code for a software-designed instrument is distributed as open source. This means that a user can directly access the software without contacting the vendor or going through other hurdles to realize any customizations.

Figure 1. A traditional instrument driver is effectively closed, merely wrapping the vendor-defined SCPI command set. A software-designed instrument is completely customizable from the top-level host interface, all the way to the pins of the instrument.

     Furthermore, there is a large difference in writing software for consumption by a limited number of developers who are intimately familiar with the code base, and writing software designed for open source distribution, where anyone may look at the code with the intent of understanding and contributing to or otherwise modifying it. When writing open source software, care must be taken to provide easily-understandable architectures, limit complexity, and supply extensive documentation.

Hardware Programmability Through Software

     Although an open host interface alone might at times prove valuable, to provide for significant user customization, software-designed instrumentation hardware must be programmable. This means that the hardware must be built using a field-programmable gate array (FPGA). FPGAs provide the hardware functionality of dedicated circuitry or silicon, can accommodate large amounts of digital logic, and are programmed (and reprogrammed) through software. The LabVIEW FPGA module provides the ability to program FPGAs at a higher level, eliminating the need for specialized hardware description languages (HDLs), which are the most common FPGA design tool, but require specialized knowledge.

Figure 2. The LabVIEW FPGA block diagram of a software designed instrument, though large, implements the functionality of over 200,000 lines of VHDL code.

     By customizing the software that defines the functionality of an FPGA, users can effectively alter the circuitry of their hardware, implementing arbitrary functionality. From Boolean logic to sophisticated digital signal processing (DSP), FPGAs provide the ability for a single piece of hardware to implement a wide variety of functionality.

Default Functionality

     For a software-designed instrument to provide value without requiring extensive programming by the user, it must be supplied with code that implements common, default functionality, and is precompiled and ready to run out-of the box. This functionality should be similar to what is commonly provided by vendor-defined instruments of the same type.

Typical Instrument Driver

Software-Designed Instrument Host Interface

Figure 3. VSA and VSG-like functionality from a software-designed instrument, is compared with a traditional VSA and VSG instrument driver.

LabVIEW host code is continuously compiled during development, but instrument firmware written in LabVIEW FPGA must undergo a more deliberate and time-consuming compilation before it can be distributed as part of the default functionality of a software-designed instrument.

Progression of Customizations

     A software-designed instrument should be architected to accommodate the more common types of user customization, and necessarily become less customizable the closer the functionality lies to fixed hardware not implemented in the FPGA. This demands an architecture that is more flexible in its higher layers where user customization is likely to occur. Though there is less opportunity for customization in the lower layers, this code should remain open for the unlikely event that some kind of tweak is necessary, and for maximum architectural transparency.

Top-Level FPGA VI

Low-Level FPGA VI

Figure 4. The top-level FPGA VI of a software-designed instrument has many opportunities for user customization, while at lower levels of the code (in subVIs), the software is more closely tied to what lies beyond the pins of the FPGA. Comments in the top-level FPGA VI indicate likely opportunities for customization.

Code Ownership

     Most virtual instrumentation systems today rely on some kind of API that is defined and maintained by a vendor. Although this API may add value in the form of stability on which a user may build their application, it is this stability or inflexibility that limits the potential to add or change instrument functionality. For instance, to add even a simple custom trigger to the FPGA of a software-designed instrument, the ability to select whether to employ that trigger in the application software must be presented by some kind of host interface. If the vendor “owns” the interface, how does the user add this control? Or in the case of removing unused instrument functionality to free FPGA resources for other logic, how would a static host interface respond to requests that require this functionality? Clearly the user must assume responsibility of the host interface to higher application-layer functionality–formerly provided by a static API. The default interface may be supplied by the vendor, but to take advantage of the FPGA on a software-designed instrument, at some point the user will need to modify that interface.

Figure 5.  The host interface of a software-designed instrument may be extended to control new functionality added to the instrumentation hardware, depicted here by an additional function that reads the averaged power spectrum from user code running on the FPGA.

The top-level FPGA design is another example of code that the user will ultimately wish to control, as this is where most enhancements are likely to be implemented.

     User ownership of the entire codebase is not a foregone conclusion, however. Similar to the point above on the progression of customization, it is unlikely that a user will wish to modify the method by which integrated circuits external to the FPGA are programmed. This code should remain open, and there should be some method by which a user may assume ownership in the event that customization is necessary, but that should not be the default behavior.

     To accommodate these seemingly diametrically opposing requirements, some fraction of the code for a software-designed instrument should by default be owned, enhanced, and maintained by the user. Similarly, the remainder of the code should by default be owned and maintained by the vendor, with the potential for the user to assume ownership of even this code. To manage changes between the user and vendor code, there does need to be some kind of defined interface. Unlike purely vendor-defined instruments, this interface is not at the host API layer, but rather it exists within the host and FPGA code at an intermediate layer of each. Below this boundary layer exists the Instrument Design Libraries–the code provided by the vendor that implements common functionality found in instruments, and is an unlikely candidate for modification.

Figure 6. Instrument Design Libraries implement common instrumentation functionality and are provided by the vendor. Unique iconography, in addition to the location on disk, indicates the boundary between user code and the Instrument Design Libraries.

Again, users may assume ownership of the Instrument Design Libraries, modify them, replace them altogether, or eliminate them entirely depending on the desired changes in the behavior of the software-designed instrument. Short of this, however, there is a well-defined boundary between default user and vendor code ownership.

Component Disaggregation

     Having established the need for vendor-provided and maintained Instrument Design Libraries, software-designed instrument vendors must carefully consider how this code should be composed. It is important that the discrete functions provided by these libraries be completely disaggregated. That is, there should be no code dependencies between libraries. For instance, the library that is responsible for configuring the analog front-end of a software-designed instrument should not depend on the library responsible for record-based acquisition to DRAM, and vice versa. Should the user choose to eliminate the record-based acquisition code and replace it with a continuous data stream to the host, while still maintaining calibrated data, this modification will be greatly simplified without complex dependencies between the two functions or libraries.

Figure 7. Different components of a software-designed instrument are independent of one another to facilitate customization without the complexity of extensive dependencies. These components may be aggregated at a higher layer to deliver more advanced functionality, or present a familiar user interface.

Multiple Processing Architectures

     Another important consideration in the architecture of software-designed instruments is to choose the right processing architecture for a given algorithm. CPUs excel at implementing algorithms with complex conditional branches, floating point computation, and manipulation of large vectors with significant interdependencies. FPGAs are well suited for algorithms requiring truly simultaneous, parallel processing, fixed-point computation, low-latency decision making, and extremely high-throughput data movement. The code for a software-designed instrument should be distributed accordingly. For instance, highly accurate calibration computations are better suited for host implementation with floating point numbers, while complex DSP operations of a bounded dynamic range can be implemented in real time with a fixed-point numerical representation on an FPGA.

Table 1. Algorithm Suitability for Host CPUs and Instrument FPGAs

     There is also motivation for hosting the majority of the instrument state solely on the FPGA. Although vendor-defined instrument drivers commonly implement host-based state caching to improve hardware reconfiguration performance, this can often be done on the FPGA, with little penalty for the host statelessly redownloading redundant settings, given high-speed data buses such as PXI Express. Furthermore, as more and more functionality and measurements move to the FPGA where decisions can be made quickly, any state remaining on the host may require the FPGA to halt progress to reconcile that state with the host, effectively limiting performance.

Architectural Similarity With Other Devices

     Lastly, to facilitate as much code reuse as possible, instruments of similar types should employ similar architectures. This gives vendors the ability to use code that implements default capabilities between devices, and users to use their investment in learning a given architecture across devices of the same type, as well as easily incorporate and reuse any application-specific code.

Specifics of the NI PXIe-5644R Vector Signal Transceiver

     The NI PXIe-5644R Vector Signal Transceiver (VST) is the world’s first software-designed instrument, combining a vector signal analyzer, a vector signal generator, and digital I/O. The software for this VST obeys all of the key tenets described above. This section provides more details specific to the software of the NI PXIe-5644R.

Instrument Design Libraries

     National Instruments provides a multitude of Instrument Design Libraries for the NI PXIe-5644R. As described above, these Instrument Design Libraries exist at the interface between user and vendor code on both the host and FPGA, and implement functionality commonly found in instruments. Table 2 presents a list of top-level Instrument Design Libraries and their functionality.

Table 2. Top-level Instrument Design Libraries for the NI PXIe-5644R.

These Instrument Design Libraries are installed with the software listed at ni.com/vst/getting-started/, and subsequently exist on disk in c:\Program Files\National Instruments\LabVIEW 2012\instr.lb\. Visually, they can be distinguished from other VIs in that they have a thicker, color-matched border.

Figure 8. Instrument Design Libraries feature unique iconography to distinguish them from other VIs, with thicker, color-matched borders.

Furthermore, by default they are locked, presenting a dialog box to unlock the VI before users may modify the contents. Provided below are details on taking ownership of these Instrument Design Libraries, which should happen before any modifications occur.

     To exchange data between the host and FPGA of a given Instrument Design Library, there are numerous possible mechanisms. The NI-RIO driver, used by all National Instruments products that use the LabVIEW RIO architecture and LabVIEW FPGA, provides both single-point, memory-mapped, register-based host to FPGA and FPGA to host communication, as well as multipoint, continuous DMA FIFOs from host to FPGA, and FPGA to host. These are both powerful mechanisms for data exchange, requiring little-to-no knowledge of the underlying bus architecture to effectively communicate between host and FPGA.

     A common requirement for Instrument Design Libraries is that the host code may need to download a large number of settings to the device, for instance to program the registers of chips connected to the FPGA, or to update groups of settings such as filter taps on the FPGA. Because several Instrument Design Libraries require this policy, and there are a limited number of DMA channels on the device, it may be necessary for these libraries share a common FIFO, with additional logic for arbitration on both the host and FPGA side of the FIFO. Additionally, this type of communication is typically unidirectional for the large data set, but it may also require some kind of single-point confirmation from the FPGA to the host, for instance confirming that all of the settings were successfully applied. All of these concepts are grouped into a distinct concept called the register bus, which is employed by several of the Instrument Design Libraries.

     The register bus uses a single Host-to-FPGA DMA FIFO for downloading settings, as well as a few registers/NI-RIO controls and indicators for handshaking, returning single-point data to the host, and optionally signaling confirmation that the instructions in the downloaded settings have been carried out.

Figure 9. The register bus is a lightweight protocol built on top of NI-RIO DMA, controls, and indicators, which implements the ability to efficiently download large groups of settings to the FPGA, a common requirement between the host and FPGA side of a given Instrument Design Library.

To manage arbitration, each Instrument Design Library has a unique subsystem ID that allows multiple libraries to share a single register bus. To better summarize the communication policies of the NI PXIe-5644R, table 3 shows which policy is used by each library.

Table 3.  Host and FPGA Data Exchange Mechanisms of the NI PXIe-5644R Instrument Design Libraries.

Furthermore, when combined with the embedded configuration Instrument Design Library, the register bus can be used for FPGA-initiated reconfiguration with no host involvement.

     Because the Instrument Design Libraries represent a defined interface between vendor and user code, they are presented in palettes on both the host and FPGA. Under the host context on a LabVIEW VI block diagram, the host-side interface of the Instrument Design Libraries can be found under Functions>>FPGA Interface>>NI PXIe-5644R. On the FPGA side, they are located under Functions>>NI PXIe-5644R.

Host Palette for the NI PXIe-5644R Instrument Design Libraries

FPGA Palette for the NI PXIe-5644R Instrument Design Libraries

Figure 10. Host and FPGA palettes for the Instrument Design Libraries of the NI PXIe-5644R. The FPGA palette includes additional Instrument Design Libraries for common, lower-level functionality.

A Multitude of Design Patterns

     The NI PXIe-5644R Instrument Design Libraries provide significant capabilities, but alone they do not completely address the requirement of a software-designed instrument to deliver default functionality, nor do they provide a simple host interface that is familiar to the majority of VSA and VSG instrument programmers.

     LabVIEW 2012 provides a new feature that serves as a convenient mechanism to not only distribute additional code that provides default, precompiled functionality and a convenient host interface, but also allow users to easily take ownership of that code. This mechanism is the LabVIEW sample project, which copies a LabVIEW project, specific VIs, and associated files to a user-specified location on disk. It also offers the ability to rename files and update VI banners.

Figure 11. With LabVIEW 2012 sample projects, users of software-designed instruments can take ownership of the appropriate portions of code.

More details on creating sample projects for the NI PXIe-5644R can be found at ni.com/vst/getting-started/.

      The software installer for the NI PXIe-5644R adds the capability to create multiple sample projects, each with different features. The project that is most similar to the default functionality of a VSA and VSG is the Simple VSA/VSG (NI PXIe-5644R) sample project. As shown in Figure 3 above, this sample project provides a host interface that is similar to other VSA and VSG APIs. The high level architecture and data flow of the Simple VSA/VSG sample project is shown in Figure 12.

Figure 12. The Simple VSA/VSG sample project aggregates Instrument Design Libraries on the host and the FPGA to present a starting point familiar to users of VSAs and VSGs.

     Starting with the FPGA VI of the Simple VSA/VSG sample project, there are four main loops, and some additional functionality located in the process subVIs. For configuring all of the programmable components of the NI PXIe-5644R, as well as some of the Instrument Design Libraries on the FPGA, the configuration loop receives registers and settings from the host, and then distributes them to various FPGA subsystems and external circuitry. To increase performance as well as provide independent access from multiple processes on the host, there are two register buses. One is designated for acquisition, one for generation, and each must be able to configure shared resources such as clocking.

Figure 13.  The configuration loop is responsible for receiving data from the host and programming the instrument.

     The RF input loop takes data from the analog-to-digital converters (ADCs); applies a complex vector calibration; and provides for frequency shifts, phase alignment, impairments, and variable, factional, alias-protected decimation. It also implements synchronization as well as digital and power-level triggering before writing data to a FIFO and eventually DRAM.

Figure 14. The RF input loop produces calibrated data at a configurable I/Q rate and writes it to DRAM.

     The RF output loop is similar to the RF input loop, though the order of operations is reversed. Data from DRAM is interpolated, scaled, frequency-shifted, phase-aligned, interpolated, calibrated, and then generated out of the digital-to-analog converters (DACs). There are also signals for triggering and synchronization.

Figure 15.  The RF output loop retrieves data from DRAM then generates it.

     The process subVIs contain loops and state machines that implement multirecord acquisition and waveform sequencing DRAM controllers. They contain a considerable amount of code, which is necessary to meet the high-bandwidth and low-latency performance necessary to guarantee that they can consume full rate ADC data without overflowing, and produce full-rate DAC data without underflowing, while still transferring waveform data to and from the host.

     The fetch loop implements functionality that could exist in the mutirecord acquisition process, but is exposed for convenience. It provides one final opportunity to process acquired data as it leaves DRAM and before it is sent to the host. This path is in its own loop so that IP, which may not meet the timing requirements of the 120 MHz RF input and output loops, may still be employed. To accommodate such IP, reducing this loop rate by a small amount does not adversely affect fetch performance, and though reducing it by a considerable amount may, this will only increase the time it takes for the data to reach the host. It will not drop samples or otherwise corrupt data, though acquisition memory may completely fill.

Figure 16. The fetch loop provides an opportunity to process acquired data before it is returned to the host. By default, it returns the data unaltered.

     Although the top-level FPGA VI aggregates the functionality of 13 Instrument Design Libraries, it would be inconvenient to program each of these libraries independently on the host, and this application-level host code would look nothing like that of a traditional VSA or VSG API. To address this, the Simple VSA/VSG sample project includes an additional host layer that aggregates these Instrument Design Libraries into an interface that presents functions more similar to those of a vendor-defined VSA/VSG API. LabVIEW classes provide a convenient mechanism to do this, offering a strictly typed session wire, public and private methods, and a convenient mechanism for maintaining subVI icon headers. Note that the object-oriented concept of inheritance, while available in LabVIEW classes, is not used for this host interface.

Figure 17. LabVIEW classes provide a convenient mechanism for aggregating functionality and maintaining host interfaces.

The Simple VSA/VSG sample project additionally provides several host examples for common RF VSA and VSG operations, which demonstrate how to properly use the host interface. These cover frequency domain and I/Q acquisition; CW and sequence-based waveform generation; and multiple input, multiple output (MIMO) synchronization.

Figure 18. Several host examples demonstrate use of the class-based host interface for the Simple VSA/VSG sample project.

     The Simple VSA/VSG sample project incorporates a significant amount of functionality and presents a familiar host interface. This utility comes at a cost, however, and that cost is code complexity. Specifically, the waveform-based abstractions of the DRAM attached to the FPGA add a considerable amount of code, complexity, and resource utilization of the VST FPGA. Yet not all applications require a waveform-based or instrumentation data movement paradigm. Some applications are better suited with a real-time streaming data movement architecture. For these, the VST Streaming (NI PXIe-5644R) sample project offers a better starting point, with greater opportunity for customization.

Figure 19. The VST Streaming sample project aggregates Instrument Design Libraries on the host and the FPGA to present a starting point which is flexible for real-time, low-latency signal processing and embedded applications.

     The top-level FPGA VI of the VST Streaming sample project has a similar architecture to that of the Simple VSA/VSG sample project. Though, on closer inspection it is considerably simpler. Noticeably absent are the configuration processes, which represent a significant amount of code. The configuration loop is much simpler, with only a single register bus instead of two, and all subsystems are wrapped into a single subVI.

Figure 20. The configuration loop of the FPGA VI found in the VST Streaming sample project, with only a single register bus interface, is considerably simpler than that of the Simple VSA / VSG.

Rather than having separate acquisition and generation loops, the VST Streaming sample project uses a single loop for all analog I/O. This architecture provides deterministic synchronization of RF input and output for applications that require a known phase relationship between the two, and is only possible because both the ADCs and DACs use the same sample clock. The DSP and calibration of the VST Streaming sample project is similar to that of the Simple VSA / VSG.

     The main difference between the two sample project FPGA VIs is that the VST Streaming sample project uses a lightweight mechanism to send and receive data to and from the host. It features simple stream controllers that support basic triggering, continuous and intermittent streams, and overflow and underflow detection. These controllers operate by interrupting the 2-wire handshaking signals between their sources and destinations, effectively gating the data flow. They do not support the full 4-wire handshaking scheme, which has the capability to throttle upstream nodes or be throttled by downstream nodes, so the burden is on the programmer to characterize the system and ensure that all FIFOs controlled by these stream controllers can produce or consume data at the requisite rates. A key concept in the VST Streaming sample project is that the FIFOs, which by default send data to and from the host, may be easily changed to support streaming to other locations on the VST FPGA for additional processing, or over the PXI Express backplane to other modules through peer-to-peer data streaming.

Figure 21. FPGA stream controllers and FIFO encapsulations provide for basic flow control and the ability to easily reroute stream sources and destinations.

     Moving to the host side of the VST Streaming sample project, there is a similar aggregation of the host components of the Instrument Design Libraries, though the mechanism differs from the Simple VSA/VSG. The VST Streaming sample project does not use LabVIEW classes, instead it simply aggregates functionality in subVIs and passes a session to the register bus between them. This register bus session also contains a reference to the FPGA VI Reference, so each of these subVIs has access to not only the register bus communication policy, but also NI-RIO FIFOs and controls. Furthermore, there are no independent sessions for acquisition and generation; all VIs use the same session.

Figure 22. The VST Streaming sample project host interface features a register bus-based session wire for both acquisition and generation subVIs. This example logically groups acquisition and generation into separate rows for readability.

The VST Streaming sample project provides two host examples. The simpler one demonstrates continuous streaming of a waveform to the VST for generation, with either bursted or continuous streaming of acquired data from the VST. The more advanced example demonstrates MIMO synchronization of multiple VSTs.

Figure 23. Examples demonstrate use of the host interface for the VST Streaming sample project.

Extending the Default Functionality

     Out of the box, the Simple VSA/VSG and VST Streaming sample projects provide valuable functionality, and users may find no need to modify them for a considerable period, if at all. For more information on host programming for these sample projects with additional details on distribution, refer to the Host Programming section of ni.com/vst/getting-started. Also linked there are examples for the NI PXIe-5644R, which extend the default functionality of the sample projects with either host-only or host and FPGA modifications for common applications.

     On the FPGA, there is significant opportunity for dramatically enhancing applications with even small, evolutionary changes. Under the Hardware Customization section of ni.com/vst/getting-started/ is a link to a page that aggregates VST Application IP. This IP is downloadable host and FPGA code, designed to easily integrate with one of the sample projects, yet provide capabilities not found in vendor-defined instruments. Because the VST I/O runs at a high clock rate of 120 MHz, other FPGA IP hosted on ni.com/ipnet or elsewhere may not necessarily compile at that speed, and programmers must consider this when selecting from the ecosystem of LabVIEW FPGA IP. Another option is to use the decimation capabilities of the DSP Instrument Design Library and transfer data at a reduced rate to a slower clock domain on the FPGA for processing in the VST Streaming sample project, or reconfigure the retrieve record loop in the Simple VSA/VSG sample project to run at a lower rate, and reuse such IP without as high a clock rate requirement. Another valuable source of IP is that provided by Xilinx, the supplier of the VST FPGA, in the form of their Coregen IP. This IP is generally very resource-efficient, runs at high clock rates, and is available on the LabVIEW FPGA functions palette.

Figure 24. The Xilinx IP palette provides IP for use on the NI PXIe-5644R and other LabVIEW FPGA targets.

If the IP needed for a specific application is not available, it must be built using lower-level primitives in LabVIEW FPGA. There are links to resources on ni.com/vst/getting-started/ for assistance with this, including high-throughput LabVIEW FPGA training provided by National Instruments, additional online white papers, and NI Alliance Partner consulting services.

     After customization, the NI PXIe-5644R FPGA must be recompiled. Over time, with increasing FPGA size and complexity, compilation times have been able to remain constant only with equally dramatic increases in PC computing power. For compiling the NI PXIe-5644R FPGA, National Instruments strongly recommends the LabVIEW FPGA Compile Cloud Service, which features high-performance 64-bit Linux servers running the LabVIEW FPGA compile tools. Even with this level of performance, the default Simple VSA/VSG FPGA VI takes roughly four hours to compile, and the VST Streaming FPGA VI takes two to three. Furthermore, because compiling an FPGA is a nondeterministic process, repeatability cannot be guaranteed, and full designs at high clock rates frequently have a compile success rate significantly less than 100 percent. This means that it may take multiple compiles before one succeeds and produces a valid bitfile that fits all of the logic in the design and meets the real-world timing constraints of the FPGA silicon. Such considerations are not typical of development for microprocessor targets, yet the capabilities of FPGA technology often justify this complexity.

Figure 25. The LabVIEW FPGA Cloud Compile Service significantly reduces compile times and eliminates the burden of maintaining a dedicated compile machine. Each NI PXIe-5644R comes with a free 30-day trial of this service.

     After a successful compile, LabVIEW FPGA overwrites the default bitfile of the Simple VSA/VSG and VST Streaming sample projects so that it will be used automatically the next time the host interface is called. If this behavior is undesirable, or to maintain a collection of multiple bitfiles, the files can be located in the sample project directory under ./FPGA Bitfiles/, or the post-compile bitfile name and destination can be changed in the LabVIEW project though the FPGA VI build specifications. Before a bitfile other than the one with the default name and location can be used in the Simple VSA/VSG sample project, the NI-RIO Open FPGA VI Reference must be updated with the new bitfile, which is located under both the acquisition and generation class Open Session.vi, then Open FPGA VI Reference.vi. For the VST Streaming sample project, the NI-RIO Open FPGA VI Reference is at the top level of the host examples.

     If a LabVIEW FPGA compile fails due to a timing violation with IP that has previously been validated at its configured clock rate, then it is possible that subsequent compiles may still produce successful results. By incorporating more and more IP, however, the FPGA begins to fill, routing the full design becomes challenging, and this may manifest itself as a timing failure. Reducing the amount of logic on the FPGA may yield a successful compile. If, however, a compile fails due to resource utilization, then this failure mechanism is likely accurately reported, and again, reducing the amount of the logic on the FPGA is the only option. For the Xilinx LX195T FPGA on the NI PXIe-5644R, size or time-related compile failures begin to occur when roughly 45 percent of flip-flops, 75 percent of LUTs, and 95 percent of overall slices are consumed. By this metric, the Simple VSA/VSG FPGA VI is roughly 60 percent full with the out-of-the-box functionality, while the VST Streaming FPGA VI is less than 40 percent full. For other more specific resources such as DSP slices and block RAMs, both FPGA VIs are at 30 percent utilization of DSP, the Simple VSA/VSG FPGA VI is at 40 percent block RAM, and the VST Streaming FPGA VI is at only 20 percent block RAM.

     After making all necessary FPGA modifications and producing a valid bitfile, the host must be modified to appropriately control the new FPGA capabilities. There are three basic methods for doing this. The first, which is useful in debugging and for applications that do not require significant polish, is to simply add the necessary NI-RIO or register bus code into the top-level host VI. This is the most straightforward way of interfacing with the FPGA. The next option is to aggregate such code into subVIs that use either the NI-RIO Dynamic FPGA VI Reference or a register bus reference as session information. This creates more polished code, and it has the advantage of being portable. For instance, such code can be easily ported to other targets, or used with multiple bitfiles that have the same corresponding FPGA code additions. For the most polish, when extending the Simple VSA/VSG sample project functionality, adding host code as a public method of the acquisition or generation class preserves the consistency of the host interface. Such VIs are less portable, however, as they may only work with other host VIs of the same class.

Interfacing With NI-RIO at the Top-Level Interface

Wrapping Functionality with NI-RIO Dynamic Wires

Extending Simple VSA/VSG Host Interface Class

Figure 26. There are three primary methods of adding host functionality to the sample projects.

Creating subVIs that use an NI-RIO Dynamic FPGA VI Reference or a register bus reference, and then wrapping these subVIs with a public class method achieves the benefits of both options–portability in the lower-level VI and polish in the top-level VI–with only a small investment in additional code.

Figure 27. Extending classes with VIs that wrap more portable host VIs produces both modularity and polish.

     Finally, the most advanced applications may require even the Instrument Design Libraries to be customized. Before modifying the code in these libraries, the user should copy it to a user-owned directory such as c:\Program Files\National Instruments\LabVIEW 2012\user.lib\. This will prevent future updates to the code in .\instr.lib\ from overwriting user modifications. Because there are many interdependencies within a given library, programmers should take ownership of entire libraries. After this change in ownership and any user modifications, higher-level code must be relinked to the appropriate location on disk, replacing any VIs still referencing .\instr.lib\. For modification of lower-level Instrument Design Libraries such as the register bus, on which other Instrument Design Libraries depend, all libraries in this call chain should be branched to a user directory, ensuring that all code in the application use only one instance of a given library.

Conclusion

     Software-designed instruments promise to initiate the next era of instrument capabilities and test system performance. By facilitating user customization at every opportunity, all the way to the pins of the device, they will enable unique features that would not be possible with vendor-defined hardware and APIs. The NI PXIe-5644R is the first software-designed instrument, bringing this concept to RF test, measurement, and design. Visit ni.com/vst/getting-started to take the next step in creating a completely custom RF instrument.

0 Ratings | 0.00 out of 5

 Print |  PDF

Reader Comments | Submit a comment »