Newsletters - MATLAB Digest

Frame-Based Processing with
the DSP Blockset

by Anne Mascarin and Don Orofino

This article discusses the use of frame-based processing in block-diagram simulations of digital signal processing (DSP) systems. DSPs are microprocessors that excel at performing fast, repetitious calculations on discrete-time signals. Many DSPs support frame-based processing, and now, the DSP Blockset also supports it. The Simulink/DSP Blockset models (.mdl files) and audio files (.wav files) portrayed in the example are available download.

What is Frame-based Processing?
A frame is a collection of consecutive samples that have been stored in a single vector. If a mathematical formula, or algorithm, is frame-based, it can operate on several samples at once instead of on only one sample at a time. Frame-based processing can be compared to the greeting of guests at a party: As the doorbell rings, the hostess must open the door, welcome each guest, and serve them a drink. A lot of time is spent "servicing" each guest. This process would be more time-efficient (i.e., frame-based) if the hostess could greet, welcome, and serve several guests at once.

Whenever data needs to be read and written, additional"overhead" cycles (those that don't contribute to the algorithmic processing ) are incurred. For example, if one overhead cycle is required to read a sample and one overhead cycle is required to write a sample, a total of two overhead cycles is required per sample. Frame-based processing can help to keep an application running in real time because it minimizes the number of overhead cycles required to read the input data and write the output data. Consider a frame-based processing scenario in which the processor is capable of reading 10 input samples with one overhead cycle and writing 10 processed samples, also with one overhead cycle. Frame-based processing has saved 9 cycles!

Because it enables real-time processing, frame-based processing is crucial in many applications. For example, compliance with telephony standards often requires the use of frame-based processing. Telephonic and telecommunications equipment is manufactured by several different companies, yet equipment from company A is required to communicate with equipment manufactured by company B. Organizations such as the ITU (International Telecommunication Union) and the TIA (Telecommunications Industry Association) publish industry-wide standards to ensure interoperability. These standards consist of algorithms and specifications for their operation. Since many of the algorithms require frame-based processing of data, the algorithms running in equipment produced by manufacturers must be frame-based.

Not all real-time applications lend themselves to the use of frame-based processing. In some instances, the processor has to wait for the input device to buffer samples into a frame before it can process this frame. The algorithmic delay incurred by buffering is called "latency". Some applications that require data to be processed and sent out at a particular rate cannot accept latency.

Frame-Based Processing in DSP
DSPs were created specifically for algorithms that require intensive multiplications and additions (such as the Fast Fourier Transform, or FFT ). In fact, many of the architectural units on a DSP accommodate multiple samples by storing and processing them in an orderly fashion (for example, in circular buffers). DSPs can also perform several tasks within one clock cycle.

Frame-based processing can offer a path to modeling, simulating, and implementing modern real-time DSP algorithms. DSP algorithms generally require the multiplication and addition of many values in a short time. It is possible to have an algorithm execute faster by allowing the DSP to access frames of samples rather than one sample at a time.

Many applications of DSP and communications use frame-based processing because they need to operate in real time: the DSP must read input data, process it, and write processed results out before the next input data is ready. If the DSP does not do this, the application can "run out of real time". This indicates that the processor is not performing the read-process-write sequence fast enough. If a DSP application can't operate in real time, the output of the process has to be saved to a storage media and processed more slowly off-line. A failure like this can have serious consequences. For example, if DSPs couldn't process radar data in real time, evading missile attacks as they occur would be impossible.

An Example
Consider the real-time DSP Blockset model shown in Figure 1 (before running the simulation, please type load mtlb at the MATLAB command prompt). The input, a recorded digital speech file of a woman saying "MATLAB," is filtered through a low-pass FIR filter. The output of the filter is displayed in the time scope and written to a Windows audio device in real time.

Figure 1: A frame-based Simulink/DSP Blockset model.

This model is frame-based. To verify this, examine some blocks. Double-click on the "MATLAB" signal block. The value in the "Samples per Frame" field is 80, indicating a frame size of 80 samples per block output (note that a frame size of 1 indicates sample-based processing). Double-click on the Digital FIR Filter Design block - the checkbox for "Frame-Based Inputs" is checked. When the simulation is run, you can hear a version of the "MATLAB" audio file that sounds somewhat muffled due to the presence of the low-pass filter. The actual audio output (as a .wav file) of this model can be found in the file 80samp.wav and can be seen in the scope output block.

Figure 2: The scope display of the signal.

Let's experiment with the effects of running the signal out of real time. Reduce the frame size by changing the field for "Sample per frame" in the dialog box of the "MATLAB" audio block. A frame size of 7 will yield interesting results: in addition to the muffled word "MATLAB", you will hear clicks and pops. The actual audio output of this model can be found in 7samp.wav. The clicking occurs because the algorithm cannot keep up with the 8 kHz sample rate of the audio source (a digital to analog converter located on the sound card). The algorithm ran out of real time when we reduced the frame size from 80 to 7 samples per frame.

In summary, frame-based processing may accelerate your application if it can withstand the latency that may occur in both simulation and real-time processing.