Martin Clark, Mike Mulligan, Colin Warwick, The MathWorks, Inc.
A multi-domain executable model provides a practical method of global optimization of signal processing and communications systems.
Global optimization of the design of a wireless communication system requires exploration of a multi-domain design space encompassing signal processing and communications algorithms and RF subsystem design. An example of a single domain task is optimizing the gain distribution among the RF subcircuits, such as LNA,

click to enlarge

Figure 1. IEEE 802.11a WLAN Model.
mixer, IF amplifier in an RF receiver. A more difficult task is optimization across domain boundaries.

Typical questions the team asks might be "Can we invest in a signal processing algorithm that will enable us to use lower cost RF components, and enjoy a net saving for the same overall performance?" or, more specifically, "For a given link budget should we invest in processing power for increasingly sophisticated signal processing algorithms (such as soft-decision and advanced equalizers), or in wider words lengths to minimize quantization noise in fixed-point algorithms such as the FFT in the ODFM receiver, or in more expensive, lower noise RF components?" It is impractical to connect and co-simulate these domains in instruction set simulators for the DSP and microcontroller, an HDL simulator for the digital hardware, and an analog circuit simulator for the RF circuits. And building several prototypes is prohibitively expensive. This article will use as an example a trade-off between RF receiver phase noise and receiver algorithm path bit width in Mode 5 of the physical layer of the IEEE 802.11a Wi-Fi wireless LAN. We will show how a multi-domain simulator can be used to explore the design space and reach the optimum trade-off.
Description of the Development Flow
We assume a development flow using Model-Based Design where a system model is at the center of the development process — from requirements capture and design to implementation and testing. In this example, the primary functional and performance requirements derive from the IEEE 802.11a standard. At the start of the design process a system engineer transforms the written standard into a model that serves as an executable specification and is continually refined throughout the development process.

As the design proceeds, the overall system requirements place constraints on the design of various elements, such as the RF and baseband signal processing receiver subsystems. In a traditional paper-based design process, this requires a translation of requirements and production of separate specifications for the various subsystems.

click to enlarge

Figure 2. Custom Graphics.
Once the design is partitioned in this way it is unlikely that there will be much optimization of the design across these subsystems.

Using Model-Based Design, the executable model can be elaborated to encompass the design of the various subsystems in a single common specification, allowing the system engineer to negotiate trade-offs between such disparate yet highly interrelated elements as fixed-point signal processing and analog RF circuitry. The goal of this process is both improved development efficiency and product quality.
Description of the Executable Model
The model shown in Figure 1 represents an end-to-end baseband model of the physical layer of a wireless local area network (WLAN) according to the IEEE 802.11a standard. It was built using hierarchical block diagram simulation and modeling tools from the Simulink® product family.

The model supports all mandatory and optional data rates: 6, 9, 12, 18, 24, 36, 48 and 54 Mb/s, and also illustrates adaptive modulation and coding over a dispersive

click to enlarge

Figure 3. BER Curves for all 8 modes.
multipath fading channel. The model makes extensive use of graphical displays because the purpose of modeling is insight, not numbers. An example of these graphical displays is shown in Figure 2.

The transmitter illustrates the complexity of this system. It includes: •Generation of random data at the bit rate specified in the standard for each mode (varies according to the channel conditions); •Convolutional coding and puncturing using code rates of , and ; •Data interleaving; •Adaptive BPSK, QPSK, 16-QAM, and 64-QAM modulation; •OFDM (orthogonal frequency division multiplexing) transmission using 52 subcarriers, 4 pilots, 64-point FFTs, and a 16-sample cyclic prefix.

There is active interest in adapting this type of standard, which was originally designed for use in a fixed or slowly varying channel environment, as a candidate for 4G mobile communications. The dispersive multipath fading channel in this model allows us to explore this potential application by adjusting the fading characteristics.

The model includes both RF behavioral models for various receiver components as well as a fixed-point implementation of the receiver’s baseband signal processing

click to enlarge
Figure 4. Mode 5 Fixed-Point BER Curves.
algorithms from the ADC through the FFT and equalizer to the demodulator and Viterbi decoder. This level of elaboration represents a step beyond the initial translation of the standard into an executable specification. At this point in Model-based Design, the model allows the system engineer to explore important trade-offs without the need for hardware prototypes.
Design Optimization
The model was first configured to simulate the end-to-end link with a floating point receiver implementation and no phase noise. As illustrated by Figure 3, these simulations establish the “ideal” bit error rate performance for all eight modes, covering the various combinations of modulation and coding in the IEEE 802.11a standard. In the remainder of this article, we will focus on Mode 5, which supports 24 Mb/s with a combination of 16-QAM modulation and rate convolutional coding.

The next step is to simulate the model with various fixed-point settings for the receiver’s baseband signal processing algorithms. Because this is still early in the design stage, we do not try to completely optimize the fixed-point design, but simply adjust the fixed-point bit width. (The fractional part is chosen relative to the overall bit width.) Using

click to enlarge

Figure 5. Mode 5 Phase Noise BER Curves.
a bit error rate of 1e-5 for comparison, we see that the golden reference (double precision) SNR from Figure 3 is 10.3 dB. Figure 4 shows that our fixed-point implementations of 14, 12 and 10 bits wide exhibit degradations of 0.2, 0.4 and 1.6 dB, respectively.

Figure 5 shows similar curves, but this time with various phase noise impairments (and in all cases double precision receiver algorithms). These four curves indicate the BER results for -77, -75, -73, and -71 dBc/Hz of phase noise (at 10 kHz offset). For these cases, the SNR values that produce 1e-5 BER are 0.25, 0.45, 0.75 and 1.15 dB less favorable than the reference value.

We next run the model with various combinations of phase noise and receiver algorithm bit widths. Note that simulating multiple domains at the behavioral level is more efficient than alternative methods. For example, attempting to join detailed digital and analog circuit-level simulators to detailed instruction set simulators would be prohibitively slow. Figure 6 shows the summary of the results.
Implementation Loss Contours
Each point on the contour plot represents on intersection of the BER versus SNR curve with the 1e-5 BER line. In addition, each point represents a combination of

click to enlarge

Figure 6. Fixed-Point vs. Phase Noise Implementation Loss Contours.
impairments resulting from both finite word length effects and some level of phase noise. This contour plot can be used by the system architect and the whole design team to answer multi-domain design trade offs.

As an example, let us consider a situation where the maximum implementation loss (i.e. link margin erosion due to the two implementation impairments under consideration here) is fixed by product requirements at, say, 2 dB. We can read off the various impairment budget pairs that will yield this maximum allowed value. These are shown in Table 1.

However, being conservative, the team decides to build a prototype with more expensive components such that the implementation loss is limited to 1 dB. The choices are shown in Table 2.

Knowing the cost of components (e.g. cost versus quality of local oscillators, and cost of silicon area for the receiver algorithm versus path bit width) enables the team to build the prototype with components that are close to production quality. This type of prototype is more useful than a "gold-plated" prototype that is guaranteed to work, but is far removed from the final product in terms of cost.

The next stage at which multi-domain simulation is valuable is when the prototype is built and working according to plan, (i.e. the implementation loss is close to 1dB) but must be cost reduced. The team can now return to Table 2, and use this to guide decisions about what impact various cost reduction strategies will have on the implementation loss: they can relax the phase noise spec, narrow the receiver algorithm path bit width, or some combination of both.

So far the phase noise model has been a behavioral one. We can refine the model with blocks that allow verification of real world RF data and confirm the trade-offs being

click to enlarge

Table 1.2 (top) dB Implementation Loss Options
Table 2.1 (bottom) dB Implementation Loss Options
made reflect the actual characteristics of the RF components under consideration. These characteristics can be obtained from measured data or from detailed circuit-level simulators, and can be expressed in terms of tabular data of network parameters, thermal noise, phase noise, and nonlinearity (e.g. power out and phase versus power in and frequency). This aspect of Model-Based Design, the ability to continuously verify the implementation throughout the design process, further contributes to improved development efficiency and product quality.
A multi-domain executable model at the center of the development process affords a practical method of global optimization of signal processing and communication systems. You can explore the design space, which encompasses signal processing and communications algorithms and RF subsystem design.

About the Authors
Martin Clark manages a team that works with companies to facilitate adoption of Model-Based Design. Mike Mulligan is a software development manager for Design Automation Tools. Colin Warwick is a product manager focused on the verification of digital, RF, analog and mixed-signal designs and implementations in the context of Model-based Design for signal processing and communications applications.