1. The Conventional Approach of Reducing Barriers
Typically, tools that span phases and functions of the design process do so by attempting to reduce the barriers between each phase and function, not by creating a unifying environment and language that spans them all. For example, within the development of an emerging RF communication standard, a specialist in communication system design might model and simulate a communication stream in a purely algorithmic and mathematical sense. To test their model, designers would either create their own test bench or, in the case of industry-standard protocols, reuse a compliance suite.
Once satisfied the design functions correctly, the historical transition from design to implementation was to simply hand the algorithm over to a different team that would hand-translate the math algorithm into an implementation; most likely using either ANSI C or HDL depending on the execution requirements of the implementation.
Figure 1. The "V" diagram is often used to represent the ideal flow of design, implementation, and test. Using a common system design language that spans the entire "V" maximizes knowledge and algorithm reuse while minimizing errors in translation and find/fix cycle times.
In addition, the test bench itself would need to be translated. This translation step requires a different team, with different skills, and anything lost in translation is a common source of new bugs or reduced test coverage. As if this initial translation layer wasn’t complicated enough, the problem is compounded as design rework is identified or implementation bugs are found. This disconnect between the design algorithm and the implementation slows the “find-and-fix” development cycle.
To mitigate some of these issues, many tools provide an automatic code generation step to facilitate the translation of the simulation to ANSI C or HDL. While this process facilitates the migration to a processor or a field-programmable gate array (FPGA), it does not remove the requirement of deploying and ultimately debugging the design by someone familiar with ANSI C or HDL; the original design was not likely perfect, nor was the automatic code generation.
2. A Single-Tool Methodology With LabVIEW
As an alternate approach, with NI LabVIEW system design software, the communication designer would model their communication stream using LabVIEW before then using it to directly implement their test bench. Once satisfied with the design and tests, the system designer simply retargets their design algorithm to either a processor or an FPGA directly for implementation. The system designer could use the same environment, algorithm, and debug and test methodology from their early exploratory design to their final implementation. This maximizes both knowledge and algorithm reuse while minimizing errors in translation and find/fix cycle times.
Given those clearly stated benefits of reusing the same algorithms in design, implementation, and test without the separate code generation step, one has to ask why more system design software doesn’t take the direct reuse approach. The answer is largely historical. Most system design software started out in the simulation space optimized for time-domain evaluation of system behaviors and then later evolved a path to implementation. The roots of LabVIEW are in system implementation, and it has evolved toward design and simulation. The language, the environment, and, more importantly, the IP/algorithm blocks are designed to compile and execute at extreme real-time rates on both processors and FPGAs.
In addition to making algorithmic reuse possible, the implementation heritage of LabVIEW greatly accelerates many simulation-time activities. For example, LabVIEW fully compiles desktop algorithms to processor-specific machine code. For purely function DSP-type algorithms, system designers can implement and debug their algorithms at extremely fast speeds relative to continuous time-domain simulation methodologies. The advantage is magnified when compared to simulations of designs intended to target FPGAs. LabVIEW supports the expected forms of bit and cycle accurate simulation well, but in many cases, when functional test will suffice, LabVIEW is orders of magnitude faster because the functional code is fully compiled and optimized for local functional execution and not “simulating” at all. It is simply more practical to reuse a fast implementation-algorithm in simulation than a slower simulation-algorithm in implementation—thus, the great advantage of LabVIEW relative to other system design software.
3. LabVIEW System Design and RF Communication Design
Returning to the example of design and test convergence within RF, communication design introduces a few unique complexities to the general trend of convergence. Most significantly, to test an RF receiver you must create a transmitter, and to test a transmitter you must create a receiver. Oftentimes, the signal and measurement characteristics of these testers must surpass that of the design itself. Additionally, the rate of change of RF communication approaches and standards is extremely fast, requiring flexibility and speed in the testers themselves. So, the ideal test instrument for the RF space would allow for quick reuse of both transmit and receive digital signal processing (DSP) algorithms and also be highly performant and flexible.
The traditional approach to these sorts of testers has been to create a fixed-function instrument crafted to measure and test a specific category of communications. To truly converge design and test, not only does the test process, test bench, and collateral need to be pulled forward into the design flow, but in the ideal sense, the design and tests could execute not in simulation, but rather directly with real-world hardware and real-world signals. In the case of LabVIEW and the NI PXIe-5644R vector signal transceiver, once the DSP building blocks of a communication stream are defined and executing as functionally expected on a desktop, the designer can retarget their algorithm from their desktop design environment to the vector signal transceiver running on its FPGA.
Figure 2. The architecture of the NI PXIe-5644R vector signal transceiver allows for user-modifiable DSP blocks to be simulated and deployed on either the host or firmware of the device. The other input/output and memory interfaces are also available for modification to complement the algorithm design.
A key element of this migration and a common stumbling block in the transition from algorithm design to final deployment (either for the design itself or the tester), is the proper integration of real-world time and, more importantly, hardware I/O and signal calibration. Traditionally, for both design and test functions, the DSP algorithm designer is distinct from the team that would implement device firmware including I/O integration. With the vector signal transceiver and LabVIEW RIO programmable devices like it, NI provides a reprogrammable, and thus very flexible, RF hardware platform with highly optimized IP blocks. These blocks manage the standard complexities of high-speed A/D and D/A integration with signal calibration as well as DMA streams of data to host processors and high-speed onboard memory. This IP, included with the vector signal transceiver, addresses three fundamentally important characteristics. First, it functionally simulates on the desktop so it can be used during algorithm design. Second, the source code is available for reference or modification as needed. And finally, as stated previously, it migrates smoothly to actual real-time execution.
4. Converging Design, Development, and Deployment
To deliver a truly cohesive system design flow from algorithm to deployment, you need a comprehensive software/hardware view. Your software must include the appropriate timing, I/O, and DSP algorithm IP. This IP must not only execute in simulation time, but should also quickly execute for functional debugging with rapid design turns and ultimately migrate both your test and design code from the desktop environment to reprogrammable deployment hardware.
The algorithms and tests you develop are your critical IP, and the job of any system design tool is to maximize your productivity by giving you the ability to reuse the same IP everywhere needed with few differences between the original design and its ultimate implementation. This is possible only through a system design software originally conceived for implementation with open and reusable building blocks that are perfectly matched with reconfigurable hardware built for an iterative design process. LabVIEW system design software and the LabVIEW RIO-enabled vector signal transceiver combine, by design, to deliver on this vision.