Synthesis of pipelined DSP accelerators with dynamic scheduling.
Abstract: To construct complete systems on silicon, application specific DSP accelerators are needed to speed up the execution of high throughput DSP algorithms. In this paper, a methodology is presented to synthesize high throughput DSP functions into accelerator processors containing a datapath of highly pipelined, bit-parallel hardware units. Emphasis is put on the definition of a controller architecture that allows efficient run-time schedules of these DSP algorithms on such highly pipelined data paths. The methodology is illustrated by means of an FFT butterfly accelerator block.
Introduction
C OMPLEX digital systems such as the videophone terminal
of figure 1 typically consist out of a heterogeneous
mix of hardware blocks [1]: processor cores, general
purpose macro blocks, and dedicated accelerator proces-
sors. These accelerator blocks are required to execute high
performant DSP functions such as motion estimation and
DCT/IDCT functions.
In this paper we will concentrate on the generation of
such application specific accelerator processors. We will
highlight both the design issues and the architecture char-
acteristics. The requirements of such accelerator processors
are:
ffl High throughput requirements impose the usage of
pipelined data paths.
ffl Area can be saved through the hardware sharing of
different micro-instructions.
ffl The accelerator processor has to be embedded in an
overall system architecture.
P. Schaumont, B. Vanthournout and I. Bolsens are with the In-
teruniversitary Micro-Electronics Center (IMEC), Kapeldreef 75, B-
3001 Leuven, Belgium. H. De Man is with the Interuniversitary
Micro-Electronics Center and Professor at the Katholieke Universiteit
Leuven, Belgium
control
data
Variable
Length
Coder
Variable
Length
Decoder
Motion
Estimator
Reconstructor
Compressor
accelerator components
micro
controller
video
RAM I/O
Fig. 1. Architecture of a Video Phone
ffl The accelerator functions can execute both at a manifest
rate and a nonmanifest rate or Data Introduction
Interval (DII [2],[3]). An example of the former is the
processing of a data stream out of an A/D converter.
An example of the latter is the processing of data out
of a processor core inside the system.
The support of a nonmanifest DII allows to split the development
of the system control component schedule and
the accelerator processor schedule. The software executed
by the system control component thus can be revised even
after the accelerator processor was developed. This is an
essential feature in the presence of today's complex algorithms

As seen from the system control software, the accelerator
component is a function call. Execution of this call spawns
off the system control thread into the accelerator, executes
the accelerator operations, and resynchronizes with the system
control thread. Such a scheme is used by some commercial
numerical coprocessor components [4].
The presented synthesis system allows to generate such
components, but with a much higher complexity and processing
power.
II. Overview of the work
Automated synthesis systems for pipelined datapaths
have been reported previously: pisyn [2], sodas [3], and
sehwa [5]. All of these assume a fixed DII. Therefore, they
fix the runtime schedule at compile time. For an accelerator
function, the fixed rate assumption does not hold and
more flexibility is needed.
For this purpose, our work has concentrated on the following
issues. The accelerator algorithm is defined by
means of a signal flow graph (SFG). The accelerator datapath
is defined as a set of application specific units (ASU) [6].
An ASU is a bit-parallel hardware operator, able to execute
one or more micro-instructions. The micro-instructions are
defined by subsets or clusters of the SFG. Each cluster corresponds
to one micro-instruction, and the set of all clusters
covers the complete SFG. This way, the accelerator
algorithm corresponds to a sequence of micro-instructions.
An efficient interconnect network, consisting of pipeline
registers, will take care of moving data from one ASU to
the other without creating a communication bottleneck.
A simple and fast controller structure is defined that
organizes the run-time sequencing of the micro-instructions
on the ASU's.
Finally, a complete design flow, from algorithm specification
to implementation is defined. For the synthesis,
including pipelining and retiming of ASU components, we
rely on existing data path synthesis tools and retiming tools
instruction bus
accelerator controller
accelerator datapath
do doAck done
pipeline register
Fig. 2. Architecture of the Accelerator Processor
[8]. The design flow is integrated into a software system
called dolphin.
In the next sections we will further detail the design steps
to realise a data path architecture composed of ASU's. After
an overview of the synthesis process, we examine the
design steps that lead to the accelerator datapath (III-A-
III-C). Following this, the architecture of the run-time
controller is elaborated (III-D), and the operation of the
controller is explained (III-E). Finally, the described architecture
and method will be demonstrated (IV) by synthesizing
a quadrature mirror filter bank used for image
encoding.
III. The Accelerator Architecture

Figure

2 shows the overall structure of the pipeline pro-
cessor. Two parts can be distinguished: an accelerator data
path and an accelerator controller.
The accelerator datapath consists of ASUs and interconnection
buses with pipeline registers. All connections run
point-to-point, and the use of latch registers that require
read-write signals is avoided. This way, the interconnection
strategy avoids that either a multiplexed bus or an inter-connect
storage register can become a pipeline bottleneck.
The accelerator controller is steered by the system level
controller through a processor interface. It also generates
control signals for the accelerator datapath, as well as
strobe signals for the input and output buses on that dat-
apath. The accelerator controller does not provide looping
and branching support: it sequences micro-instructions to
the datapath.
A. The Accelerator Data Path
The different steps taken in the design of the accelerator
data path are illustrated in figure 3, along with a small
example.
1. Using the SFG specification of the accelerator func-
tion, the accelerator data path is defined by clustering
the SFG. A cluster can contain functional operations
(additions, shifts, .), or else signal flowgraph
inputs and outputs. SDF semantics [9] are assumed.
The clustered graph must be a directed acyclic graph
(DAG). This implies that loops in the SFG, such as
algorithmic feedback loops, must be enclosed within
one cluster.
2. These clusters are assigned to hardware. Clusters containing
functional operations are assigned to ASU op-
erators, while clusters containing input/output operations
are assigned to input/output strobes. The SFG
data precedences that cross the borders of the clusters
define the interconnection buses of the accelerator
data path.
3. The set of clusters assigned to one ASU define the
ASU micro-instruction set and composition. It consists
of a local controller (LC) and a bitparallel data
path.
The local controller handles micro-instruction decoding
and local decision making. As a consequence, there
is no global decision making and thus no condition
evaluation circuitry in the accelerator controller.
The ASU bitparallel data path is obtained using the
Cathedral-3 data path synthesis tools [7], [8], which
are capable of mapping the SFG operations inside a
cluster to a bitparallel data path using sharing where
possible.
The available bitparallel operators and some corresponding
SFG operations are listed in table I. These
operators are a library of parametrized descriptions
that are instantiated in standard cells during synthesis

Aside from ASU definition tools, retiming software is
used to insert pipeline registers in the ASU data path.
Also, netlist optimization tools [10], [11] are used to
tune the instantiated bitparallel operator to an application
specific one.
The I/O timing behavior on the data and control ports
of an ASU is known as the timing view. It is expressed
as a number of clock cycles, representing the latency
between ASU input consumption and output production

4. To find the number of interconnection pipeline registers
we proceed as follows. The cluster latency is expressed
as the number of clock cycles needed to evaluate
that cluster. Using the cluster latencies as operation
lengths, and the (operator,micro-instructions)
tuples as conflicts, the clustered graph is scheduled.
The cluster latency is equal to the ASU latency incremented
by one. The increment of one ensures that
at least one pipeline register will be present on an
interconnection bus between two ASU clusters. The
maximum combinatorial delay, or critical path length,
of the accelerator datapath will therefore comply the
timing specs that were used for the individual ASU's.
A list scheduling algorithm is used to perform the or-
dering. The cluster schedule is also used to model the
micro-instruction sequence of the overall data path in
a table, with one row per ASU and one column per
clock cycle. Such a structure is called a reservation
clustering
Clustered SFG
cluster
assignment
ASU
definition
Clusters
per ASU
ASU
Structure
Timing View
per ASU
cluster
scheduling
Schedule
Reservation Table
Construction
interconnect
extraction
Reservation

Table

Interconnect
Controller
Generation
Accelerator
Controller
ip ip
<<
op op
io 0, m0
io 1, m4
m1/ m3<<
in2/_
in1/a
io 0, m0
io 1, m4
Assigned Clusters
ASU Structure
Reservation Table24
Fig. 3. Design flow for the Accelerator Processor
table, which is the basic data structure in the design
of the accelerator controller.
B. Cluster Scheduling
The cluster scheduling algorithm applied influences both
the controller specification (the reservation table) and the
interconnect specification (the number of pipeline registers
on each interconnect bus).
We wish to distinguish between the scheduling as applied
here to obtain the data path interconnect, and the
scheduling needed to decide upon the DII at runtime. Most
scheduling authors fix the DII at compile time, and apply
sophisticated techniques [12], [13], [14], [15] to arrive at a
minimum cost solution for both interconnect and DII.
Unfortunately, these cannot be applied to the problem
at hand: An accelerator requires the DII to be selectable
at runtime. The controller that will be presented is able to
do so, within the performance capabilities of the pipeline.
Therefore, we only consider scheduling as used to obtain
the data path interconnect. Currently, a list scheduling
algorithm is used. This approach only takes microinstruction
resource conflicts into account. In order to ob-


I
The available bitparallel ASU operators.
SFG operation ASU operator description
multfbb booth multiplier
delay regfbb register
delay regfilefbb register file
!!, ?? (fixed) hardwired shift operator
!!, ?? (variable) shiftfbb barrel shifter
== compfbb comparison
?,!,?=,!= addsubfbb flag generation
detection of 0, 1
z / if (:::) muxfbb signal selection
increment
tain a more optimal solution, one of two approaches can be
ffl Optimization for a desired DII. It has been shown [16]
that an arbitrary DII or DII cycle from a pipeline can
be obtained provided that performance of the pipeline
is not exceeded, and the adequate number of data path
interconnect delays are introduced.
ffl Optimization for interconnect cost. Minimization of
the number of pipeline registers residing on the inter-connect
buses can be done in polynomial time [17].
At that time, the DII rate can no longer be arbitrarily
chosen.
These two methods have conflicting goals, and depending
on the application one might prefer one or the other.
C. Clustering
The SFG clustering and assignment process, that leads
to the definition of the data path operators, will be further
detailed in this section. Current state of the art clustering
strategies [18] indicate that there is no single unifying approach
to obtain these clusters automatically. Rather, the
ideal approach is believed to be a toolbox of functions that
aid the designer in clustering an SFG.
Therefore, our current approach to SFG clustering and
assignment for the accelerator processor is a manual pro-
cess. In this section, we will identify the costs involved in
this process and derive the guidelines that will steer it. It
will be shown that, for the application area of DSP, small
clusters introduce excessive multiplexing cost, and therefore
that large clusters are preferable.
First, the hardware costs inside an ASU processor are
identified. The hardware cost is primarily defined by the
active silicon area. There are three sources of active area.
ffl The data path cost, determined by the operator area
needed to implement the SFG operations.


II
Cell Area in equivalent 2-NAND gates
Cell Function Location gates/bit
FADD1 Full Adder data path 5.5
MUX2 2-Multiplexer sharing 2.3
DFF MS-flipflop interconnect 4.6
LA Latch interconnect 3.5
ffl The multiplexing cost, which is the multiplexer area
needed to implement hardware sharing on an operator.
ffl The interconnection cost, consisting of the area of all
pipeline registers that carry signals from one cluster
to the next.
Through SFG clustering and cluster assignment the
operation-operator binding is fixed.
1. The multiplexing cost and data path cost are determined
by the set of clusters assigned to the same ASU.
2. The interconnection cost is expressed in the number of
SFG signals crossing the boundary of the clusters, and
the lifetimes of these signals. The latter is determined
by the cluster schedule.
Hardware sharing will only be effective if the savings in
data path cost exceeds the extra cost introduced by the
sharing. All the operations shown in table I except for the
delay operations are shareable. The delay operations are
needed to implement algorithmic state, which is common
in DSP algorithms.
We now show why we need a large shareable cluster size
within the target accelerator processor architecture.
In table II, the hardware cost of different operators is
expressed in terms of equivalent 2-input NAND-gates in
the target technology. These figures were obtained by averaging
the properties of two 0-5 standard cell CMOS li-
a b
c
a b
a b
c
a b
c
Fig. 4. Sharing Cost Example
braries. The bitparallel operators introduced by the data
path synthesis tools are described in terms of these cells.
For example, a ripple carry adder is a chain of FADD1 cells,
while a multiplier is a matrix of FADD1 cells. The table also
lists the multiplexing operator and the interconnect opera-
tors, the flip-flop and the latch. The proposed accelerator
uses the edge-sensitive flip-flop on the interconnect.
Consider the SFG snippet of figure 4. It is assigned in
two different ways. The leftmost one is intended to have no
sharing, and has an area cost of 11 gates/bit. The right-most
one shares the addition, but it has an area cost of
14.7 gates/bit. Both implementations have the same per-
formance: the rightmost implementation has half the critical
path of the leftmost one, but it needs two clock cycles
to perform the operation. We conclude that sharing is not
useful for this SFG: the multiplexing cost exceeds the sharing
gain.
If the operator area cost gets higher, as for example
when using multipliers, sharing might provide area gain.
The data path synthesis tools try to maximize the cluster
subgraph that can be shared among different micro-
instructions, such that sharing area gain will exceed multiplexing
cost. Given the nature of DSP algorithms however,
this is not an easy task.
ffl Complex operations are often expanded to simple ones:
A constant multiplication is implemented as an expansion
of add-shift operations which have irregular
structure. Such structures are difficult to share.
ffl Many operations like shift, bit-select and bit-reverse
are implemented hard-wired, and have virtually nil operator
size.
ffl In DSP algorithms, algorithmic delay is a key element.
This delay cannot be shared, and cuts down the maximal
cluster subgraph that can be shared.
We conclude that clustering is a process that should be
do
doAck
done
example interface behavior
m40Fig. 5. The Processor Interface Behavior
done with care, and that the designer, who knows the application
at hand, is in the best position to do it.
As table II shows, one might be inflected to use a latch
LA instead of a flip-flop DFF in order to gain interconnect
area. It is not done for the following reason. Using latches
to separate pipeline stages, and a double phase clocking
scheme, only half of the pipeline stages are filled at maxi-
mumthroughput [19]. To get the same performance as with
edge triggered flip-flops, we need a dual latch between each
pipeline stage. The figures in the table indicate that the
dual-latch solution is no better then the flip-flop solution.
D. The Accelerator Controller
After a discussion of the data path synthesis process,
we focus on the accelerator controller. The accelerator
controller must perform ASU micro-instruction sequencing
according to the cluster schedule, as represented in the
reservation table.
In figure 5, the operation of the controller is illustrated
by an example. The reservation table that was derived
in the previous example is on top. Below, the processing
of three SFG frames is shown in terms of the processor
interface pins. Time runs from left to right, one clock cycle
at a time.
The processor interface makes use of three signals do,
doAck and done. The do pin is used to initiate the processing
of one SFG frame, represented in the accelerator
controller by one reservation table instance. When a do
command is accepted, it means that hardware will be available
to execute the schedule in reservation table during the
next few cycles.
In the example the do pin is held high during 5 consecutive
clock cycles. Acceptance of the do commands is acknowledged
through the doAck output. At the second clock
cycle, a new reservation table instance can be interleaved
with the first one. For the third and fourth cycle however,
this interleaving fails and the do is not acknowledged. This
failure originates in the hardware sharing from asu 0 and
6 IEEE TRANSACTIONS ON VERY LARGE SCALE INTEGRATION (VLSI) SYSTEMS
is called a pipeline conflict. Thus, the accelerator controller
takes care of two key functions:
ffl Run-time scheduling of ASU micro-instructions and
detection of conflicts
ffl Interleaving of accelerator-level instructions
This leads to the accelerator controller hardware presented
in figure 6. Three parts are discerned:
ffl The Micro-Instruction Shifter
ffl The Conflict Controller
ffl The Processor Interface
The micro-instruction shifter is used to store reservation
table initiations. Each ASU micro-instruction bus or in-
put/output strobe has a proper shift register corresponding
to one row in the reservation table. A start signal loads
one instance of the reservation table into the shift registers,
in order to obtain the interleaving shown earlier.
The start signal is also fed into the conflict controller.
This is a hardware conflict model that signals occuring
pipeline conflicts through the ready output. Whenever this
output is high, a new reservation table can be interleaved
in the micro-instruction shifter. When this output is low,
interleaving is not possible. The start signal depends on
two conditions:
ffl The user requests accelerator execution through the do
pin of the processor interface.
ffl The conflict controller indicates the shift register controller
is ready to accept a new initiation.
Therefore, the start can be derived out of the do and
ready signals by means of an AND gate.
The two remaining processor interface signals are easily
derived out of the start signal. The done output models
the latency of the accelerator, and is obtained out of start
through simple delay.
The processor interface makes both stand-alone and
slave operation possible. For stand-alone operation, the
do-pin is tied to a logical high. In this case, the processing
rate is fixed by the conflict controller, and the processing
of a frame will be initiated whenever there is no pipeline
conflict occuring.
E. The Controller at work
The conflict controller contains the core of the dynamic
scheduling properties of the accelerator. A simple control
strategy and architecture, which can be used as conflict
controller, is due to Davidson [20]. His approach is based
on dynamic modeling of data path resource conflicts.
The instances at which a conflict occurs after the initiation
of a reservation table are called forbidden latencies.
In the example reservation table of figure 7, an initiation
will introduce a pipeline conflict, due to asu 0, two cycles
after this initiation.
An initiation latency is defined as the delay, in clock
cycles, between two succesive initiations. In order to satisfy
the resource constraints, an initiation latency cannot equal
a forbidden latency.
To achieve dynamic modeling, the pipeline conflicts are
marked as indices in a bit vector, which is shifted right as
time proceeds. This bit vector, which is called collision
do done
doAck
start
micro
instruction
shifter
conflict
controller
processor
interface
ready
reservation table shift reg
instruction bus
acceleration controller
Fig. 6. The Accelerator Controller
vector, is numbered right to left starting from 1. Bit position
i of this vector indicates wether a pipeline conflict
occurs within i clock cycles. Hence, bit position one indicates
wether a conflict occurs the next cycle, and thus
wether a new initiation is possible at the next cycle.
The initial marking of the forbidden latencies found out
of the reservation table results in an initial collision vec-
tor. Upon each new initiation, the initial collision vector is
marked into the current collision vector.
Taking the initial collision vector, a state diagram can be
constructed, with the states indicating initiation instances
and edges carrying the initiation latencies. This state diagram
is discussed in literature [21],[22]. The states are
marked with a collision vector. The initial state carries
the initial collision vector, and represents the moment just
after initiation of the empty pipeline.
Out of the positions within a collision vector with zero
bits, the initiation latencies can be derived. Out of the
initial state in the example (state 10), a new initiation is
possible already the next cycle. At that moment, the initial
collision vector is shifted one position, corresponding to a
one cycle delay. At the same time, the pipeline conflicts
introduced by this new initiation are annotated in the collision
vector by OR-ing the initial collision vector into the
current one. This results in a new collision vector (state
11). Out of this state, an initiation latency of at least 3
cycles is required, as bit positions 1 and 2 are non-zero in
the collision vector. This next initiation returns us to the
initial state.
3 or more3 or moreState transition diagram
Forbidden Latencies
collision
vector
shift reg
Conflict Controller
{ } (no conflict)
{ }
{ }
all {2}
Initial Collision Vector
clock cycle
start
ready
Fig. 7. Construction of the Conflict Controller
The state diagram models every valid pipeline state, and
therefore any cycle within this state diagram is a valid
schedule.
Using the initial collision vector, a simple hardware
structure that generates the state diagram can be con-
structed. The collision vector is modeled by means of a
shift register. Upon initiation, a new version of the initial
collision vector is or-ed into the current collision vector.
This structure is used as the conflict controller.
The advantages of using this controller architecture are
ffl Static and dynamic schedules are available within the
same controller architecture (corresponding to stand-alone
and slave-mode operation). By using runtime
conflict modeling, all possible schedules are supported.
ffl The controller has a regular structure, and is small and
fast. It can be shown that careful design reduces the
critical path to one gate delay.
ffl It allows parallel, pipelined execution of several SFG
frames.
IV. Design example
Next we present a synthesis environment called dolphin
that supports the synthesis of the accelerator processors.
We will do this in course of the synthesis of an example
accelerator.
The example concerns an accelerator typically used in
image encoding algorithms: the two-channel Quadrature
Mirror Filter (QMF) bank. This filter decomposes a full-rate
signal into two half-rate sub-signals, such that the ensemble
of subsignals can be used to reconstruct the original
signal. The basic theory on QMF banks is exposed in [23],
while [24] and [25] present more recent work.

Figure

8 sketches the system architecture of a 2 channel
QMF bank. The signal In(z) is decimated into two
streams, consisting of the even and odd In(z) samples.
These are fed into two digital filters H 0 (z) and H 1 (z). Two
decimated signals O 1 (z) and O 2 (z) are produced. The2
In(z)
z
k z -k
z -k
Fig. 8. A two-channel QMF bank
filter impulse responses of H 0 (z) and H 1 (z) are mirror-
symmetrical and related such that the reconstruction property
holds on the output signals O 1 (z) and O 2 (z).
We wish to generate an accelerator processor for this
filter. One input port is allocated to feed the input signal
In(z), and one output port extracts both O 1 (z) and O 2 (z).
This way, the data rates on input and output port are
balanced. We also want the accelerator processor to have
minimal latency and maximal data throughput.
A behavioral description of the QMF filterbank in the
silage behavioral language [26] is shown in listing 9. In
this design example, we use the filter coefficients for the
16-tap FIR case described in [24], quantized to 14 bit.
The accelerator is now synthesized according to the design
flow shown in figure 3: Clustering of the SFG, definition
of the ASU datapath, evaluation of the cluster sched-
ule, and controller synthesis. The target implementation is
a CMOS 0-7 standard cell technology.
For the purpose of clustering, the silage description is
converted to a graph format, upon which the user can interactively
indicate the desired clustering.
The clustering is performed as indicated in figure 10:
ffl The input operation of In(z) is assigned to I/O tuple
(io 0,m0).
ffl The splitting of In(z) into odd and even streams requires
one delay operation, which is assigned to asu
8 IEEE TRANSACTIONS ON VERY LARGE SCALE INTEGRATION (VLSI) SYSTEMS
#define W fix!14,12?
#define W2 fix!18,16?
begin
Fig. 9. The QMF silage description2
In(z)
z
io 0, m0
io 1, m0
io 1, m1
z -k
Fig. 10. Clustering of the the QMF bank
ffl The filtering of the decimated streams has been
grouped into a single cluster, assigned to the asu-
microinstruction tuple (asu sharing is introduced
because of the maximal throughput requirement
and irregular structure of the constant tap multiplications

ffl The two output operations have been assigned to I/O
tuple (io 1, m0) and (io 1,m1). This assignment
expresses the sharing of the output signals O 1 (z) and
O 2 (z) on the output port.
Following clustering, the ASU definition is done. The
following steps are performed.
ffl Operator selection and operator netlist generation.
This includes expansion of operations such as the expansion
of the constant filter tap multiplications into
canonical signed digit (CSD) add-shift operations.
ffl Mapping of the operator netlist to an abstract standard
cell library.
ffl Standard cell netlist optimization including redundancy
removal, retiming and buffering. The retiming
tool allows to specify a desired target clock. For our
example, a target clock of 27MHz was chosen.
We next evaluate the cluster schedule using the timing
view obtained from the ASU definition. The conflict model
is shown on the left of figure 11. The presence of decimate
operations in the input description is visible as multiplexing
switches. The tool copes with this by an expansion
step which enumerates all paths in the clustered graph.
Since the graph is acyclic, this is a trivial operation. The
resulting conflict model is shown on the right of figure 11.
Using the schedule obtained by the list scheduler, a reservation
table as shown in figure 12 is constructed. This data
structure fixes the collision vector, and defines the state
transition diagram. The shift register controller as well as
the conflict controller is synthesized out of it. Finally, the
controller and datapath are interconnected.
The resulting cicruit properties are summarized in table
III. The complete design flow is supported by a software
script allowing a short edit-compile-test cycle from
behavioral description to optimzed netlist. For the example
this cycle takes less than 15 minutes on a HP700.
V. Conclusion
In this paper, a strategy and a tool was presented to integrate
data path synthesis and retiming tools into a system
component design environment.
ffl The proposed strategy allows to generate small and
efficient control for pipelined systems.
ffl In addition, an implementation of a system level data
model is offered through a processor interface.
expand
Fig. 11. The QMF multirate and expanded conflict model
collision
state transition diagram
reservation table
Fig. 12. The QMF reservation table
Different schedules are available within one controller
architecture, allowing non-manifest data rates.
An integrated environment for the design of these accelerators
, called dolphin, was developed. Currently, it is
being used for the design of accelerator parts in systems
for videotelephony and compression, and advanced CATV
modem parts.

Acknowledgements

The authors wish to thank Karl Van Rompaey and Serge
Vernalde from IMEC for the constructive remarks during
the writing of this paper. The work is also founded on
the netlist optimization tools developed by Luc Rijnders
and Zohair Sahraoui from Imec, on the library work of
Veerle Derudder from Imec and on the test work of Maryse
Wouters from Imec.


III
Circuit properties of the QMF bank accelerator
Component Cells Active Area Critical
(mm
Data Path 1894 2.88 26.3
Controller
InterConnect 408 0.46 5.75
Technology: CMOS 0-7 standard cells



--R

"VLSI Architectures for Video Compression"
"Scheduling and Hardware Sharing in Pipelined Data Paths"
"Design of a Pipelined Datapath Synthesis System for Digital Signal Processing"
"Issues in CPU Coprocessor Communication and Synchronization"
"Sehwa: A Software Package for Synthesis of Pipelines from Behavioral Specifications"
"Cathedral-III: Architecture-Driven High-level Synthesis for High Throughput DSP Applications"
"Combined Hardware Selection and Pipelining in High-Performance Data-Path Design"
"Synthesis of high Throughput DSP ASICs using Application Specific Data paths"
"Static Scheduling of Synchronous Data Flow Programs for Digital Signal Processing"
"Area Optimization of Bit-Parallel Custom Data Paths"
"Timing Optimization by bit-level arithmetic transformations"
"PLS: A Scheduler for Pipeline Synthesis"
"Force Directed Scheduling in Automatic Data Path Synthesis"
"Functional Requirements for an extended scheduling tool"
"A formal approach to the scheduling problem in high level synthesis"
"Maximum Performance Pipelines with Switchable Reservation Tables"
"Minimizing the Number of Delay Buffers in the Synchronization of Pipelined Systems"
"Synthesis of accelerator data-paths for high- throughputsignal processing applications"
"The Counterflow Pipeline Processor Architecture"
"Effective Control for Pipelined Computers"
"The Architecture of Pipelined Computers"
"Pipeline Architecture"
"Quadrature Mirror Filter Banks, M-Band Extensions and Perfect-Reconstruction Techniques"
"A Closed Form Expression for an Efficient Class of Quadrature Mirror Filters and Its FIR Imple- 10 IEEE TRANSACTIONS ON VERY LARGE SCALE INTEGRATION (VLSI) SYSTEMS mentation"
"Fast and Low Roundoff Implementation of Quadrature Mirror Filters for Subband Cod- ing"
"DSP specification using the silage language"
--TR
Cathedral-III
Pipeline Architecture

--CTR
Miodrag Potkonjak , Kyosun Kim , Ramesh Karri, Methodology for behavioral synthesis-based algorithm-level design space exploration: DCT case study, Proceedings of the 34th annual conference on Design automation, p.252-257, June 09-13, 1997, Anaheim, California, United States
Andreas Koch, Efficient integration of pipelined IP blocks into automatically compiled datapaths, EURASIP Journal on Embedded Systems, v.2007 n.1, p.9-9, January 2007
highly pipelined data paths;parallel architectures;pipelined DSP accelerator synthesis;application specific DSP accelerators;datapath;dynamic scheduling;pipeline processing;controller architecture;circuit CAD;application specific integrated circuits;pipelined bit-parallel hardware;scheduling;FFT butterfly accelerator block;network synthesis;run-time schedules;silicon;digital signal processing chips;DSP algorithms