Model-Based Design Helps Unleash the Potential of Software-Defined Radio

tmily

Model-Based Design Helps Unleash the Potential of Software-Defined Radio [Copy link]

Introduction: As design complexity increases, the traditional development model based on text specifications can no longer meet the portability requirements of SDR hardware and software. This article discusses a new design method using the "model-based design" concept to address these challenges and fully realize the potential of SDR.

Although the guiding principle of software-defined radio (SDR) is "develop once, run anywhere", all development often has to start over every time the hardware changes. The industry has realized that the traditional development model based on text specifications can no longer meet the portability requirements of SDR hardware and software. This realization has prompted the emergence of a new design approach for the next generation of communication radios. This approach is based on a higher level of abstract description and adopts the concept of "model-based design". Its core is the operational specifications based on "implementation-independent models (IIM)" and "implementation-specific models (ISM)". The Joint Program Office (JPO) of the Joint Tactical Radio System (JTRS) has proposed guidelines for the use of these operational specifications to fully realize the potential of SDR.

The radio provided by SDR can be dynamically programmed to support different waveform standards, provide new features, improve system performance, and support new services. The main promoter of SDR development is the US military, which hopes to implement the basic JTRS (next generation communication system) on SDR. SDR will enable soldiers to communicate on various communication systems and imitate the functions of any radio simply by adding software. At the same time, an open and interoperable framework, especially the framework defined by the Software Communication Architecture (SCA), can significantly reduce the cost of designing, deploying and maintaining future radios. From the current point of view, due to the low-cost advantage of SDR, many commercial wireless equipment manufacturers have gradually begun to adopt the SDR architecture.

As an important branch of the JTRS project, SCA provides an open architecture framework that defines how to achieve interoperability between various software and hardware. SCA also proposes a core framework (CF) designed to provide interoperability between different waveforms (similar to standards such as GSM and 802.11), which are used in commercial applications as software applications and can be downloaded to any radio device that supports the SCA specification.

Increased development complexity

Almost every major advancement in communications technology presents a huge challenge to software and hardware design engineers, and SDR is no exception. Leading weapons contractors, electronic component suppliers, and system integrators are currently developing the next generation of SDRs, promising that the new SDRs will transform wireless communications, allowing various wireless devices to operate interoperably and adding new features through software downloads.

It will be a great design challenge to enable wireless systems to communicate with any waveform through software programs running on more flexible hardware. In today's military or commercial wireless platforms, the hardware is optimized for waveforms, especially the RF part, which is optimized for the narrow frequency band in which the radio operates. The shift from dedicated design to general-purpose design will inevitably have an adverse impact on the system's real-time performance, power consumption and size.

Disadvantages of Traditional Design Methods

Until now, most SDR designers have been using the traditional design approach: specifications defined by system architects are refined into documents, which are used to guide project teams specializing in signal processing or RF engineering. These teams then define the hardware, design the circuits, write the software, run simulations, test, and generate large amounts of data that are used to verify that the final implementation meets the specifications.

A significant problem with this approach is that many errors are often not detected until the prototype stage when all modules can be tested together. If the product prototype does not meet the specifications, the designer must determine whether the problem is in the system requirements, the simulation model, the interface, or the target processor. Because the cost of solving the problem increases with the size of the design, problems with the target processor will quickly increase the cost of development.

Key Challenges of Waveform Portability

While these challenges are not easy to solve, they are much less difficult than the requirements of multi-target development. Every major development project must consider a variety of hardware options, including general-purpose processors (GPPs), DSPs, and FPGAs, and the choice of hardware is often not determined until a certain stage in the development process. Even if the hardware has been selected, designers must be prepared for hardware upgrades and form factor changes to completely change the development direction, such as switching from DSP to FPGA. Traditional development methods are associated with specific hardware architectures, so in order to implement a new hardware platform, you must start over from the technical specification.

Recognizing the limitations of traditional design methods, the JTRS Joint Program Office proposed a new design approach. In this approach, waveform specifications are defined in an executable IIM (independent of the hardware specification) and one or more executable ISMs (dependent on the hardware specification). This approach has three advantages: first, the IIM and ISM are single, unambiguous, executable waveform specifications that can be shared among teams, departments, and contractors; second, they provide a high-level design perspective to conduct system-level analysis and trade-offs and discover potential design and implementation errors; and finally, they reduce the cost of porting waveforms from one radio to another, while also supporting performance analysis, requirements analysis traceability, and high-performance waveform design.

The IIM contains information that can be used to define, characterize, and verify waveform behavior. Waveform behavior can be verified and tracked to meet the requirements in the waveform requirements document. The signal flow, control flow, and networking of the waveform can be defined using information such as waveform subsystem boundaries, subsystem jitter, latency and timing requirements, subsystem processing requirements, and signal port sampling times. The executable IIM provides a test bench to verify that waveform functional modules or systems meet system requirements and verify their performance.

On the other hand, the ISM reflects the details of the intended implementation when ported to a specific radio architecture. The model contains more information about the allocation of processing elements to various processor resources, which allows designers to understand the implementation in detail. It also includes models of the execution time, latency, memory and queue sizes of the target processor, which allows waveform designers and subsequent porting efforts to understand the impact of resource changes at a system level, such as throughput, jitter, latency, memory consumption, DC power and real-time performance.

Model-Based Design Makes IIM and ISM a Reality

Proven model-based design techniques incorporate IIM and ISM concepts. Unlike text-based methods (which rely on the interpretation of constantly changing design specification documents), model-based design is based on the creation of executable specifications from block diagrams. Executable specifications can eliminate design uncertainty and enable communication across the organization and between customers, contractors, and suppliers. Using model-based design, algorithm engineers, RF design engineers, software and hardware design engineers, and other development teams can collaborate, make design trade-offs, and evaluate solutions to improve system performance and reduce costs.

The executable specification of the waveform is initially defined at a high level, using pre-built elements and advanced algorithms, and includes other programming languages such as C, C++, Fortran, MATLAB or HDL code. This specification is then executed to determine the performance that the algorithm or element currently in the model can provide. By performing system behavioral level simulations under different states, parameter values and input conditions, designers can quickly identify, isolate and fix system design problems. Designers can quickly modify designs by adding, removing or moving modules, or changing parameters and immediately evaluating the impact of these changes.

By simply changing parameters, designers can evaluate the impact of switching from a floating-point model (typically used early in the design process) to a fixed-point model, which is typically used during hardware implementation to reduce system size, memory, and power consumption.

In text-based approaches, the implementation of different components (whether hardware or software) is generally recoded manually, which is a time-consuming and error-prone process. Model-based design includes two models: IIM and ISM. The former consists of hardware-independent functional modules, and the latter consists of modules optimized for specific hardware. As the development process progresses from the specification stage to design, implementation, and verification and testing of the overall system, the content of the model becomes more and more detailed, but it always remains a single and clear representation of the system throughout the process.

While protecting the design intellectual property, this model can be used to automatically generate code that can be used on many hardware platforms, including C code for GPP, C code and assembly code for DSP, and HDL code for FPGA. Automatic code generation can provide coding standards for the generated code because the same constructs can be used in each implementation. This approach eliminates manual coding errors and limits potential errors between simulation code and actual embedded code. Because the code can directly track the simulation, errors must appear in the interface or execution under real-time constraints. Because these models are developed independently of the embedded hardware, they can be easily ported to other platforms and reused in future systems.

Integrating testing into models throughout the development process ensures design quality. Each model has a set of test vectors and a baseline of test results for each release. Continuous verification and validation helps find problems earlier, which are easier and less expensive to resolve. System-level models developed by system architects can be used later in the design process to verify the design from a system perspective in conjunction with actual simulation or test data.

Conclusion

Model-based design is key to the development methodology required to implement SDR. It supports automatic code generation and code portability across different hardware, software, and SCA core framework platforms. Model-based design can simplify and make the SDR development process more efficient by establishing executable specifications, IIM and ISM models, maintaining traceability of original waveform specifications, and ensuring continuous verification throughout the development process. This approach makes designing and deploying SDRs simpler and more robust than traditional methods, thereby improving the performance and reliability of SDR systems and reducing design costs.

By Alex Rodriguez

MathWorks