A Review of Reconfigurability

Let’s review what we mean by reconfigurability. There are three ways to define reconfigurable
devices:
 Devices that are reconfigured by the vendor (often prior to shipment)
 Devices that can be reconfigured by a network
 Devices that can reconfigure themselves

Devices that are reconfigured by a vendor do not need to be connected to a network.
Devices that are reconfigured by a network or reconfigure themselves include RF:
infrared, copper, and optically connected devices. The design decisions to be made are
as follows:
 What percentage of a product can remain fixed (that is, supported by conventional
logic or an ASIC)?
 How much changeable overhead is required?
Bear in mind that reconfigurability has a price tag attached—the benefits have to
outweigh the additional cost. FPGAs can be applied in predelivery reconfigurability.
Effectively, FPGAs allow designers to compile C code, to produce algorithms and associated
floating-point and fixed-point arithmetic, to decide on hardware and software
partitioning, and then to produce hardware and to change their minds when the device
doesn’t work very well. Alternatively, if the marketing department decides mid-design
that the specification needs changing, the hardware can be changed, since FPGAs are
much more forgiving when it comes to finalizing gate-level hardware architectures.
FPGAs are also useful if you have a range of products at different prices that are
basically the same product but with certain features enabled or disabled—a Bluetooth
or GPS add-on, for example. Reconfiguration can be undertaken at any stage of the
production cycle or even at point of sale. Handsets with infrared connectors, for example,
can be reconfigured on the production line or, if staff are sufficiently well trained
and security issues are addressed, in a retail outlet.
The User Service Identity Module (USIM) in a 3G handset is an example. It can be
configured at point of sale or reconfigured at any future time, either back at the point
of purchase or remotely over the air. AUSIM reconfiguration is a change of software in
the device. Effectively, in FPGAs, we are applying the same principle to hardware
reconfiguration.
We can also define reconfigurability in terms of time scale, years, months, weeks,
days, hours, minutes, seconds, millisecond, microseconds. The shorter the time scale,
the higher the added value and (sometimes) the higher the performance value.
Static and dynamic rate matching in 3GPP1 is an example of reconfigurability. Here,
the implication is that the processing environment, and, possibly, related hardware
configuration, can change every 10 ms.
Present vendors of FPGAs are promoting their devices for use in Node B transceivers.
The devices are also propositioned for use in handsets, though it will be hard
to realize the required cost targets. On the Node B transmit side, FPGAs can be used to
realize the linear feedback registers (generating the long and short scrambling codes)
and are claimed to provide better silicon area utilization compared to programmable
logic devices. Similarly on the receive side, FPGAs can be used to realize the matched
filters for extracting the multiple-channel PN codes.
Sometimes, the theoretical benefits of FPGAs are hard to realize because of the need
to simultaneously process signals in the device. After all, there is not much advantage in
reconfigurability if jobs have to be done in parallel.
Figure 5.1, a block diagram from Altera, provides an example of possible partitioning
in a Node B design. The chip rate despreading is, at present, a hardware-intensive
process, as is the multiuser detection and combining. Essentially, all chip rate processors are currently hardware-based. The more complex symbol level processing tasks, such
as turbo decoding, are hardware-based. The similar symbol-level tasks, such as deinterleaving,
Viterbi convolutional decoding, and block decoding, and bit-level tasks,
such as source coding, can be implemented in software on a DSP. Hardware tasks are
therefore a candidate for FPGAs. FPGAs are used presently in Node B designs because
there is still some fluidity in the standards-making process. Designers still tend to
migrate toward ASICs to get maximum hardware performance out of a device, along
with lowest per-unit cost. The cost of an ASIC, of course, is the lack of flexibility.
The idea of remote hardware reconfiguration seems attractive in theory but can be
quite tricky in practice. An incorrect reconfiguration bit stream could physically damage
millions of subscriber handsets, and the damage could be irreversible. Such damage
could either be the result of incompetence or malicious intent. To protect against
malicious intent, it is necessary to authenticate reconfiguration bit streams and to
authenticate devices to which the reconfiguration bit stream is addressed.
The issues are not dissimilar to remote software upgrades—either way, it is always
rather nerve-racking to have the potential of physically damaging millions of subscriber
products all at once! There are various standards groups working on the security
issues of remote reconfiguration, including the Internet Reconfigurable Logic
Group supported by Xilinx and Altera.
As we said earlier, FPGAs in Node B designs have a number of well-defined benefits.
The use of FPGAs in a handset will be harder to justify.
Figure 5.2 shows how the DSP in a 2G cellular handset does more or less all of the
bit-level/symbol-level processing, as well as quite a lot of preprocessing for the RF
stages of the device. This was not always the case. In 1992, about the only task the DSP
was capable of realizing was the speech encoder/decoder. Between 1992 and 1997, the
DSP gradually took over other jobs like convolutional encoding/decoding and channel
equalization. The microcontroller looked after higher-level protocol tasks and the
man/machine interface. By the end of the 1990s, more or less the whole baseband was
being done on (largely TI!) DSPs.

Present GPRS handsets are similar in that the DSP is completely dominant in the
baseband area, as shown in Figure 5.3. Additionally, tasks such as image processing
and MPEG-4 encoding/decoding are typically divided between the DSP and microcontroller.
The DSP does repetitive signal processing tasks, such as Fast Fourier Transform
(FFT) transitions, and the microcontroller looks after housekeeping tasks, such as
organizing memory fetch processes, interrupts, and parallel multitasking. These are all
the rather unpredictable tasks for which DSPs are not well suited.
In a 3G handset, early designs are back to the DSP only doing about 10 percent of the
baseband processing. In their book The Application of Programmable DSPs in Mobile Communications
(Wiley, ISBN 0-471-48643-4) Alan Gatherer and Edgar Auslander provide a
well-reasoned argument as to how and why the DSP will repeat its 1990s trick of gradually
taking over all other baseband processing in the handset, including, in the longer
term, chip rate processing (OVSF spreading/despreading).
Presently, however, tricky jobs like the turbo coder/decoder have to be realized
using flexible or reconfigurable coprocessors—hardware accelerators running beside
the DSP. This adds cost and complexity. The need to manage a number of simultaneous
processing tasks, which are very real-time dependent—for example, the processing of
time-sensitive, time-interdependent multiple OVSF code streams—has meant that
DSPs have to have their own real-time operating system, which, hopefully, will communicate
with the microcontroller RTOS.
It is worth noting that the majority of the sources being coded (audio and video) are
analog. Also, of course, the RF carrier is analog (a sinusoidal waveform onto which we
superimpose analog phase and amplitude signals).
This has led to proposals to produce an analog DSP. An example is from Toumaz
(www.toumaz.com) and is a proposed analog implementation of an FFT using bandpass
filters.

In the meantime, we are left with heavy-lifting DSP solutions for baseband coding/
encoding. As coding overheads increase and user data rates increase, processor
efficiency becomes increasingly critical. By its very nature 3G is a wide dynamic range,
slow-to-fast data rate, multifunction (voice, text, video), multiuser cellular system.
This requires optimized low-power, flexible digital-processing capability.
DSPs can provide low-power (relatively), software-adjustable digital processing
capability. However, DSP architectures are fixed. There is no capability to modify the
interconnects between function units. Under each processing requirement a number of
functions will remain unused—a measure of inefficiency. Anumber of vendors attempt
to address this problem with Reconfigurable Communication Processors (RCP).
The vendors, such as Chameleon, Siroyan, Elixent, PicoChip, Prairie, MIPS Technologies,
and ARC, are propositioning more efficient DSP core architectures.
Approaches include a number of different methods to take advantage of parallelism
and pipelining in the algorithm. For example, Chameleon has a three-core architecture
where the first core is an embedded processor subsystem, the second core is a 32-bit
reconfigurable processor with 108 parallel computation units, and the third core is a
programmable I/O (PIO) with a 1.6-Gbps bandwidth. Elixent has a large array of simple
arithmetic logic units (ALUs) with distributed memory and local/global interconnects.
These are arranged in a chessboard array of tiles. Each tile takes on the
responsibility for particular logic functions as demand requires.
Siroyan concentrates on optimizing compiler efficiency and then matching the DSP
architecture to the compiler. (Normally you optimize the compiler architecture to the

DSP.) Siroyan’s approach is to get the software right first, and then design the hardware
around it. In doing so, the hardware ends up being a more scalable distributed
DSP optimized for simultaneous parallel processing.
These parallel processing/distributed processing DSP architectures are well suited
to image processing: They can be optimized for processing multiple variable-width
data streams onto multiple variable-rate physical radio channels (OVSF code channels).
Because they move across a complex radio layer into a complex transport layer,
they are well suited to preserving the properties of multiple data streams.
Another option is an optical DSP (ODSPE). Optical DSPs promise substantial gains
in processor speed and efficiency. An example is Lenslet’s EnLight ODSPE product
family (www.lenslet.com).
For the moment, electronics will have to do, and we just need to find ways of efficiently
using them.