System Design Flow and Fixed-point Arithmetic - Digital Design of Signal Processing Systems: A Practical Approach - page 86

because the algorithm designer has to explore digital communication techniques to meet them. The
specification lists OFDM to be used supporting BPSK, QPSKandQAMmodulations. The technique
caters for multipath effects and fast fading due to Doppler shifts as the transmitter and receiver are
expected to move very fast relative to each other. The communication system also supports different
FEC techniques at 512 kbps. Further to this the system needs to fulfill some special requirements.
Primarily these are to support frequency hopping and provide flexibility and programmability in the
computing platform for mapping additional waveforms. All these specifications pose stringent
computational requirements on the digital computing platform and at the same time require them to
be programmable; that is, to consist of GPP, DSP and FPGA technologies.
The purpose of including this example is not to entangle the reader's mind in the complexities of
a digital communication system. Rather, it highlights that a complete list of specifications is critical
upfront before initiating the design cycle of developing a signal processing system.
3.2.3 Coding Guidelines for High-level Behavioral Description
The algorithm designer should always write MATLAB code for easy translation into C/C þþ and
its subsequent HW/SW partitioning, where HW is implementation is in RTL Verilog and SW
components are mapped on DSP. Behavioral tools like MATLAB provide a good environment for
the algorithm designer to experiment with different algorithms without paying much attention to
implementation details. Sometimes this flexibility leads to a design that does not easily go down in
the design cycle. It is therefore critical to adhere to the guidelines while developing algorithms in
MATLAB . The code should be written in such a way that eases HW/SW partitioning and fixed-
point translation. The HW designer, SW developer and verification engineer should be able to
conveniently fall back to the original implementation in case of any disagreement. The following are
handy guidelines.
1. The code should be structured in distinct components defined as MATLAB functions with
defined interfaces in terms of input and output arguments and internal data storages. This helps in
making meaningful HW/SW partitioning decisions.
2. All variables and constants should be defined and packaged in data structures. All user-defined
configurations should preferably be packaged in one structure while system design constants are
placed in another structure. The internal states must be clearly defined as structure elements for
each block and initialized at the start of simulation.
3. The code must be designed for the processing of data in chunks. The code takes a predefined
block of data from an input FIFO (first-in/first-out) and produces a block of data at the output,
storing it in an output FIFO, mimicking the actual system where usually data from an analog-to-
digital converter is acquired in a FIFO or in a ping-pong buffer and then forwarded to HWunits
for processing. This is contrary to the normal tendency followed while coding applications in
MATLAB , where the entire data is read from a file for processing in one go. Each MATLAB
function in the application should process data in blocks. This way of processing data requires the
storing of intermediate states of the system, and these are used by the function to process the next
block of data.
An exampleMATLAB code that works on chunks of data for simple basebandmodulation is shown
below. The top-level module sets the user parameters and calls the initialization functions and main
modulation function. The processing is done on a chunk-by-chunk basis.