Analog Integr Circ Sig Process (2011) 69:119–129
DOI 10.1007/s10470-011-9765-8
Implementation of sphere decoder for MIMO-OFDM on FPGAs
using high-level synthesis tools
Juanjo Noguera • Stephen Neuendorffer •
Sven Van Haastregt • Jesus Barba •
Kees Vissers • Chris Dick
Received: 14 February 2011 / Revised: 6 July 2011 / Accepted: 16 August 2011 / Published online: 23 September 2011
Ó Springer Science+Business Media, LLC 2011
Abstract In this study we explain the implementation of a
sphere detector for spatial multiplexing in broadband wire-
less systems using high-level synthesis (HLS) tools. These
modern FPGA design tools accept C/C?? descriptions as
input specifications, and automatically generate a register
transfer level (RTL) description for FPGA implementation
using traditional FPGA implementation tools. We have used
AutoESL’s AutoPilot HLS tool to implement this demand-
ing algorithm on a Virtex-5 running at a clock frequency of
225 MHz. The obtained results show that these modern HLS
tools produce Quality of Results competitive to the ones
obtained using a traditional RTL design approach, while
significantly abstracting the designer from the low-level
FPGA implementation details.
Keywords Sphere decoding  High level synthesis 
FPGAs
1 Introduction
Spatial division multiplexing MIMO (Multiple Input and
Multiple Output) processing significantly increases the
J. Noguera (&)
Xilinx Ireland, Dublin, Ireland
e-mail: juanjo.noguera@xilinx.com
S. Neuendorffer  K. Vissers  C. Dick
Xilinx, Inc, San Jose, CA, USA
S. Van Haastregt
Leiden University, Leiden, The Netherlands
J. Barba
University of Castilla-La Mancha, Ciudad Real, Spain
spectral efficiency, and hence capacity, of a wireless
communication system: it is a core component of next
generation wireless systems, for example, WiMAX
(Worldwide Interoperability for Microwave Access) and
other OFDM-based wireless communication standards.
Spatial multiplexing MIMO processing is a computation-
ally intensive application that implements highly
demanding signal processing algorithms. A specific
example of spatial multiplexing in MIMO systems is
sphere decoding, which is a complexity-efficient method to
solve the MIMO detection problem, while maintaining a
bit-error rate (BER) performance comparable to the opti-
mal maximum-likelihood (ML) detection algorithm.
However, even this reduced complexity algorithm is gen-
erally not feasible to implement on a digital signal pro-
cessor (DSP) in real-time.
Field programmable gate arrays (FPGAs) are an attrac-
tive target platform for the implementation of complex
DSP-intensive algorithms, like the sphere decoder (SD).
Modern FPGAs are high-performance parallel computing
platforms that provide the high-performance of dedicated
hardware solutions, while keeping the flexibility of pro-
grammable DSP processors. There are several studies
showing that FPGAs could achieve 1009 higher perfor-
mance and 309 better cost/performance than traditional
DSP processors in a number of signal-processing applica-
tions [1].
Despite this tremendous performance advantage,
FPGAs are not generally used in wireless signal pro-
cessing since they are perceived as devices difficult to use
for traditional DSP programmers. The key barrier for the
widespread adoption of FPGAs in wireless applications is
the traditional hardware-centric design-flow and tools.
Currently, the use of FPGAs requires significant hardware
design experience, like for example, being familiar in
123
120
using hardware description languages (e.g., VHDL,
Verilog).
Recently, new high-level synthesis (HLS) tools [2] have
become available as design tools for FPGAs. These design
tools take as input a high-level algorithm description and
generate RTL that can be used with standard FPGA
implementation tools (e.g., Xilinx ISE/EDK). These tools
offer an increase in the design productivity and reduction
of the development time, while producing good quality of
results [3]. This study describes the FPGA implementation
of a complex wireless algorithm on a modern FPGA (i.e.,
sphere detector for spatial multiplexing MIMO in 802.16e
systems) using HLS tools. We have used AutoESL’s
AutoPilot HLS tool to target a Xilinx Virtex-5 running at
225 MHz. We present a comprehensive study reporting on
our experiences in using HLS tools for this particular
wireless algorithm and compare the results to an imple-
mentation generated using on a traditional FPGA hard-
ware-centric design approach.
2 Related work
WiMAX, based on the IEEE 802.16e-2005 standard, refers
to a new generation of (mobile) wireless broadband access
networks. WiMAX supports multiple input and multiple
output antenna configurations, meaning that both the
transmitter and the receiver use multiple antennas to
increase bandwidth efficiency and link reliability. Decod-
ing the data from the different antennas using a maximum
likelihood (ML) detector yields the optimal bit error rate
(BER) performance. However, a ML detector implemen-
tation grows exponentially with the number of antennas
and the choice of modulation scheme, making it cost-pro-
hibitive for high-data rate systems with large numbers of
antennas. Alternatively, channel decoding can be realized
using a SD, whose implementation is less expensive while
still achieving a BER performance comparable to that of an
ML detector [4]. Hence, in this paper we focus on a SD.
Most of the existing literature on SDs focuses on the
architecture of the SD. For example, in [5] the authors
described different designs optimized for implementation
on an FPGA. In [6], a VLSI architecture for the K-best
MIMO detector algorithm was presented and implemented
on both FPGA and ASIC technology. A multi-core archi-
tecture for a 16 9 16 antenna configuration was presented
in [7] whereas we use a 4 9 4 configuration in this study.
An implementation of a Layered ORthogonal Lattice
Detector (LORD) for a 2 9 2 configuration was presented
in [8]. Although the LORD algorithm follows a different
approach to the one implemented in sphere detectors,
comparisons are valuable. In principle, the LORD algo-
rithm is more suitable for hardware implementations due to
123
Analog Integr Circ Sig Process (2011) 69:119–129
opportunities for parallization that it offers. However, the
implementation in [8] provides ML error performance for
the 2 9 2 implementation but demanding a considerable
amount of resources when compared to a 4 9 4 SD. The
work of [9] showed that the optimal channel ordering not
only depends on the channel matrix, but also on the
received points. In this study, we do not take this into
account however.
Instead of focusing primarily on the application archi-
tecture, we focus in this paper on the design method used to
implement SD application blocks. Both the work of [10] and
the particular implementation [11] on which our work is
based were specified in MATLAB and subsequently imple-
mented using Xilinx’ System Generator for DSP. Instead, we
have taken the MATLAB reference implementation, con-
verted it in a literal fashion to C?? code and worked to
optimize the implementation through the HLS tool flow.
Similar approaches were followed in [12–14] for algorithms
that had lower complexity or lower throughput requirements.
In [12], the PICO high level synthesis tool was employed to
implement image processing kernels. In [13], the Catapult-C
high level synthesis tool was employed to implement a
64-QAM decoder in both FPGA and ASIC technology. In
[14], the Impulse C tool suite was employed to implement a
computed tomography back-projection algorithm. The
independent BDTI HLS tool certification program [3] has
been set up to evaluate HLS tools for FPGA design. As of
mid-2010, both the PICO and AutoPilot HLS tools have been
certified by this program.
3 Sphere decoder
Sphere detection is a prominent method of simplifying the
detection complexity in spatial multiplexing systems while
maintaining BER performance comparable with optimum
ML detection. The block diagram of the MIMO 802.16e
wireless receiver is shown in the Fig. 1. It is assumed that the
channel matrix is perfectly known to the receiver which can
be accomplished by classical means of channel estimation.
After channel reordering and QR decomposition, the
sphere detector (SD) is applied. In preparation for engaging
a soft-input-soft-output channel decoder (e.g. Turbo deco-
der), soft outputs are produced by computing the log-
likelihood ratio (LLR) of the detected bits. A detailed
explanation of this algorithm can be found in [9]. Fol-
lowing we briefly introduce the key three building blocks
in this algorithm.
3.1 Channel matrix reordering
The order in which the antennas are processed by the
sphere detector has a profound impact on the BER
Analog Integr Circ Sig Process (2011) 69:119–129
Fig. 1 Block diagram for
sphere decoder
performance. So prior to sphere detection, channel reor-
dering is applied. By utilizing a channel matrix pre-pro-
cessor, that realizes a type of successive interference
cancellation similar in concept to that employed in BLAST
(Bell Labs Layered Space Time) processing, the detector
achieves close to ML performance.
The method implemented by the channel reordering
determines the optimum detection order of columns of the
complex channel matrix over several iterations. Depending
on the iteration count, the row with the maximum or
minimum norm is selected. The row with the minimum
Euclidian norm represents the influence of the strongest
antenna while the row with the maximum Euclidian norm
represents the influence of the weakest antenna. The novel
approach first processes the weakest stream. All subsequent
iterations process the streams from highest to lowest
power.
To meet the high data rate requirements, the cannel
ordering block is realized using the pipelined architecture
shown in Fig. 2, which processes 5 channels in a time
division multiplexing (TDM) approach. This approach
provides more processing time between the matrix ele-
ments of the same channel while sustaining high data
throughput. The calculation of the matrix inverse is the
most demanding process in Fig. 2 which is realized using
Fig. 2 Iterative channel matrix
reordering algorithm
121
QR decomposition (QRD). A common method for realiz-
ing QRD is based on Givens Rotations. The proposed
implementation performs the complex rotations in the
Diagonal and OffDiagonal cells, which are the funda-
mental computations units in the systolic array we are
using. After QRD and prior to the reordering operations,
back substitution of the decomposed matrix is done.
3.2 Modified real-valued QR decomposition
After obtaining the optimal ordering of the channel matrix
columns, the QR decomposition on the real-valued matrix
coefficients is applied. The functional unit used for this
QRD processing is similar to the QRD engine designed to
compute the inverse matrix, but with some modifications.
The input data in this case are real valued and the systolic
array structure has a correspondingly higher degree. In
order to meet the desired timing constraints the input data
consumption rate had to be 1 input sample per clock
cycle. This introduced challenges around processing
latency problems which could not be addressed with a
5-channel TDM structure. The number of channels in a
TDM group was increased to 15 to provide more time
between the successive elements of the same channel
matrix.
123
122
3.3 Sphere detector (SD)
The iterative sphere detection algorithm can be viewed as a
tree traversal with each level of the tree i corresponding to
processing symbols from the ith antenna. The tree traversal
can be performed using several different methods. In our
implementation we selected a breadth-first search due to
the attractive hardware-friendly nature of the approach. At
each level only the K nodes with the smallest partial
Euclidian distance (Ti) are chosen for expansion. This type
of detector is called a K-best detector.
The norm computation is done in the partial euclidean
distance (PED) blocks of the sphere detector. Depending
on the level of the tree, three different PED blocks are
used: the root node PED block calculates all possible PEDs
(tree level index is i = M = 8). The second level PED
block computes 8 possible PEDs for each of the 8 survivor
paths generated in the previous level. This will give us 64
generated PEDs for the tree level index i = 7. The third
type of PED block is used for all other tree levels which
compute the closest-node PED for all PEDs computed on
the previous level. This will fix the number of branches on
each level to K = 64, thus propagating to the last level
i = 1 and producing 64 final PEDs along with their
detected symbol sequences.
The pipeline architecture of the SD allows data pro-
cessing on every clock cycle, thus the number of PED
blocks necessary at every tree level is only one. The total
number of PED units is equal to the number of tree levels,
which for 494 64-QAM, is 8. The block diagram of the SD
is illustrated in the Fig. 3.
3.4 FPGA performance implementation targets
The target FPGA device is a Xilinx Virtex-5 FPGA, with a
target clock frequency of 225 MHz. The channel matrix is
estimated for every data subcarrier which limits the
available processing time for every channel matrix. For the
selected clock frequency and a communication bandwidth
of 5 MHz (corresponding to 360 data sub-carriers in a
WiMAX system), the available number of processing clock
cycles per channel matrix interval is calculated as follows:
Fig. 3 Sphere detector
processing pipeline
123
Analog Integr Circ Sig Process (2011) 69:119–129
ð102:9us=360Þ
num cycles ¼ ffi 64: ð1Þ
1=225MHz
As mentioned earlier, the most computationally
demanding configuration with 4 9 4 antennas and 64-QAM
modulation scheme has been designed. The achievable raw
data rate in this case is 83.965 Mbps.
4 High-level synthesis for FPGA
High-level synthesis tools take as their input a high-level
description of the specific algorithm to implement and
generate the RTL description of FPGA implementation.
Modern HLS tools accept untimed C/C?? descriptions
as input specifications. These tools give two interpretations
to the same C/C?? code: (1) sequential semantics for
input/output behavior; and (2) architecture specification
based on C/C?? code and compiler directives. Based on
the C/C?? code, compiler directives and target throughput
requirements, these HLS tools generate high-performance
pipelined architectures. Among other features, HLS tools
enable automatic pipeline stages insertion and resource
sharing to reduce FPGA resource utilization. In summary,
HLS tools raise the level of abstraction for FPGA design,
and make transparent the time-consuming and error-prone
RTL design tasks. We have focused on using C??
descriptions, with the goal of leveraging C?? template
classes to represent arbitrary precision integer types and
template functions to represent parameterized blocks in the
architecture.
The overall design approach is shown in Fig. 4, where
the starting point is a reference C/C?? code that could
have been derived from a MATLAB functional description.
As illustrated in this figure, the first step in implementing
an application on any hardware target is often to restructure
the reference C/C?? code. By ‘‘restructuring,’’ we mean
rewriting the initial C code (which is typically coded for
clarity and ease of conceptual understanding rather than for
optimized performance) into a format more suitable for the
target processing engine. For example, on a DSP it may be
required to rearrange an application’s code so that the
Analog Integr Circ Sig Process (2011) 69:119–129
Fig. 4 High-level synthesis for FPGAs
Fig. 5 Iterative C/C?? refinement design approach
algorithm makes an efficient use of the cache memories.
When targeting FPGAs, this code restructuring might
involve, for example, rewriting the code so it represents an
architecture specification that can achieve the desired
throughput, or rewriting the code to make efficient use of
the specific FPGA features like embedded DSP macros.
The functional verification of this implementation
C/C?? code is achieved using traditional C/C?? com-
pilers (e.g., gcc) and reusing C/C?? level testbenches
developed for the verification of the reference C/C??
code. The C/C?? code implementation is the main input
to the HLS tools. However, there are additional inputs to
the HLS tools that significantly influence the generated
hardware, its performance and number of FPGA resources
123
used. Two essential constraints are the target FPGA family
(i.e., technology) and the target clock frequency, which
obviously have an effect on the number of pipeline stages
in the generated architecture. Additionally, HLS tools
accept compiler directives (e.g., pragmas inserted in the
C/C?? code) which can be applied to different sections of
the C/C?? code. There are different types of directives;
for example, there are directives that are applied to loops
(e.g., loop unrolling), while other directives can be applied
to arrays (e.g., to specify which FPGA resource must be
used to the implementation of the array).
Based on all these inputs, the HLS tools generate an
output architecture (in RTL) and report the throughput of
the individual generated modules. Depending on this
throughput, then the designer can modify the directives
and/or the implementation C/C?? code. If the generated
architecture meets the required throughput, then the output
RTL is used as the input to the FPGA implementation tools
(ISE/EDK). The final achievable clock frequency and
number of FPGA resources used is reported only after
running logic synthesis and place and route. If the design
does not meet timing or the FPGA resources are not the
expected ones, the designer should modify the implemen-
tation C/C?? code or the compiler directives.
The last step in this workflow, once the synthesis report
certifies the design achieves the demanded performance, is
RTL verification. Unlike non HLS design flows, this stage
occurs only once at the very end of the process instead of
taking place in each iteration. Thus, a non negligible
amount of RTL simulation hours are saved to the designer
who sees how his productivity rises. Moreover, in our case,
AutoESL’s Autopilot HLS tool supports the automatic
generation of the entire co-simulation infrastructure that
enables reusing the C/C?? testbenches to feed the gen-
erated RTL through a set of SystemC adapters.
5 Sphere decoder high-level synthesis
implementation
We have implemented the key three building blocks of the
WiMAX SD shown in Fig. 1 using AutoPilot 2010.07.ft
from AutoESL. It is important to emphasize that the
algorithm is exactly the algorithm described in [11], and
hence has exactly the same BER. In this section we give
specific examples of code re-writing and compiler direc-
tives that we have used for this particular implementation.
5.1 Design approach: iterative C/C?? refinement
The original reference C code, derived from a MATLAB
functional description, included 2000 lines of code (aprox.),
including synthesizable and verification C code. It contains
123
124
Fig. 6 Sphere detector macro-architecture description
Fig. 7 Example of code parameterization
only fixed-point arithmetic using C built-in data types. All
the required floating point operations (e.g., sqrt) have been
approximated by a FPGA-friendly implementation.
In addition to the reference C code describing the
functions to synthesize in the FPGA, there is a complete
C-level verification testbench. The input test vectors, as
well as the golden output reference files, were generated
from the MATLAB description. The original C reference
code is bit accurate with the MATLAB specification, and
passes the entire regression suite consisting of multiple
data sets.
This reference C code has gone through different types
of code restructuring. As examples, Fig. 5 shows three
instances of code restructuring that we have used, which
are explained in the following subsections. A key concept
to keep in mind is that the C-level verification infra-
structure has been re-used to verify any change to the
implementation C/C?? code. All verification has been
carried out at the C-level, not at the RTL level, avoiding
123
Analog Integr Circ Sig Process (2011) 69:119–129
time-consuming RTL simulations and hence, contributing
to the reduction in the overall development time.
5.2 Macro-architecture specification
Probably the most important code refactoring example is to
rewrite the C/C?? code to describe the macro-architec-
ture that efficiently would implement a specific function-
ality. In other words, the designer is accountable for the
macro-architecture specification, while the HLS tools are
in charge of the micro-architecture generation. This type of
code restructuring has a major impact on the obtained
throughput and quality of results.
In the case of the SD, there are several instances of this
type of code restructuring. For example, to meet the high
throughput of the channel ordering block, the designer
should describe in C/C?? the macro-architecture shown in
Fig. 2. Such C/C?? code would consist of several func-
tion calls communicating using arrays. The High Level
Synthesis tools might automatically translate these arrays
in ping-pong buffers to allow parallel execution of the
several matrix calculation blocks in the pipeline. Another
example of code restructuring at this level would be to
decide how many number of channels should be employed
in the TDM structure of a specific block (e.g., 5 channels in
the Channel Matrix Reordering block, or 15 channels in the
modified real-valued QR decomposition block.
Figure 6 is a specific example of macro-architecture
specification. This snipped of C?? code describes the
sphere detector block diagram shown in Fig. 3. We can
observe a pipeline of nine function calls, each one repre-
senting a block as shown in Fig. 3. The communication
between functions is achieved through arrays, which are
mapped to streaming interfaces (not embedded BRAM
memories in the FPGA) by using the appropriate directives
(pragmas) in lines 5 and 7.
5.3 Parameterization
Parameterization is another key example of code re-writ-
ing. We have extensively leveraged C?? template
functions to represent parameterized modules in the
architecture.
In the implementation of the SD, there are several
examples of this type of code rewriting. A specific example
would be the different matrix operations used in the
channel reordering block. The Matrix Calculations blocks
(4 9 4, 3 9 3 and 2 9 2) showed in Fig 2 use different
types of matrix operations like Matrix Inverse or Matrix
Multiply. These blocks are coded as C?? template func-
tions with the dimensions of the matrix as template
parameters.
Analog Integr Circ Sig Process (2011) 69:119–129
Fig. 8 Applying TDM to the 898 M-RVD QRD C code
Figure 7 shows the C?? template function for Matrix
Multiply. In addition to the matrix dimension, this template
function has a third parameter MM_II (Initiation Interval
for Matrix Multiply), which is used to specify the number
of clock cycles between two consecutive loop iterations.
See directive (pragma) in line 9, which is used to param-
eterize the required throughput for a specific instance. This
is a really important feature, since it has a major impact on
the generated micro-architecture. That is, the ability of the
HLS tools to exploit resource sharing, and hence, reducing
the FPGA resources used in the implementation. For
example, just by modifying this Initiation Interval (II)
parameter and using exactly the same C?? code, the HLS
tools automatically achieve different levels of resource
sharing in the implementation of the different Matrix
Inverse (4 9 4, 3 9 3, 2 9 2) blocks.
5.4 Time division multiplexing
For designs without feedback, the HLS tool is generally
able to instantiate registers freely to increase clock fre-
quency and throughput. However, in pipelines that are part
of a feedback loop, registers cannot be inserted freely
without introducing pipeline stalls. Hence, recurrences, or
feedback loops, in a design are the key limiter of
throughput. For example, Fig. 8 shows the high level
structure of the 8 9 8 M-RVD QRD loop nest. Although
there are several recurrences in the application, the critical
recurrence in this code occurs when the result X[j][0][t] of
the diagonal function call is used as an argument to the
next diagonal call. Synthesis of the diagonal function
results in a 14-stage pipeline. Hence, to accommodate the
recurrence without introducing pipeline stalls, we apply
TDM over 15 datasets. The parts typeset in boldface in
Fig. 8 explicitly reflect TDM or c-slowing over separate
datasets through the inner t-loop.
We observe several characteristics of this design. First,
the code accurately reflects the order in which data is
processed in the reference design. Second, the number of
channels to iterate over, that is, the TDM depth, cannot be
determined without knowing the size of the critical recur-
rences. Although AutoPilot does not compute the number
of channels automatically, the HLS process does analyze
the source code for recurrences and report to the designer
125
Fig. 9 FPGA optimization for DSP48 utilization
where recurrences are not met. In the SD application, since
360 independent data subcarriers have to be processed for
each frame, TDM is a straightforward way to handle the
presence of the recurrence while incurring additional buf-
fering and a small amount of additional processing latency.
5.5 FPGA optimizations
FPGA optimization is the last example of code rewriting.
The designer can rewrite the C/C?? code to more effi-
ciently utilize specific FPGA resources, and hence,
improve timing and reduce area. There are two very spe-
cific examples of this type of optimizations: (1) bit-widths
optimizations; and (2) efficient use of embedded DSP
blocks (i.e., DSP48 s). The reference C/C?? code was
written using built-in C/C?? data types (e.g., short, int),
while the design uses 18-bit fixed point data types to rep-
resent the matrix elements. We have leveraged C??
template classes to represent arbitrary precision fixed-point
data types, hence reducing FPGA resources and minimiz-
ing impact on timing.
Figure 9 is a C?? template function that implements a
multiplication followed by a subtraction, where the width
of the input operands is parameterized. These two arith-
metic operations can be mapped into a single embedded
DSP block (i.e., DSP48 block). By efficiently using
DSP48 s, timing is improved and FPGA resource utiliza-
tion is minimized. In Fig. 9, we can also observe two
directives that instruct the HLS tool to use a maximum of
two cycles to schedule these operations and use a register
for the output return value.
6 Productivity metrics
6.1 Development time
In Fig. 10 we plot how the size of the design (i.e., FPGA
resources) generated using AutoESL’s AutoPilot evolves
over time and compare it to a traditional System Generator
(i.e., RTL) implementation. It is important to observe in
this figure that by using HLS tools we are able to imple-
ment many valid solutions, which differ in size over time.
On the other hand, there is only one RTL solution, which
123
126 Analog Integr Circ Sig Process (2011) 69:119–129

Fig. 10 Development time

requires of a long development time. Many solutions can implemented using HLS tools and the reference system
be obtained using HLS tools. Depending on the amount of generator implementation, which is basically a structural
code restructuring, the designer can tradeoff how fast to get RTL design, explicitly instantiating FPGA primitives, like
a solution versus the size of that solution. for example, DSP48 blocks. Please, note that the devel-
We have observed that it is relatively quick to obtain opment time for AutoESL includes learning the tool, pro-
several fast solutions, which use significant more FPGA ducing results, design space exploration and detailed
resources (i.e., area) than the traditional RTL solution. On verification.
the other hand, the designer might decide to generate many To have accurate comparisons, we have re-implemented
more expert solutions by implementing more advanced the reference RTL design using the latest Xilinx ISE 12.1
C/C?? code restructuring techniques (e.g., FPGA-specific tools targeting a Virtex-5 FPGA. The RTL generated by
optimizations) to reduce FPGA resource utilization. AutoESL’s AutoPilot has also been implemented using ISE
Finally, and since all verification has been carried out at 12.1 targeting the same FPGA. From Table 1, we can
the C/C?? level, not at the RTL-level, we avoided the observe that AutoESL’s AutoPilot achieves significant
time consuming RTL simulations. We found that doing the savings in FPGA resources, which is mainly the result of
design verification at the C/C?? level significantly con- the application of resource sharing techniques in the
tributed to the reduction in the overall development time. implementation of the matrix inverse blocks. We can also
observe a significant reduction in the number of registers
6.2 Quality of results and a slightly higher utilization of Look-up Tables (LUTs).
This result is partially due to the fact that delay lines are
In Table 1, we compare final FPGA resource utilization mapped onto SRL16 s (i.e., LUTs) in the AutoESL
and overall development time for the complete SD implementation, while the delay lines are implemented
using registers in the system generator implementation.
There are other modules where we tradeoff BRAMs for
Table 1 Quality of results (development time and FPGA resources) LUTRAM, resulting in lower BRAM usage in the channel
Metric SysGen AutoESL % Diff preprocessor.
expert expert For a better understanding on how the area savings are
Development time (weeks) 16.5 15 29
obtained, it is instructive to look more closely at smaller
blocks of the design. The RVD-QRD block, summarized in
LUTs 27,870 29,060 ?4
Table 2, operates at II = 1, completing an 8 9 8 QR
Registers 42,035 31,000 226
decomposition of 18-bit fixed point values every 64 cycles.
DSP48 s 237 201 215
The block implements a standard Givens-rotation based
18 K BRAM 138 99 228
systolic array consisting of diagonal and off-diagonal cells,

123
Analog Integr Circ Sig Process (2011) 69:119–129 127

Table 2 8 9 8 RVD-QRD implementation results 28 DSP48

Metric RTL AutoPilot AutoPilot D

expert expert expert x x x x x x x

Dev. time (man-weeks) 4.5 3 5 (a) 4x4 case (ToplevelII=3, OD II=3)

LUTs 5,082 6,344 3,862
Registers 5,699 5,692 4,931 D 12 DSP48
DSP48 s 30 46 30 x
x x
18 K BRAMs 19 19 19
(b) 3x3 case (ToplevelII=5, OD II=1)

where the diagonal cells compute an appropriate rotation, D 4 DSP48

zeroing one of the matrix elements, and the off-diagonal x

cells apply this rotation to the other matrix elements in the (c) 2x2 case (ToplevelII=9, OD II=3)
same row. To meet the required throughput, one row of the
systolic array is instantiated, consisting of one diagonal cell Fig. 11 Complex QRD architectures
and 8 off-diagonal cells, and the remaining rows are time
multiplexed over the single row. In addition, since the imaginary components time-multiplexed over a single
systolic array includes a recurrence, 15 channels are time- datapath. Deriving and verifying the 3 9 3 and 2 9 2 case
division multiplexed over the same hardware. took approximately 1 week each. In AutoPilot, the three
In brief, Autopilot was able to generate exactly the same cases were implemented as C?? template functions,
architecture but with a more optimized pipeline for the parameterized by the size of the matrix. All three cases
non-critical off-diagonal cell, resulting in slightly lower were implemented concurrently, using a script to run
resource usage after optimization. After only 3 weeks, the multiple tool invocations in parallel. Depending on the
AutoPilot design had met timing and throughput goals, but matrix dimension, different initiation intervals (II) were
required more logic resources than the RTL design. targeted, resulting in a variety of resource sharing archi-
Additional optimization and synthesis constraints on the tectures for each block, as shown in Fig. 11
DSP48 mapping, lead AutoPilot to get the same DSP48 In the 4 9 4 case, the off-diagonal cell implements fine-
mapping as the RTL design (3 DSP48 s to implement the grained resource sharing, with one resource-shared complex
off-diagonal cell rotations and 6 DSP48 s to implement the multiplier. In the 3 9 3 case, the off-diagonal cell contains
diagonal cell computation and rotation), including mapping 3 complex multipliers and the off-diagonal cell itself is
onto the DSP48 post-adder. resource shared at a coarser granularity. In the 2 9 2 case,
Table 3 details multiple implementations of the Matrix- all of the off-diagonal cell operations are time multiplexed
Multiply Inverse components, consisting of the combined on a single complex multiplier, combining both coarse-
Matrix Multiply, QR Decomposition, and Back Substitution grained and fine-grained resource sharing techniques. In
blocks. This combination implements (ATA)-1 for various AutoPilot, the only difference between these blocks is the
dimensions of 18-bit complex fixed-point matrices. In both different target II, resulting in significant resource sharing.
RTL and AutoPilot design approaches, the 4 9 4 case was Certainly, there is no doubt that an RTL designer could have
implemented first, and the 3 9 3 and 2 9 2 cases were achieved such optimized architectures, given the appropri-
derived from the 4 9 4 case. In RTL, resource sharing was ate insight, but at the cost of a complete RTL-level redesign.
implemented in a similar way for each case, with real and We do observe that AutoPilot uses additional BRAM to
implement this block relative to the RTL implementation,
because AutoPilot requires tool-implemented double-buf-
Table 3 Matrix-multiply inverse results. autopilot (AP) versus RTL fers to only be read or written in a single loop. When con-
implementation sidered as part of the overall design, however, we were able
Metric 494 494 393 393 292 292 to reduce BRAM usage by converting BRAMs to
RTL AP RTL AP RTL AP LUTRAM due to the improved architecture of this block.
Dev. Time (man- 4 4 1 0 1 0
weeks)
7 Conclusions
LUTs 9,016 7,997 6,969 5,028 5,108 3,858
Registers 11,028 7,516 8,092 4,229 5,609 3,441
In this study we have presented the implementation of a
DSP48 s 57 48 44 32 31 24
complex and demanding wireless MIMO receiver using a
18 K BRAMs 16 22 14 18 12 14
HLS tool targeting a Xilinx FPGA.

123
128 Analog Integr Circ Sig Process (2011) 69:119–129

This evaluation has demonstrated that AutoESL’s 13. Takach, A., Bowyer, B., & Bollaert, T. (2005). C Based hardware
AutoPilot achieves significant abstractions from low-level design for wireless applications. In Proceedings of the conference
on Design, Automation and Test in Europe - (DATE ’05), Vol. 3,
FPGA implementation details (e.g., timing and pipeline pp. 124–129. Washington, DC, USA: IEEE Computer Society.
design), while producing quality of results highly com- doi:10.1109/DATE.2005.87. http://dx.doi.org/10.1109/DATE.
petitive to the ones obtained using a traditional RTL design 2005.87.
approach. C/C?? level verification contributes to the 14. Xu, J., Subramanian, N., Alessio, A., & Hauck, S. (2010).
Impulse C vs. VHDL for accelerating tomographic reconstruc-
reduction in the overall development time by avoiding time tion. symposium on field-programmable custom computing
consuming RTL simulations. However, obtaining excellent machines. doi:10.1109/FCCM.2010.33.
results for complex and challenging designs requires good
macro-architecture definition and FPGA tools knowledge
Juanjo Noguera received his
(e.g., understand and interpret FPGA tool reports). BSc degree in Computer Science
from the Autonomous University
of Barcelona, Spain, in 1997, and
his PhD degree in Computer
References Science from the Technical
University of Catalonia, Barce-
1. Berkeley Design Technology, Inc. (2007). FPGAs for DSP. BDTI lona, Spain, in 2005. He has
Industry Reports (2nd ed). Available online at: http://www.bdti. worked for the Spanish National
com/Services/WPAR/IndustryReports. Centre for Microelectronics, the
2. Grant, M., & Gary, S. (2009). High-level synthesis: Past, present, Technical University of Catalo-
and future. IEEE Design and Test of Computers, 26(4), 18–25. nia, and Hewlett-Packard Inkjet
3. Berkeley design technology, Inc. (2010). An independent evalu- Commercial Division. Since
ation of: High-level synthesis tools for xilinx FPGAs. White 2006, he has been with the Xilinx
paper. http://www.xilinx.com/technology/dsp/BDTI_techpaper. Research Labs, Ireland. His
pdf. Accessed 22 January 2011. interests include high-level system design, reconfigurable architectures
4. Amiri, K., Cavallaro, J., Dick, C., & Rao, R. M. (2009). A high and next-generation wireless communications.
throughput configurable SDR detector for multi-user MIMO
wireless systems. Journal of Signal Processing Systems. doi: Stephen Neuendorffer gradu-
10.1007/s11265-009-0360-5. ated in 1998 from the University
5. Barbero, L., & Thompson, J. (2006). FPGA design considerations of Maryland and BS degrees in
in the implementation of a fixed-throughput sphere decoder for Electrical Engineering and
MIMO systems. International Conference on Field Programmable Computer Science. He gradu-
Logic and Applications. doi:10.1109/FPL.2006.311247. ated with University Honors,
6. Mondal, S., Eltawil, A., Shen, C.-A., & Salama, K. (2009). departmental Honors in Electri-
Design and Implementation of a sort free K-best sphere decoder. cal Engineering, and was named
IEEE Transactions on Very Large Scale Integration Systems, Outstanding Graduate in the
17(11), 1497–1501. Computer Science department.
7. Yang, C., & Markovic, D. (2008). A multi-core sphere decoder He completed his PhD at UC
VLSI architecture for MIMO communications. Global Tele- Berkeley in 2003 after being
communications Conference. doi:10.1109/GLOCOM.2008.ECP. one of the key architects of
633. Ptolemy II. He has been work-
8. Cupaiuolo, T., Siti, M., & Tomasoni, A. (2010). Low-complexity ing in the Research Labs at
high throughput VLSI architecture of soft-output ML MIMO Xilinx ever since on various aspects of system design in FPGAs.
detector. In Proceedings of the conference on Design, Automation
and Test in Europe (DATE ’10). European Design and Automa- Sven van Haastregt received
tion Association, 3001 Leuven, Belgium, pp. 1396–1401. the BSc (with honors) and MSc
9. Su, K., & Wassell, I. (2005). A new ordering for efficient sphere (with honors) degrees in com-
decoding. IEEE International Conference on Communications. puter science from Leiden
doi:10.1109/ICC.2005.1494671. University, Leiden, The Neth-
10. Barbero, L., & Thompson, J. (2006). Rapid prototyping of a erlands, in 2006 and 2008,
fixed-throughput sphere decoder for MIMO systems. IEEE respectively. From January
International Conference on Communications. doi:10.1109/ICC. 2010 to April 2010, he was a
2006.255278. guest researcher at Xilinx
11. Dick, C., Trajkovic, M., Denic, S., Vuletic, D. et al. (2009). Research Labs, San Jose, CA.
FPGA implementation of a near-ML sphere detector for 802.16E He is currently working towards
broadband wireless systems. Software Defined Radio Technical his PhD degree at the Leiden
Conference and Product Exposition. Embedded Research Center of
12. Denolf, K., Neuendorffer, S., & Vissers, K. (2009). Using C-to- Leiden University. His research
gates to program streaming image processing kernels efficiently interests include automated
on FPGAs. Field Programmable Logic and Applications. doi: parallelization using polyhedral analysis, high level synthesis, and
10.1109/FPL.2009.5272373. prototyping on Field Programmable Gate Arrays (FPGAs).

123
Analog Integr Circ Sig Process (2011) 69:119–129
Jesús Barba received the MS
and PhD degrees in Computer
Engineering Diploma from the
University of Castilla-La Man-
cha (UCLM), Spain, in 2001
and 2008 respectively. He is
working as Teaching Assistant
with the Department of Infor-
mation and Systems Technol-
ogy since 2001. His research
interests include SoCs, HW/SW
integration and reconfigurable
systems.
Kees Vissers graduated from
Delft University in the Nether-
lands. He worked at Philips
Research on processors, image
processing, HDTV process-
ing and Hardware—Software
co-design. He was a visiting
industrial fellow at CMU,
working on High Level Syn-
thesis, and a visiting industrial
fellow at UC Berkeley working
on streaming models of com-
putation. He was a director of
Architecture at Trimedia, CTO
at Chameleon Systems, and
consulted for Intel, Nvidia and Xilinx. He is today a distinguished
engineer in the CTO office of Xilinx. He is working with the teams
that work on designing and programming systems that consists of
129
processors and reconfigurable fabric. He has a quantitative approach
to tools and architectures. He has a broad interest in Signal Processing
Systems.
Chris Dick is the DSP Chief
Arhictect at Xilinx and the
engineering manager for the
Xilinx Communications Signal
Processing Group. Chris has
worked with signal processing
technology for two decades and
his work has spanned the com-
mercial, military and academic
sectors. Prior to joining Xilinx
in 1997 he was a professor at La
Trobe University, Melbourne
Australia for 13 years and
managed a DSP Consultancy
called Signal Processing Solu-
tions. He has been an invited speaker at many international signal
processing symposiums and workshops and has authored more than
100 journal and conference publications, including many papers in the
fields of parallel computing, inverse synthetic aperture radar (ISAR),
FPGA implementation of wireless communication system PHYs and
the use of FPGA custom computing. Chris’ work and research
interests are in the areas of fast algorithms for signal processing,
digital communication, MIMO, OFDM, software defined radios,
VLSI architectures for DSP, adaptive signal processing, synchroni-
zation, hardware architectures for real-time signal processing, and the
use of Field Programmable Arrays (FPGAs) for custom computing
machines and real-time signal processing. He holds a bachelor’s and
PhD degrees in the areas of computer science and electronic
engineering.
123