The next level of configurable radio is being driven by and will be based upon the JTRS JPO's specifications for both military and civilian SDRs.

By Alex Rodriguez

Glossary of acronyms

802.11— IEEE specifications for wireless LAN technology that apply to an over-the-air interface between a wireless client and a basestation or between two wireless clients.

CF— Core Framework

DSP— Digital Signal Processor

FPGA— Field Programmable Gate Array

GPP— General-Purpose Processor

GSM— Global System for Mobile Communications

HDL— Hierarchical Design Language

IIM— Implementation-Independent Model

ISM— Implementation-Specific Model

JPO— Joint Program Office

JTRS— Joint Tactical Radio System

SCA— Software Communications Architecture

SDR— Software-Defined Radio

Although SDR's guiding principle is "develop once, run anywhere," development all too frequently must start anew each time the hardware changes. The traditional practice of developing from text-based specifications is incompatible with SDR hardware and software portability. A new methodology for the design of next generation communication radio relies on a higher level of abstraction using Model-based Design. At its heart are executable specifications based on an IIM and ISM. The JTRS JPO has provided guidelines for using these executable specifications to achieve SDR's full potential.

Next Generation SDR Concepts

click the image to enlarge

Figure 1. Executable Implementation-Independent Model is an abstract high-level behavioral representation of a communication system.

SDR provides radios that can be dynamically programmed to support different waveforms, provide new features, improve performance and deliver new services. SDR development is currently driven by the U.S. military, which plans to base JTRS, its next-generation communications system, on SDR. It will enable soldiers to communicate over a wide range of communications systems and emulate the capabilities of any radio simply by adding software. At the same time, an open and interoperable framework, as specified by the SCA, promises to significantly reduce the cost of designing, deploying and maintaining future radios. Meanwhile, attracted by its cost-savings benefits, commercial wireless manufacturers are slowly but steadily adopting SDR architectures.

An important offshoot of the JTRS program, the SCA provides an open architecture framework that defines how hardware and software interoperate. The SCA interposes a CF designed to provide interoperability between waveforms (which are equivalent to standards such as GSM and 802.11 used in commercial applications as a software application that can be downloaded to any radio set that supports the SCA specification).

Development Complexity and Orders of Magnitude

click the image to enlarge

Figure 2. Executable specifications eliminate ambiguity in the design and allow communication among the different development teams.

Nearly every sizeable increase in communications capability has placed huge demands on hardware and software developers, and SDR is no exception. Leading defense contractors, electronics components suppliers and systems integrators are currently developing the next generation of SDRs, which promise to transform wireless communications by allowing all types of wireless devices to operate with each other and enabling new features to be added via software downloads.

Enabling the wireless system to communicate with virtually any waveform via software programs running on much more flexible hardware poses a significant design challenge. In today's military and commercial wireless platforms, the hardware is optimized for the waveform; in particular, the RF section is optimized for the narrow frequency band in which the radio operates. Moving from specific to generic involves compromises that can adversely affect real-time performance, power consumption and size.

Shortcomings of Traditional Design Methods

click the image to enlarge

Figure 3. Designers can use the same model to evaluate different bit widths and analyze quantization effects.

Until now, most SDR developers have used traditional design methods, where specifications conceptualized by systems architects are captured as text documents and used to guide project teams that specialize in areas such as signal processing and RF engineering. These teams specify hardware, design circuits, write software, run simulations, perform tests and generate mountains of data that are used to verify that the implementation results match the specifications.

A key problem with this approach is that errors are often not detected until all the modules can be tested together at the prototype stage. If the prototype results do not match the specification, then engineers need to determine whether the problem lies in the requirements, the simulation models, the interface or the target processor. Because the cost of fixing a problem generally increases by an order of magnitude as the design progresses, a problem with the target processor can quickly drive up development costs.

Critical Challenges of Waveform Portability

These challenges, however difficult, pale in comparison to the need to develop for multiple targets. Every major development program must consider a wide range of hardware options, including GPPs, DSPs and FPGAs, and the hardware selection is often not finalized until well into the development process. Even after the hardware is selected, developers must be prepared for hardware upgrades and derivative form factors to take a completely different direction, such as a switch from DSPs to FPGAs. Traditional development methods are tied to a particular hardware architecture, making it necessary to start again from the specifications to port to a new hardware platform.

Recognizing the limitations of the traditional design methodology, the JTRS JPO has proposed a methodology in which waveform specifications are defined in an executable IIM, which is independent of the hardware specification, and one or more executable ISMs, which are specific to the hardware implementation. This recommendation has three advantages:

• IIM and ISM become a single, unambiguous, executable specification of a waveform that can be shared among teams, departments, and contractors.

• They provide a high-level view of the design to explore system-level analysis and trade-offs and detect potential design and implementation errors.

• They reduce the cost of porting waveforms from one radio set to another while supporting performance analysis, requirements analysis traceability and high-performance waveform design.

IIM and ISM Characteristics

click the image to enlarge

Figure 4. Using Model-based Design, designers can automatically generate code for different targets such as GPP, DSP and FPGA.

The IIM includes information to define, characterize and validate how the waveform behaves that can be verified and traced to the waveform requirement documents. The signal flow, control flow and networking aspects of the waveform are defined using information such as waveform subsystem boundaries, subsystem jitter, latency and timing requirements, subsystem processing requirements and signal port sample times. An executable IIM provides a test bench to verify waveform functional blocks or systems against system requirements and validate their performance.

The ISM, on the other hand, reflects the details of an intended implementation as ported to a specific radio set architecture. It contains more information about the allocations of process components to various processor resources, enabling a detailed understanding of the implementation. It also includes the model of execution timing on the target processors, latencies, memory and queue sizes, allowing the waveform developer and subsequent porting efforts to understand the effect of changes in resource capability on the system level behavior, such as throughput, jitter, latency, memory consumption, DC power and real-time performance.

Model-based Design Enables IIM and ISM

The proven technology of Model-based Design encompasses the concept of IIM and ISM. Unlike the text-based approach, which relies on interpretation of constantly changing design specification documents, Model-based Design is based on the creation of block-diagram executable specifications. Executable specifications eliminate design ambiguity and allow communication throughout the organization and to customers, contractors and suppliers. Using Model-based Design, algorithm developers, RF designers, software and hardware engineers and other development teams can cooperate to make trade-offs and evaluate solutions, enhancing performance and reducing costs.

The executable specification of the waveform is initially defined at a high level using pre-built primitives and advanced algorithms and incorporating other programming languages such as C, C++, FORTRAN, MATLAB or HDL code. The specification can then be executed to determine the performance that would be delivered by the components and algorithms incorporated into the current model. By performing detailed simulations of the system behavior under different conditions, parameter values and inputs, engineers can quickly identify, isolate and fix system design problems. Designers can quickly make changes by adding, subtracting or moving blocks, or changing parameters, and then immediately assessing the effect of the changes.

By simply changing parameters, designers can evaluate the effects of quantization from floating-point, typically used during the early stages of design, to fixed-point representations, typically used in hardware implementation to reduce size, memory and power consumption.

In a text-based approach, implementation of the different components, whether hardware or software is typically done by manual recoding. This process is time-consuming and error-prone. Model-based Design incorporates both the IIM and the ISM. The IIM consists of hardware-independent functional blocks, whereas the ISM consists of blocks that have been optimized for a particular hardware implementation. The model increases in detail as it moves from the specifications phase, through design, implementation and into the overall system validation and testing, but remains a single, unambiguous representation of the system throughout the development process.

Although the model maintains the design intellectual property, it can be used to automatically generate code for a wide range of hardware platforms, including C code for GPPs, C and assembly for DSPs and HDL for FPGAs. Automatic code generation provides a coding standard for the generated code, because the same constructs are used with every build. This approach eliminates hand-coding errors and limits potential error sources between the simulation code and the embedded code. Because the code is directly traceable to the simulation, errors must either be in the interface or in the execution under real-time constraints. Because the model is developed independently of an embedded hardware target, it can easily be retargeted to different platforms and reused in future systems.

Throughout the engineering process, quality is ensured by integrating tests into the model. Each model has a test suite of check cases with baseline results for each released version. This continuous verification and validation helps identify errors early, when they are easier and less expensive to fix. The system-level model developed by the system architect can be used later in the design process to incorporate realistic data generated by simulation or testing to validate the design from a systems perspective.

click the image to enlarge

Figure 5. Model-based Design streamlines SDR development through the creation of executable specifications and IIM and ISM models.

Fulfilling the promise of SDR

Model-based Design is a key component in the development approach necessary for the realization of SDRs. It supports the process of automatic code-generation and code portability across hardware, software and SCA core-framework platforms. Model-based Design streamlines development through the creation of executable specifications and IIM and ISM models, maintaining traceability to the original waveform specifications and ensuring continuous verification throughout the development process. SDR design and deployment using model-based design is significantly simpler and more robust than traditional design processes. The outcome is reflected in improvements in cost, performance and reliability of SDR systems.

About the Author

Alex Rodriguez is the product manager for communications products at The MathWorks. He joined The MathWorks as a senior communications engineer and contributed to the development of the Communications Toolbox and the Communications Blockset and the creation of application examples of communications systems. Prior to joining The MathWorks, Alex was a communications system engineer at National Semiconductor where he designed chips for GSM, cdma2000 and WCDMA communications systems. Alex holds a Master's degree in Communications Engineering from the Universitat Politècnica de Catalunya (UPC) — School of Telecommunications in Barcelona, Spain, and a Master's degree in Wireless Communications from the Ecole Nationale Supérieure des Télécommunications (ENST) in Paris, France.