Advertisement
Product Releases
Advertisement

Model-base Design of Wireless Systems

Fri, 06/29/2007 - 6:55am
By Mike Woodward, The MathWorks

Technical and market forces make it increasingly challenging to design wireless systems in a timely and profitable manner. Wireless standards are more complex, devices must integrate several wireless standards, and companies are facing increased competition from new entrants to the market. As a result, in the wireless ASIC

click to enlarge

Figure 1. Model-Based Design methodology, which puts a system model at the center of the development process, from requirements capture and design to implementation and test. The model is an executable specification that is continually refined throughout the development process. Simulation shows whether the model works correctly.
market first-mover advantage wholly determines profitability. According to the International Technology Roadmap for Semiconductors (ITRS), the cost of design is the greatest threat to the continuation of the semiconductor roadmap.

Some of the design practices used in the industry are unfortunately contributing to the problems rather than providing solutions. Table 1 shows key design challenges and the reasons for failure associated with them.

Using a design process that prevents these frequently occurring design failures will lead to improved quality and time-to-market, as well as a more productive use of resources. However, design flow changes are risky. To manage this risk, we recommend requiring that new ideas or concepts work with the existing design flow (evolution, not revolution). In this article, we discuss how Model-Based Design can work with existing design processes to realize improvements in time-to-market, quality, and cost.
The Basic Concepts of Model-based Design
The core concept of Model-Based Design is using an executable system model as the basis for activities performed at four different stages in the design process (Figure 1). The same system model can function as an executable specification, a way to design the system, a basis for code generation, and a means of continuous test and verification. We focus on these four design stages in subsequent sections.

The same model in the same form should be used throughout the design process to avoid duplicating efforts at different design stages. To enable this, the design environment must be capable of multidomain simulation, allowing digital, analog, and RF components to be simulated in the same model. Such a requirement makes it hard, for example, for C/C++ models to fulfill our needs without building an RF simulation capability. Model-Based Design, therefore, requires the use of a commercial off-the-shelf (COTS) design and simulation platform such as Simulink. The core idea is the separation of the design and simulation environment from the model itself, which focuses development effort on the model and not the tool environment.
Stage 1: Executable Specifications
An executable specification is a system-level specification—essentially a system model—that is executed to produce results proving that the specification fulfills the requirements. For example, instead of stating on paper that the frame-error rate (FER) must be lower than some limit at a particular signal-to-noise ratio (SNR), we can build a specification (system model) that runs at the stated SNR, producing an FER less than the limit, thereby proving that the specification is achievable (Figure 2). The ITRS estimates that using an executable specification improves design productivity by of the order of 100 to 200%.

Because an executable specification is, by definition, executable, an engineer working with an executable specification can examine a far wider range of inputs and outputs and operating conditions than can be contained in a written specification. For example a broad range of channel models could be used. This flexibility results in a more complete behavioral specification and, because the specification is testable, an executable specification also uncovers errors much earlier in the design process.

Replacing or supplementing paper specifications with executable models is a fairly straightforward step; the real advantages of Model-Based Design, however, become apparent when models are used for several activities in the design process.
Stage 2: Designing with Simulation
Designers need to evaluate different design alternatives as quickly as possible. Changing the architecture of a system model based in C/C++ can be time consuming because of multiple recompilations and code changes. On the other hand, COTS platforms are typically graphically based so that models can be reconfigured without recompiling or changing component interfaces, so encouraging a component-based approach to design — something very beneficial for geographically dispersed design teams.

Many COTS platforms allow the same model to be used for both floating-point and fixed-point simulations, with the underlying platform providing the fixed-point engine. This capability alone

click to enlarge

Figure 2. An executable specification is an executable system model like the one shown here. An executable specification can be run to check that the simulation results are in line with those expected.
represents a tremendous productivity enhancement as designs no longer have to be rewritten in fixed-point. It enables the fixed-point performance of multiple designs to be evaluated, which is almost impossible in C/C++ based projects.

Perhaps the greatest benefit available to designers using Model-Based Design is the ability to examine cross-domain design trade-offs, where we study the impact of changing a component in one domain on the entire system. For example, we might want to look at the effects of using a cheaper analog power amplifier in conjunction with a digital predistortion filter. This system-level approach is difficult to do outside of Model-Based Design.

Because Model-Based Design has these productivity enhancing features, it enables more than one design to be explored, which increases the probability of selecting the best possible design.
Stage 3: Implementation
A significant strength of Model-Based Design is the fact that an executable specification or design can be used to generate implementation code. Although such code might not be as efficient in all cases as manually written code, it enables engineers to produce functioning prototypes without having to recode the system each time a design change is made. Furthermore, automatically generated code substantially reduces the risk of introducing coding errors compared to hand coding. Of course, automatically generated code can be used with hand coding to combine the strengths of both. The tradition in the wireless world to avoid automatic code generation because of performance concerns is being pushed aside as code generation technology improves and increased design complexity makes hand coding whole projects more challenging to accomplish.
Stage 4: Test and Verification
By raising the level of abstraction, Model-Based Design helps with the test and verification process. In fact, if an executable specification is used, the testing process can begin before the specification is even delivered. However, Model-Based Design also offers other advantages for verification.

Models are used extensively in industry as test harnesses for software, hardware, or processor-in-the-loop testing. Models can also be used to generate test vectors, even serving as the gold standard by which an implementation is compared.

Several test equipment manufacturers, for example Agilent, Anritsu, and LeCroy, have begun to benefit from Model-Based Design by incorporating design and simulation software into their equipment.
Model-Based Design and IP Reuse
Because wireless projects typically share many common design elements, the strategy of reusing intellectual property (IP) can play a significant role in boosting productivity and quality. IP sharing has been severely limited by two factors: the IP’s level of abstraction and how the IP will be shared. At the lowest level of abstraction—HDL code, for example—IP can be too specific to the targeted platform and project to be reused. IP sharing at higher abstraction levels (for example, sharing C/C++ code) is more appropriate, but is complicated by interface problems. For example, different C/C++ models can have different interfaces, which makes it difficult to share IP between different models. Even where common interfaces and design principles are mandated, there can still be difficulties due to different interpretations of the rules.

In order to share model components across projects, teams, and even companies, a common design and simulation platform is required. The use of a common platform will ensure that components developed for use in one model can be reused in another model. Model-Based Design explicitly encourages the use of a common platform throughout the design process, so enabling IP reuse.
Conclusions
Wireless system design is becoming increasingly difficult due to both technological and market forces, and existing design processes are showing the strain. Model-Based Design offers better quality, faster project delivery, and lower cost. These benefits can be introduced through a low-risk approach of using Model-Based Design initially for just one phase of a design, and then expanding its use in conjunction with existing design processes as value is demonstrated.

Table 1: Common design-process challenges

Key Design Challenges Reason for Failure
Multi-domain design and codesign Hardware, software, and RF design follow different development paths and it’s difficult to make and evaluate design decisions that cross domains.
Reducing repetitive work Some design flows require a floating-point system to be rewritten in a fixed-point format to be rewritten again for implementation on the target platform.
Reusing Intellectual Property (IP) between projects Different wireless projects often have common elements, yet there is often very little sharing of IP between projects due to the practical difficulties of sharing IP in different formats.
Exploring design alternatives Design flows provide little opportunity for exploring alternative designs as they postpone design evaluation to the implementation or testing stage when only one alternative can be evaluated due to cost and time considerations.
Reducing the cost of specification changes Because specifications are usually written documents, it is difficult to detect specification errors early in the process, when they are less expensive to correct. As a result, specification errors are often found late in the design cycle, when they are expensive to correct.
Finding errors early in the design process Design processes tend to push testing to late in the design cycle, where the cost of fixing bugs is much higher [4].

About the Author
Mike Woodward is the communications industry marketing manager at The MathWorks. He has been active in the communications industry for many years and has degrees in Physics and Semiconductor and Microwave Physics. Mike worked on the transmission infrastructure for the UK’s commercial DAB transmission network, a project that was awarded the British Computer Society’s IT Award for Excellence in 2000. He has also worked on audio processing and has several audio processing patents to his name.

Advertisement

Share this Story

X
You may login with either your assigned username or your e-mail address.
The password field is case sensitive.
Loading