By Jack Wilber, MathWorks
Engineers at BAE Systems, engaged in the design and development of embedded systems involving FPGAs, are highly skilled in the well-established, traditional design process based on the hand-coding of VHDL. Recently, they seized a rare opportunity to directly compare that process with a new approach built upon Model-Based Design. While developing a software-defined radio (SDR) waveform for MIL-STD-188 satellite communications, they ran two development efforts in parallel―one using the traditional approach, the other using Model-Based Design with MathWorks and Xilinx tools. They discovered that Model-Based Design reduced development time by more than 80%.
The traditional design flow at BAE Systems involves three distinct phases (Figure 1):
Ideally, all the information and detail defining the algorithm is carried forward from the system engineers to the hardware engineers, who will implement the design, but there is inevitably some loss in this transfer. Engineers attempt to fully capture the detail of the design as a hardware specification and as input-output test vectors. Not only is this process quite lengthy, but it is also prone to error. To overcome these limitations, engineers use Model-Based Design with Simulink and Xilinx System Generator to build a model that becomes an executable specification of the system for development teams to follow. This approach eliminates the need to pass written documentation to a software team for VHDL coding and reduces the three phases of the traditional design approach to two phases (Figure 2):
Two groups worked in parallel to develop the SDR waveform’s signal-processing chain, hardware interfaces, and clocking. One group, led by Robert Regis, a senior engineer at BAE Systems with more than 15 years’ experience in VHDL development, used the traditional workflow. The other, led by Sean Gallagher, a senior engineer at Xilinx, used Model-Based Design.
Each group tracked the hours spent on the following tasks:
Regis and Gallagher each implemented the same subset of MIL-STD-188-165a (Figure 3). In this design, the transmitted data passes through a scrambler, differential encoder, Reed-Solomon encoder, matrix interleaver, convolutional encoder, and quadrature amplitude modulation (QAM) modulator to produce baseband complex samples, which in the transmitter are passed to a pair of digital-to-analog converters (DAC) through low-voltage differential signal (LVDS) serial links. The receive chain reverses these steps:the complex baseband samples received by a pair of analog-to-digital converters (ADC) passes through a QAM demodulator, Viterbi decoder, matrix deinterleaver, Reed-Solomon decoder, differential decoder, and descrambler to produce a serial bitstream. A Sync Detect function is used to identify Reed-Solomon block boundaries.
Both groups had access to an equivalent set of prevalidated components (IP cores) —for example, Regis used existing VHDL code for the Reed-Solomon encoder, while Gallagher used a Reed-Solomon encoder block available within System Generator. Similarly, both had access to a Reed-Solomon decoder, Viterbi decoder, and interleavers. In Regis’s case these were available as IP cores, and in Gallagher’s case they were incorporated through inclusion of an associated System Generator block that, in turn, referenced and instantiated a Xilinx IP core.
BAE Systems engineers modeled and simulated the transceiver waveform using Simulink and the Communications Blockset (Figure 4). They used frame-based processing in the model to increase simulation speed. (Frame-based connections cause the model to pass an entire frame, or packet of data, between blocks, thereby reducing block execution management overhead and increasing simulation speed.)
The Simulink model gave them the flexibility to implement the waveform on a range of targets—for example, they could have used Real-Time Workshop to automatically generate code for a DSP implementation that met the performance requirements of the original specification. To ensure a valid comparison with the traditional design flow, however, they implemented the design on an FPGA.
The Simulink model was handed off to Gallagher, who used it as a reference design in building the equivalent model in Xilinx System Generator. Gallagher used existing Xilinx blocks for Reed-Solomon encoding, matrix interleaving, and Viterbi decoding. He built other high-level blocks for which there was no direct substitute using lower-level Xilinx blocks (Figure 5).
He used scopes and bit-error-rate meters to debug the model and verify operational performance before using Xilinx System Generator to automatically generate VHDL and synthesize the FPGA.
The waveform involves the processing of single bits or scalar, complex values produced by the QAM Modulator. In the receiver, real soft symbols produced by the QAM Demodulator are represented using finite precision values. Therefore, unlike the floating-point double-precision values that exist in the Simulink model, in the System Generator model it is necessary to select the scaling to be used to represent these values. Gallagher selected the scaling parameters based on trial and error until bit widths were as small as possible without significant impact to performance.
Regis’s team required 645 hours to complete the design and development of the signal-processing chain (Figure 6). Gallagher needed only 46 hours, a reduction in development time greater than 10 to 1. When equal amounts of hardware integration and lab testing―estimated at 137 hours―are factored in, the end-to-end improvement is still greater than 4 to 1.
David Haessig, Ph.D., a senior BAE Systems technical staff member who was involved in both efforts, points out that in addition to the obvious time savings provided by automatic code generation, Model-Based Design accelerated the project by shifting debugging and analysis forward in the schedule. “When following the traditional design flow process, a large portion of the simulation and debugging work tends to occur later in the design, during VHDL coding. With Model-Based Design the model defines the code, and you are therefore obliged to include in the model every detail needed to define the waveform. Typically the model is built and tested incrementally, and you deal with the bugs and the algorithmic issues as they occur. Debugging is handled almost entirely during the modeling phase of the design, with a bit-true, cycle-true model. With access to Similink and to MATLAB data visualization tools, bugs are much easier to identify and fix prior to VHDL. The alternative, debugging the VHDL code, is more difficult and tedious."
BAE Systems identified three additional factors that contributed to the substantial reduction in development time achieved using Model-Based Design: clocking, defect discovery, and component interfaces.
In the traditional design flow, Regis spent substantial time hand-calculating a combination of clock enables and multiple clock domains necessary for generating the odd sample rates associated with Reed-Solomon encoding and decoding. In contrast, Gallagher relied on Xilinx System Generator to automatically derive a common clock at the highest rate and build enabling logic to throttle multiple rates.
As reflected in the time logged for verification in each approach, finding and repairing defects was greatly simplified in the approach using Model-Based Design. “With Simulink and Xilinx System Generator, the model is directly connected to the resulting code, which enables you to discover bugs at the modeling stage using source and sink blocks, not at the VHDL behavioral test stage using test benches." Haessig says.
Regis notes that while he had to carefully read the interface specifications of each block he used, Gallagher could wire blocks together with relative ease. “With System Generator, it's amazing how easily the IP blocks are connected together. There is no need to study data sheets, clocking and control options, and so on. This may be the most underrated aspect of Model-Based Design."
Based on the results of the experiment, Haessig expects Model-Based Design with MathWorks tools to become an integral part of the BAE Systems software development process.
In addition, BAE Systems is exploring ways to use MathWorks tools for Model-Based Design to enable waveform portability by automatically generating software communications architecture (SCA)-compliant software and firmware. Joint Tactical Radio System (JTRS) radios must follow SCA as a standard for achieving waveform portability. Responding to a request from the Joint Program Executive Office (JPEO), BAE Systems is involved in the deployment of waveforms that JPEO can use in current and future radio systems without redeveloping the waveform components. The same SDR code will be able to run on new hardware platforms without modification.
BAE Systems is working with The MathWorks, Virginia Tech, Xilinx, and Zeligsoft to create an interface that will enable code generated by Real-Time Workshop and System Generator to be directly incorporated into SCA-compliant radios. According to Haessig, “This initiative holds great potential for reducing time to market and the cost of JTRS radio development, allowing seamless transition from simulation to an SCA-compliant implementation; increasing reusability and portability of components; and expanding the lifespan of source code."