36 T. Bollaert
Fig. 3.3 The Gantt chart
to complete. In the Catapult flow, the generation of RTL is accomplished in a matter
of minutes.
Catapult generates VHDL, Verilog or SystemC netlists, based on user settings.
Various reports are also produced providing both hardware-centric and algorithm-
centric information about the design’s characteristics.
Finally, Catapult provides an integrated verification flow that automates the pro-
cess of validating the HDL netlist(s) output from Catapult against the original
C/C++ input. This is accomplished by wrapping the netlist output with a SystemC
“foreign module” class and instantiating it along with the original C/C++ code and
testbench in a SystemC design. The same input stimuli are applied to both the orig-
inal and the synthesized code and a comparator at each output validates that the
output from both are identical (Fig. 3.4). The flow automatically generates all of
the SystemC code to provide interconnect and synchronization signals, Makefiles to
perform compilation, as well as scripts to drive the simulation.
3.3 Coding and Optimizing a Design with Catapult Synthesis
This section provides an overview of the various controls the user can leverage to
efficiently synthesize his design.
3 Catapult Synthesis: A Practical Introduction to Interactive C Synthesis 37
Fig. 3.4 Catapult synthesis’ automatic verification flow
3.3.1 Coding C/C++ for Synthesis
The coding style used for functional specification is plain C++ that provides a
sequential implementation of the behavior without any notion of timing or concur-
rency. Both the syntax and the semantics of the C++ language are fully preserved.
3.3.1.1 General Constructs and Statements
Catapult supports a very broad subset of the ANSI C++ language. The C/C++
synthesized top-level function may call other sub-functions, which may be inlined
or may be kept as a level of hierarchy. The design may also contain static vari-
ables that keep some state between invocations of the function. “if” and “switch”
condition statements are supported, as well as “for,” “do” and “while” looping

statements. “break,” “continue” and “return” branching statements are synthesiz-
able as well. The only noticeable restriction is that the code should be statically
determinable, meaning that all its properties must defined at compilation time. As
such, dynamic memory allocation/deallocation (malloc, free, new, delete) is not
supported.
3.3.1.2 Pointers
Pointers are synthesizable if they point to statically allocated objects and there-
fore can be converted into array indexes. Pointer arithmetic is also supported and
a pointer can point to several objects inside of an array.
38 T. Bollaert
Fig. 3.5 Coding style example
3.3.1.3 Classes and Templates
Compound data types such as classes, structs and arrays are fully supported for
synthesis. Furthermore, parameterization through C++ templates is also supported.
The combination of classes and templates provides a powerful mechanism facilitat-
ing design re-use.
The example in Fig. 3.5 gives an overview of some of the coding possibilities
allowed by the Catapult synthesizable subset. A struct is defined to model a RGB
pixel. The struct is templatized so users can define the actual bitwidth of the R,
G and B fields. Additionally, a method is defined which returns a grayscale value
from the RGB pixel. The synthesized design is the “convert
to gray” function. It
is implemented as a loop which reads RGB pixels one by one from an input array,
calls the “to
gray” method to compute the result and assigns it to the output array
using pointer arithmetic.
3.3.1.4 Bit-Accurate Data Types
Hardware designers are accustomed to bit-accurate datatypes in hardware design
languages such as VHDL and Verilog. Similarly, bit-accurate data types are needed
to synthesize area efficient hardware from C models. The arbitrary-length bit-

accurate integer and fixed-point “Algorithmic C” datatypes provide an easy way
to model static bit-precision with minimal runtime overhead. Operators and meth-
ods on both the integer and fixed-point types are clearly and consistently defined so
that they have well defined simulation and synthesis semantics.
The precision of the integer type ac
int<W,S> is determined by template param-
eters W(integer that gives bit-width) and S (a boolean that determines whether the
integer is signed or unsigned).
The fixed-point type ac
fixed<W,I,S,Q, O> has five template parameters which
determine its bit-width, the location of the fixed-point, whether it is signed or
unsigned and the quantization and overflow modes that are applied when construct-
ing or assigning to object of its type.
3 Catapult Synthesis: A Practical Introduction to Interactive C Synthesis 39
The advantages of the Algorithmic C datatypes over the existing integer and
fixed-point datatypes are the following:
• Arbitrary-Length: this allows a clean definition of the semantics for all operators
that are not tied to an implementation limit. It is also important for writing general
IP algorithms that don’t have artificial (and often hard to quantify and document)
limits for precision.
• Precise Definition of Semantics: special attention has been paid to define and
verify the simulation semantics and to make sure that the semantics are appro-
priate for synthesis. No simulation behavior has been left to compiler depen-
dent behavior. Also, asserts have been introduced to catch invalid code during
simulation.
• Simulation Speed: the implementation of ac
int uses sophisticated template
specialization techniques so that a regular C++ compiler can generate opti-
mized assembly language that will run much faster than the equivalent SystemC
datatypes. For example, ac

int of bit widths in the range 1–32 can run 100×
faster than the corresponding sc
bigint/sc biguint datatype and 3× faster than
the corresponding sc
int/sc uint datatype.
• Correctness: the simulation and synthesis semantics have been verified for many
size combinations using a combination of simulation and equivalence checking.
• Compilation Speed and Smaller Executable: code written using ac
int datatypes
compiles 5× faster even with the compiler optimizations turned on (required for
fast simulation). It also produces smaller binary executables.
• Consistency: consistent semantics of ac
int and ac fixed.
In addition to the Algorithmic C datatypes, Catapult Synthesis also supports the
C++ native types (bool, char, short, int and long) as well as the SystemC sc
int,
sc
bigint and sc fixed types and their unsigned version.
3.3.2 Synthesizing the Design Interface
3.3.2.1 Hardware Interface View of the Algorithm
The design interface is how a hardware design communicates with the rest of the
world. In the C/C++ source code, the arguments passed to the top-level function
infer the interface ports. Catapult can infer three types of interface ports:
• Input Ports transfer data from the rest of the world to the design. All inputs are
either non-pointer arguments passed to the function or pointer arguments that are
read only.
• Output Ports transfer data from the design to the rest of the world. Structure or
pointer arguments infer output ports if the design reads from them but does not
write to them.
• Input ports transfer data both to and from the design. These are pointer arguments

that are both written and read.
40 T. Bollaert
3.3.2.2 Interface Synthesis
Catapult builds a correspondence between the arguments of the C/C++ function
and the I/Os of the hardware design. Once this is established, the designer uses
interface synthesis constraints to specify properties of each hardware ports.
With this approach, designers can target and build any kind of hardware interface.
Interface synthesis directives give users control other parameters such as bandwidth,
timing, handshake and other protocols aspects.
This way the synthesized C/C++ algorithm remains purely functional and
doesn’t have to embed any kind of interface specific information. The same code
can be retargeted based on any interface requirement (bandwidth, protocol, etc )
Amongst other transformations and constraints, the user can for instance:
• Define full, partial or no handshake on interface signals
• Map arrays to wires, memories, busses or streams
• Control the bandwidth (bitwidth) of the hardware ports
• Add optional start/done flags to the design
• Define custom interface protocols
Hardware specific I/O signals such as clock, reset, enable or and handshaking
signals do not need to be modeled either and are added automatically based on user
constraints.
3.3.3 Loop Controls
3.3.3.1 Loop Unrolling
Loop unrolling exposes parallelism that exists across different subsequent iterations
of a loop by partially or fully unrolling the loop.
The example in Fig. 3.6 features a simple loop summing two vectors of four
values. If the loop is kept rolled, then Catapult will generate a serial architecture. As
shown on the left, a single adder will be allocated to implement the four additions.
The adder is therefore time-shared, and dedicated control logic is built accordingly.
Assuming the mux, add and demux logic can fit in the desired clock period, four

cycles are needed to compute the results.
On the right-hand side, the same design is synthesized with its loop fully
unrolled. Unrolling is applied by setting a synthesis constraint and has the same
effect as copying four times the loop body. Catapult can now exploit the operation-
level parallelism to build a fully parallel implementation of the same algorithm. The
resulting architecture necessitates four adders to implement the four additions and
has a latency of one clock cycle.
Partial unrolling may also be used to trade the area, power and performance of
the resulting design. In the above example, an unrolling factor of 2 would cause
the loop body to be copied twice, and the number of loop iterations halved. The
3 Catapult Synthesis: A Practical Introduction to Interactive C Synthesis 41
Fig. 3.6 Unrolling defines how many times to copy the body of a loop
synthesized solution would therefore be built with two adders, and have a latency of
two cycles.
3.3.3.2 Loop Merging
Loop merging exhibits loops-level parallelism. This technique applies to sequential
loops and creates a single loop with the same functionality as the original loops.
This transformation is used to reduce latency and area consumption in a design by
allowing parallel execution, where possible, of loops that would normally execute
in series.
With loop merging, algorithm designers can develop their application in a very
natural way, without having to worry about potential parallelism in the hardware
implementation.
In Fig. 3.7, the code contains sequential loops. Sequential loops are very con-
venient to model the various processing stages of an algorithm. By enabling or
disabling loop merging, the designer decides if in the generated hardware, the loops
should run in parallel (merging enabled) or sequentially (merging disabled). With
this technique, the designer maintains the readability and hardware independence
of his source code. The transformation and optimization techniques in Catapult can
produce a parallelized design which would have required a much more convoluted

source description, as shown on the right-hand side.
It should also be noted in this example that Catapult is able to appropriately
optimize the intermediate data storage. When sequentially processing the two loops,
intermediate storage is needed to store the values of “a.” When parallelizing the two
loops, values of “a” produced in the first loop can directly be consumed by the
second loop, removing the need for storage.
42 T. Bollaert
Fig. 3.7 Merging parallelizes sequential loops
Fig. 3.8 Pipelining defines when to initiate the next iteration of a loop
3.3.3.3 Loop Pipelining
Loop pipelining provides a way to increase the throughput of a loop (or decreas-
ing its overall latency) by initiating the next iteration of the loop before the current
iteration has completed. Overlapping the execution of subsequent iterations of a
loop exploits parallelism across loop iterations. The number of cycles between iter-
ations of the loop is called the initiation interval. In many cases loop pipelining may
improve the resource utilization thus increasing the performance/area metric of the
design.
In example Fig. 3.8, a loop iteration consists of four operations: an I/O read
to in[i], a multiplication with coef1, an addition with coef2, and finally an I/O
write to out[i]. Assuming that each of these operations executes in a clock cycle,
and if no loop constraints are applied, the design schedule will look as shown on
the left hand side. Each operation happens sequentially, and the start of a loop
iteration (shown here with the red triangle) happens after the previous iteration
3 Catapult Synthesis: A Practical Introduction to Interactive C Synthesis 43
completes. Conceptually, the pipeline initiation interval is equal to the latency of
a loop iteration, in this case, four cycles.
By constraining the initiation interval with loop pipelining, designers determine
when to start each loop iteration, relative to the previous one. The schedule on the
right hand side illustrates the same loop, pipelined with an initiation interval of one
cycle: the second loop iteration starts one cycle after the first one.

Pipelining a design directly impacts the data rate of the resulting hardware imple-
mentation. The first solution makes 1 I/O access every four cycles, while the second
one will make I/O accesses every cycles. Some applications may require a given
throughput, therefore commanding the initiation interval constraint. Other designs
may tolerate some flexibility, allowing the designers to explore different pipelining
scenarios, trading area, bandwidth utilization as well as power consumption.
3.3.4 Hierarchical Synthesis
The proper integration of individual blocks into a sub-system is one of the major
challenges in chip design. With its hierarchical synthesis capability Catapult Syn-
thesis can greatly simplify the design and integration tasks, building complex
multi-block systems correct-by-construction.
While loop unrolling exploits instruction level parallelism and loop merging
exploits loop level parallelism, hierarchy exploits function level (task-level) paral-
lelism. In Catapult, the user can specify which function calls should be synthesized
as hierarchical units. The arguments of the hierarchical function define the data
flow of the system, and Catapult will build all the inter-block communication and
synchronization logic.
Hierarchy generalizes the notion of pipelining, allowing different functions to run
in a parallel and pipelined manner. In complex systems consisting of various pro-
cessing stages, hierarchy is very useful to meet design throughput constraints. When
pipelining hierarchical systems, Catapult builds a design were the execution of the
various functions overlap in time. As shown in Fig. 3.9, in the sequential source
code, the three functions (stage1, stage2 and stage3) execute one after the other. In
Fig. 3.9 Task-overlapping with hierarchical synthesis
44 T. Bollaert
the resulting hierarchical system, the second occurrence of stage1 can start together
with the first occurrence of stage2, as soon as first occurrence of stage1 ends.
3.3.5 Technology-Driven Scheduling and Allocation
Scheduling and allocation is the process of building and optimizing the design given
all the user constraints, including the specific clock period and target technology.

With the clock period defining the maximum register-to-register path, the tech-
nology defines the logic delay for each design operation. The design schedule is
therefore intimately tied to these clock and technology constraints (Fig. 3.10). This
is fundamental to build optimized RTL implementations, allowing efficient retar-
geting of algorithmic specifications from one ASIC process to another, or even to
FPGAs, with always optimal results.
This capability opens new possibilities in the field of IP and reuse. While RTL
reuse can provide a quick path to the desired functionality, it often comes at the
expense of suboptimal results. RTL IPs maybe reused over many years. Devel-
oped on older processes, IPs will certainly work on newer ones, but without taking
advantage of higher speeds and better densities, therefore resulting in bigger and
slower than needed implementations. In contrast, Catapult can built optimized RTL
designs from functional IPs for each process generation, taking reuse to a new level
of efficiency.
Fig. 3.10 Technology-driven scheduling and allocation
3 Catapult Synthesis: A Practical Introduction to Interactive C Synthesis 45
3.4 Case Study: JPEG Encoder
In this section we will show how a sub-system such as a JPEG encoder can be
synthesized with Catapult Synthesis.
We chose a JPEG encoder design for this case study, as we felt that the applica-
tion would be sufficiently familiar to most readers in order to be easily understood
without extensive explanations. Moreover, such an encoder features a pedagogical
mix of datapath and control blocks, giving a good overview of Catapult Synthesis’
capabilities.
3.4.1 JPEG Encoder Overview
The pixel pipe (Fig. 3.11) of the encoder can be broken down in four main
stages: first RGB to YCbCr color space conversion block, second DCT (discrete
cosine transform), third zigzag reordering combined with quantization and last, the
Huffman encoder.
3.4.2 The Top Level Function

The top level function synthesized by Catapult (Fig. 3.12) closely resembles the
system block diagram. Four sub-functions implement the four processing stages of
the algorithm. The sub-functions simply pass on arrays to each other, mimicking the
system data flow.
3.4.3 The Color Space Conversion Block
The color space conversion unit is implemented as a relatively straightforward
vector multiplication. Different sets of coefficients are used for Y, Cb and Cr
components.
Fig. 3.11 JPEG encoder block diagram