Developing next-gen signal processing and communications systems: Engineering tools and design flow advancements

Story

October 06, 2010

It used to be that system engineers, algorithm developers, and hardware engineers used different tools to do their jobs, which often resulted in workflow gaps that led to design errors. However, with Model-Based Design (MBD), engineers use models as a golden reference that links every part of the development process - requirements, design, implementation, and testing.

A traditional versus MBD workflow is examined, and multidomain modeling tool requirements definition, design trade-off study performance, in-model algorithm development, and verification against design requirements are also examined.

To accommodate tighter budget and time constraints for developing next-generation signal processing and communications technologies, continuity in design flow is becoming critical for engineers. Traditionally, system engineers, algorithm developers, and hardware engineers use different tools to do their jobs, which can introduce gaps in the workflow that may lead to errors in the design and delays in the development process. In contrast, by using Model-Based Design, engineers across disciplines use a common set of models in an extensible environment to define requirements, develop algorithms, implement or target hardware, and test and verify their designs.

Traditional workflow versus Model-Based Design

In a traditional workflow, requirements analysis and high-level design trade-offs are often done on paper or with a basic tool such as Excel or using expensive prototype hardware. Algorithm implementation in C or Hardware Description Language (HDL) is done manually, as are testing and verification. This process often requires several iterations between the algorithm design team and the C and HDL teams as a result of unclear requirements and design documentation or inherent design difficulties.

With Model-Based Design, system engineers use models to derive low-level requirements and then use the models to interface with customers and suppliers. They model the behavior of digital, analog, and RF components of the system and perform design trade-offs in simulation, which can be difficult or impossible using paper-based design reviews. Algorithm developers can then reuse and elaborate the same models to build and test more detailed designs. Further in the development process, these models can become the design artifacts from which hardware engineers automatically generate HDL code. Then the system-level models and tests can be reused as a test bench to validate performance of the HDL implementation and the final hardware against the model-level results.

With Model-Based Design, models are reused and elaborated at every development phase, reducing the amount of translation inefficiencies and errors in the process. With the model at the center of the design process, engineering teams also have a common platform to share the design (see Figure 1).

 

Figure 1: Model-Based Design provides a multidomain tool environment and integrates all phases of development.

 

Defining requirements with a multidomain modeling tool

Modern signal processing and communications systems are characterized by complex and interconnected digital, analog, mixed-signal, radar, and Radio Frequency (RF) subsystems. Further, at the beginning of a project, requirements are often incomplete or conflicting. Thus, the first step is to use the high-level requirements to derive well-defined, function-level requirements that can then be portioned into relevant subsystems. To illustrate using an example, the figure below is a set of high-level and functional-level requirements for an ISM Band FSK/GFSK/OOK/MSK/GMSK Transceiver(1). The high-level requirements are: frequency bands of 862 MHz to 928 MHz, and 431 MHz to 464 MHz, with data rates of 1 kbps to 300 kbps. Digital function-level requirements are receiver sensitivity Bit Error Rate (BER) specifications (see Figure 2), and Intermediate Frequency (IF) receiver bandwidths.

 

Figure 2: Sample high-level and function-level specification of a High Performance, Low Power, ISM Band FSK/GFSK/OOK/MSK/GMSK Transceiver IC(1) illustrates the type of high-level requirements that system engineers receive.

(Click graphic to zoom)

 

To implement this set of requirements, the system engineer needs to break down the high-level functional block diagram into its digital and RF components. With Model-Based Design, the digital and RF components can be combined into a single model that allows the system engineer to make design trade-offs and analyze system performance to ensure that it meets the high-level requirements. Traditionally, optimal design trade-off comes from years of hands-on experience in the digital and RF domains, or from heritage design. Model-Based Design relies less on heritage knowledge and more on system-level simulation to find the optimal design.

The model can be used as a set of executable specifications and the model-level test vectors can be used as the acceptance criteria. Often, the process of creating the models and running simulations uncovers requirement errors at the beginning of a project, when they are less expensive and easier to fix compared to finding them in the implementation and testing stages, when fixes can be an order of magnitude more costly. The time and effort that engineers invest in creating the executable models at the requirement stage will pay significant dividends in the latter stages of the design process. Aerospace companies who use Model-Based Design typically reduce their verification time by about 90 percent primarily because bugs are typically discovered and removed in the design and simulation stage, instead of at the test stage.

Performing design trade-off studies

As mentioned, by using a multidomain Model-Based Design environment, engineers can perform simulations early in development and make effective trade-offs in designs. For example, to study how best to meet the system-level BER requirements, systems engineers can explore design options by swapping in different types of IF receiver architectures and modulation and demodulation schemes in a single tool environment.

Simulating the models can also eliminate guesswork. Instead of relying on heritage design to understand what would be adequate margins in each phase, effective frequency margins can be lowered because gains and losses at each stage can be better understood via simulation than static analysis.

Developing algorithms in models

The system-level models used for requirement definition can be reused, thereby serving as a basis from which a detailed algorithm design can be developed. Modeling tools generally provide libraries of common building blocks, such as common filters and amplifiers. Teams can also develop and share custom building blocks, reducing the amount of duplicate effort across projects or companies.

In the past, engineers had to use a system-level tool to create an overall system model representation that was different and disconnected from tools that allowed for detailed modeling and exploration of the algorithms within the system. Recent advancements in algorithm modeling tools help engineers build and maintain a single integrated model that captures the overall system complexity and the interaction of various subsystems. For example, tools now support stream processing for continuous acquisition of live data, processing large signal and image data files, and for embedded implementation, while maintaining tight integration with system-level modeling tools. In addition, these tools support automatic management of state information, data indexing, and buffering, which are particularly useful for iterative or stream-processing algorithms.

Verifying implementation against design requirements

A key benefit of building models and running simulations of executable system specifications is that those models can then help engineers significantly improve the efficiency and the quality of results of the final system implementation.

As a modern signal processing or communications system design moves through the design flow, an early key elaboration stage is identification of the portions of the design suitable for implementation on a fixed-point DSP, a microcontroller, an FPGA, or an ASIC. To make this assessment, engineers must convert the early floating-point designs to fixed point. However, fixed-point conversion is one of the major challenges in communication systems workflow. Traditionally, at this stage, engineers would take the floating-point system models as a starting point and recode major portions of the design in fixed-point C or HDL, resulting in delays, bugs or flaws, and wastage of time and resources. Rather than writing or rewriting the algorithm in C and manually converting it to fixed point, Model-Based Design tools often provide automatic fixed-point conversion capabilities. In many cases, engineers can now build and maintain a single polymorphic reference model that can be run in floating-point or fixed-point as needed. In Model-Based Design, the models that were used to design algorithms can be used to automatically generate C or HDL. By connecting the algorithm design environment to the code implementation environment, engineers reduce the number of errors introduced during translation.

Verification can be completed through co-simulation of the system-level models with the final C or HDL design. At this stage, the system-level models are reused as the test bench. Through this reuse, engineers save time writing test bench code and creating test vectors. This close coupling between design, implementation, and verification not only saves time when compared to coding manually, but also helps minimize implementation errors.

Reference:

1. Analog Devices, Technical Data ADF7023 – High Performance, Low Power, ISM Band FSK/GFSK/OOK/MSK/GMSK Transceiver IC www.analog.com/en/rfif-components/rfif-transceivers/adf7023/products/product.html

Joy Lin joined MathWorks in 2008 as Aerospace and Defense Industry Marketing Manager. Prior to this, she worked at Boeing Defense, Space & Security in El Segundo, California. She holds a bachelor’s degree in Aerospace Engineering from the Massachusetts Institute of Technology and an MBA from the MIT Sloan School of Management. Joy can be contacted at [email protected].

MathWorks 508-647-7159 www.MathWorks.com