comment on this article

Design flow developments enable more capable signal processing

Design flow developments enable more capable signal processing

Continuity in the design flow is becoming critical if engineers are to meet tighter budget and time constraints when developing next generation signal processing and communications systems.

Traditionally, system engineers, algorithm developers and hardware engineers use different tools, which can introduce gaps in the workflow. However, with Model-Based Design, engineers 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.

Requirements analysis and high level design tradeoffs have often been done on paper, with Excel or with expensive prototyping hardware. Algorithm implementation in C or a hardware description language (HDL) is done manually, as is testing and verification. This process often requires several iterations between the algorithm design team and the C and HDL teams, due to unclear requirements and design documentation or inherent design difficulties.

With Model-Based Design, system engineers can model the behaviour of digital, analogue and rf components and perform design tradeoffs 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.

Later in the development process, these models can become the design artefacts from which hardware engineers generate HDL code. At that time, system level models and tests can be reused as a test bench to validate the performance of the HDL implementation and the final hardware against the model level results.

Defining requirements
Modern signal processing and communications systems are characterised by complex and interconnected digital, analogue, mixed signal, radar and rf subsystems. At the beginning of a project, requirements are often incomplete or conflict, so the first step is to use the high level requirements to derive well defined function level requirements, which can then be portioned into relevant subsystems.

As an example, an ISM band transceiver may be required to handle frequencies from 862MHz to 928MHz and from 431MHz to 464MHz, with data rates ranging from 1kbit/s to 300kbit/s, various receiver sensitivity specifications (bit error rate, BER) and intermediate frequencies.

To implement these requirements, the system engineer needs to break down the high level functional block diagram into its digital and rf components. Model-Based Design means these components can be combined into one model that allows for design trade offs to be made and for system performance to be analysed to ensure that it meets the high level requirements.

Optimal design trade off often 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.

The model can be used as a set of executable specifications, with model level test vectors 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. 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 90%, primarily because bugs are typically discovered and removed in the design and simulation stage, instead of at the test stage.

Tradeoff studies
Engineers can perform simulations early in development and make effective tradeoffs in designs that include both digital and analogue/rf components, while ensuring the various design options satisfy system level requirements.

To study how best to meet the system level BER requirement, engineers can explore design options by swapping in different types of IF receiver architecture and modulation and demodulation schemes in one tool environment.

Simulating the models can also eliminate guess work from the link budget design and analysis. 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.

In the past, a system level tool was used to create an overall representation of the design. This tool was different and disconnected from those used for detailed modelling and exploration of system algorithms. Recent advances in algorithm modelling tools help engineers to build and maintain an integrated model that captures overall system complexity and the interaction of various subsystems.

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

As a signal processing or communications system design proceeds, an early elaboration stage is identification of those portions of the design which can be implemented on a fixed point dsp, a microcontroller, an fpga or an asic. To do so, engineers convert early floating point designs to fixed point, but this conversion is a major challenge.

Previously, engineers would take floating point system models and recode major portions of the design in fixed point C or HDL, resulting in delays, bugs, flaws and wastage of time and resources. Rather than writing or rewriting the algorithm in C and converting it manually to fixed point, Model-Based Design tools support automatic fixed point conversion. In many cases, engineers can build and maintain a single polymorphic reference model that can run in floating or fixed point modes, as needed.

Verifying that an implementation meets the design requirements has traditionally been an iterative process. C or HDL code – either written manually or generated automatically – is delivered to design engineers, who must write tests to evaluate the code, isolate errors and issue change requests until the implementation matches the design. In Model-Based Design, the models used to design algorithms can also be used to generate C or HDL code.

Verification can be completed through cosimulation of the system level models with the final C or HDL design. At this stage, system level models are reused as the test bench. This reuse saves time writing test bench code and creating test vectors.

Close coupling between design, implementation and verification not only saves time when compared to coding manually, but also helps to minimise implementation errors.

With Model-Based Design, engineers use models as a golden reference that links every part of the development process – requirements, design, implementation and testing. Creating models at the start of the process saves more time at every subsequent stage through reuse or elaboration of design elements or by identifying errors when it takes time and money to fix them. By reusing models, system engineers can focus on design innovation to achieve higher performance.

Several recent advancements – including multidomain modelling, stream processing algorithms with full integration to the system level models, fixed point design and C and HDL code generation and verification – streamline, integrate and automate many critical steps in the design of complex signal processing and communications systems.

Joy Lin is The Mathworks' aerospace and defence industry marketing manager.

Joy Lin

Related Downloads

Comment on this article

This material is protected by MA Business copyright See Terms and Conditions. One-off usage is permitted but bulk copying is not. For multiple copies contact the sales team.

What you think about this article:

Add your comments


Your comments/feedback may be edited prior to publishing. Not all entries will be published.
Please view our Terms and Conditions before leaving a comment.

Related Articles