MATLAB Digest - November 2003
The Benefits of Model-Based Design for Multirate Systems |
|
The invention of turbo codes by Claude Berrou and Alain Glavieux1 revolutionized the field of error control coding, yet initially the inventors were trying to solve a very different problem. As VLSI designers, they were concerned with simplifying the design of integrated circuits. In their own words:“ The idea of so-called parallel concatenation did not germinate by analogy with product codes. More trivially, we were seeking to simplify the clock distribution in our envisaged high-data-rate integrated circuit, because classical (serial) concatenation requires different clocks to be generated.”2 In many cases, the system designers who choose the error control coding approach give little thought to the challenges faced by the circuit designers who implement the system and vice versa. Yet this historical anecdote illustrates how important it can be to consider implementation issues early in the design cycle.
In this article we explore the use of model based design in the development of a multirate system similar to the one that challenged Berrou and Glavieux. By creating models with Simulink at the earliest stage of the design process it is possible not only to predict the performance of a system through analysis and simulation, but you can also examine trade-offs that affect the implementation of the system. The combination of the multi-rate discrete-time simulation support built into Simulink with the frame-based processing of the DSP Blockset and Communications Blockset creates a flexible design environment that allows you to accurately model your system and ensure a successful design.
Multiple Synchronized Clocks
For high data rate applications, timing is always a critical implementation
issue. On a typical chip, clocks are used to control the sequencing of
millions of operations every second. If there is only one clock, then the
designer’s primary concern is clock distribution – making sure
that the “ticks and tocks” are heard at precisely the same
moment everywhere on the chip. However, many systems require multiple synchronized
clocks, each one ticking away at a different rate, with all of them ticking
together at regular intervals. Merely generating these clocks can be a
challenge, especially when their rates are not multiples of one another.
Multiple clocks also aggravate the clock distribution problem, so if there
is a way to minimize the number of clocks, the system designer should look
for it.
The most straightforward method of generating multiple synchronized clocks is based on the mathematical operations of finding the greatest common divisor (GCD) and simple counting. As an example, to generate two clocks, one that ticks every nine seconds and one that ticks every twelve seconds, the first step is to compute the GCD of nine and twelve. Since the result is three, a master clock must tick every three seconds. Then from this master clock, the first clock is generated by counting to three and the second clock is generated by counting to four.
In theory this technique can be applied to generating an arbitrary number of clocks, but in practice problems can arise. For example, if the computed GCD of the set of clock periods is much smaller than each of the required clock periods, then the master clock must tick at a very fast rate and the derived clocks require large counters. In most cases, the clock periods are established by a standard and are thus design constraints. The designer cannot change the required clock periods and so must look elsewhere for the flexibility to create an efficient design.
Digital Video Broadcasting
Let’s explore some of these timing issues further and consider how
to incorporate them into a model based design. For our example we will use
the concatenated coding specified by the Digital Video Broadcasting (DVB)
system3. DVB is the European standard for a variety of high definition
digital television broadcasts: over the air, over a cable, or through a satellite.
To ensure the quality of the received DVB signal, the transmitter performs
a sequence of baseband signal processing steps: Reed-Solomon coding, interleaving,
punctured convolutional coding, two more stages of interleaving, modulation,
and finally Orthogonal Frequency-Division Multiplex (OFDM) transmission.
Some of these steps have several options, as shown in the table below:
| Outer coder | (204,188) byte Reed-Solomon code |
| Outer interleaver | 12x17 convolutional interleaver |
| Inner coder | rate 1/2, 2/3, 3/4, 5/6, or 7/8 convolutional code |
| Inner bit interleaver | 126 bit block interleaver |
| Inner symbol interleaver | 1512 (2k mode) or 6048 (8k mode) symbol block interleaver |
| Modulator | QPSK, 16QAM, or 64QAM |
| OFDM transmitter | insertion of pilot tones and transmission parameter signalling |
To keep the example simple, let us consider a single operating mode by choosing the rate 3/4 code, with 1512 carriers per OFDM symbol, and one 64-QAM signal carrying six bits of information on each carrier. We will focus on the coding and interleaving, contrasting the implementation complexity of three design options. Even with this limited example, we will see that the code rates and block sizes place difficult constraints on the problem.
Design Option #1
Let us first consider the approach that Berrou and Glavieux sought to avoid:
the use of multiple clocks. The Simulink model shown in Figure 1 illustrates
this approach using the “sample time colors” feature. Each
color indicates a different sample time or clock rate. Blocks such as encoders
that change the rate of the signal have different colors on the input and
output. Each signal corresponds to one sample, in this case either a bit
or a byte of information. The only signal rate that is explicitly set is
that of the source: all other rates are automatically derived from it.
Figure 1: Multirate Sample-Based Model
Click on image to see enlarged view.
The DVB standard calls for an OFDM symbol time of 224µs. With 9072
bits of information in each OFDM symbol, this translates to a channel bit
period of ~24.7ns, indicated by the red signal lines in the diagram. Similar
calculations yield the remaining (approximate) signal periods: 32.9ns(green),
263.4ns(olive), 285.8ns (orange), and 35.7ns (blue). To generate all these
clocks as multiples of a single master clock, the period of the master clock
(T) would need to be T 
175.1ps.
The periods of the five clocks required by this design are then:
| red | 141 T |
| green | 188 T |
| olive | 1508 T |
| orange | 1632 T |
| blue | 204 T |
Expressed as multiples of this fundamental period, the relationships between the sample times can be more easily deduced. The green is 4/3 times the red, due to the convolutional coding. Similarly, the olive is eight times the green, reflecting the conversion between bits and bytes. The orange is 204/188 times the olive due to the Reed-Solomon coding. Finally, the blue is one eighth of the orange, again indicating a conversion between bits and bytes. Note that the GCD of the five integers in this table is 1, as expected.
In this example, which represents only one mode of the DVB system, the master clock is at least two orders of magnitude faster than each of the five synchronized clocks. This is a typical example of a concatenated coding design: no wonder Berrou and Glavieux were looking for an alternative approach. Short of inventing a revolutionary new technology such as turbo codes, are there alternatives for managing the complexity of this design? Specifically, is there a way to reduce the number of synchronized clocks that are required?
One alternative way to implement rate changes is to use frames of data and adjust the sizes of the input and output frames to reflect the multirate behavior of operations such as coding. In this approach, the input and output clocks are the same and in theory the whole system could be synchronized with a single clock! The key is to find the right frame sizes so that at each step there is an integer number of frames to be processed.
Continued
