High Level Synthesis: from Algorithm to Digital Circuit- P12 pps

96 M. Meredith
• Synthesize RTL that implements the SystemC semantics that were simulated
• Use the same testbench for high-level simulation and RTL simulation
The design can comprise a single module or multiple cooperating modules. In
the case of multiple modules, the high-level SystemC simulation ensures that the
modules are operating correctly individually and working together properly. This
simulation validates the algorithms, the protocol implementations at the interfaces,
and the interactions of the modules operating concurrently.
The modules can then be synthesized, and the resulting RTL can be verified
using the same testbench that was used at the high level. This is made possi-
ble by the mixed-mode scheduling described earlier in which the algorithm is
written as untimed SystemC while the interfaces are specified as cycle-accurate
SystemC. Multiple testbench configurations may be constructed to verify various
combinations of high-level modules and RTL modules.
Single SystemC Testbench
RTL
Cynthesizer
Socket
C/C++ Algorithm
Socket
Cynthesizerincorporatesacompletedependencymanagementandprocessautoma-
tion system that automatically generates needed cosimulation wrappers and testbench
infrastructure to automate verification of multiple configurations of high-level and
RTL modules without any need to customize the testbench source code itself.
5.11 Conclusion
This chapter has outlined the synthesizable constructs of C++ and SystemC sup-
ported by the Forte Design Systems in its Cynthesizer product. It has described
specific techniques that can be used to encapsulate synthesizable communication
protocols in C++ classes for maximum reuse and techniques used to automati-
cally produce well-structured RTL for predictable timing closure. Finally, some of
5 High-Level SystemC Synthesis with Forte’s Cynthesizer 97

the user-visible mechanisms for controlling scheduling and the architecture of loop
implementation have been discussed along with a brief discussion of verification
issues automation incorporated in the Cynthesizer product.
Hopefully, this has enabled the reader to understand how SystemC synthesis with
Cynthesizer can be used to implement a broad range of functionality at multiple
abstraction levels and how the use of high-level C++ and SystemC constructs raises
the level of abstraction in hardware design.
Chapter 6
AutoPilot: A Platform-Based ESL
Synthesis System
Zhiru Zhang, Yiping Fan, Wei Jiang, Guoling Han, Changqi Yang, and Jason Cong
Abstract The rapid increase of complexity in System-on-a-Chip design urges
the design community to raise the level of abstraction beyond RTL. Automated
behavior-level and system-level synthesis are naturally identified as next steps to
replace RTL synthesis and will greatly boost the adoption of electronic system-level
(ESL) design. High-level executable specifications, such as C, C++,orSystemC,
are also preferred for system-level verification and hardware/software co-design.
In this chapter we present a commercial platform-based ESL synthesis system,
named AutoPilot
TM
offered by AutoESL Design Technologies, Inc. AutoPilot is
based on the xPilot system originally developed at UCLA. It automatically gener-
ates efficient RTL code from C, C++ or SystemC descriptions for a given system
platform and simultaneously optimize logic, interconnects, performance, and power.
Preliminary experiments demonstrate very promising results for a wide range of
applications, including hardware synthesis, system-level design exploration, and
reconfigurable accelerated computing.
Keywords: ESL, Behavioral synthesis, Scheduling, Resource binding, Interface
synthesis
6.1 Introduction

The rapid increase of complexity in System-on-a-Chip (SoC) design urges the
design community to raise the level of abstraction beyond RTL. Electronic system-
level (ESL) design automation has been widely identified as the next productivity
boost for the semiconductor industry. However, the transition to ESL design will
not be as well accepted as the transition to RTL in the early 1990s without robust
synthesis technologies that automatically compile high-level functional descriptions
into optimized hardware architectures and implementations.
P. Coussy and A. Morawiec (eds.) High-Level Synthesis.
c
 Springer Science + Business Media B.V. 2008
99
100 Z. Zhang et al.
Despite the past failure of the first-generation behavioral synthesis technology
during the mid-1990s, we believe that behavior-level and system-level synthesis
and optimizations are now becoming imperative steps in EDA design flows for the
following reasons:
• Embedded processors are in almost every SoC: With the coexistence of micro-
processors, DSPs, memories and custom logic on a single chip, more software
elements are involved in the process of designing a modern embedded sys-
tem. It is natural to use C-based languages to program software for embedded
processors. Moreover, the automated C-based synthesis allows the designer to
quickly experiment different hardware/software boundaries and explore various
area/power/performance tradeoffs using a single functional specification.
• Huge silicon capacity requires higher level of abstraction: Design abstraction is
one of the most effective methods for controlling rising complexity and improv-
ing design productivity. For example, the study from NEC [10] shows that a
1M-gate design typically requires about 300K lines of RTL code, clearly beyond
what can be handled by a human designer. However, the code density can be
improved by more than 7X when moved to the behavior level. This results in a
human-manageable 40K lines of behavioral description.

• Verification drives the acceptance of SystemC: Transaction-levelmodeling (TLM)
with SystemC [2] has become a very popular approach to system-level verifica-
tion [8]. Designers commonly use SystemC TLMs to describe virtual software/
hardware platforms, which serve three important purposes: early embedded
software development, architectural modeling and functional verification.
The wide availability of SystemC functional models directly drives the needs
for SystemC-based synthesis solutions, which automatically generate RTL code
through a series of formal constructive transformations. This avoids the slow and
error-prone manual process and simplifies the design verification and debugging
effort.
• Accelerated computing or reconfigurable computing needs C/C++ based
compilation/synthesis to FPGAs: Recent advances in FPGAs have made recon-
figurable computing platforms feasible to accelerate many high-performance
computing (HPC) applications, such as image and video processing, financial
analytics, bioinformatics, and scientific computing applications.
Since HDLs are exotic to most application software developers, it is essential
to provide a highly automated compilation/synthesis flow from C/C++ language
to FPGAs.
In this chapter we present a platform-based ESL synthesis system named
AutoPilot
TM
, offered by AutoESL Design Technologies, Inc. AutoPilot is capable
of automatically generating efficient RTL code from an untimed or partially timed
C, C++ and SystemC description for the target hardware platform. It performs
platform-based behavioral and system synthesis, tightly integrates with a modern
leading-edge C/C++ compiler, and embodies a class of novel, near-optimal, and
highly-scalable synthesis algorithms.
6 AutoPilot: A Platform-Based ESL Synthesis System 101
The synthesis technology was originally developed in the UCLA xPilot sys-
tem [5], and has been licensed by AutoESL for the commercialization. In its current

stage, AutoPilot exhibits the following key features and advantages:
• Unified C/C++/SystemC design flow: AutoPilot accepts three kinds of stan-
dard C-based design entries: C, C++ and SystemC. It also supports a variety
of abstraction models including pure untimed functional model, partially timed
transactional model, and fully timed behavioral or structural model. The broad
coverage of languages and abstraction models allows AutoPilot to target a
wide range of applications, including hardware synthesis, system-level design
exploration and high-performance reconfigurable computing.
• Utilization of state-of-the-art compiler technologies: AutoPilot incorporates a
leading-edge commercial-strength C/C++ compiler in the synthesis loop. Many
state-of-the-art compiler techniques (intra-procedural and inter-procedural) are
utilized to analyze, transform and aggressively optimize the input behaviors.
• Platform-based and implementation-aware synthesis: AutoPilot takes advantage
of the target platform information to carry out more informed synthesis and opti-
mization. The timing, area and power for the available computation resources
and communication interfaces are all characterized.
In addition, AutoPilot has tight integration with several downstream RTL
synthesis and physical synthesis tools to assure better quality-of-result and higher
degree of automation.
• Interconnect-centric and power-aware optimization: AutoPilot is able to generate
an optimized microarchitecture with consideration of the on-chip interconnects
at the high level and maximize both data locality and communication locality to
achieve faster timing and power closure. Furthermore, it can carry out aggressive
power optimization using fine-grain clock gating and power gating.
The reminder of this paper is organized as follows: Sect. 6.2 presents an overview
of the AutoPilot design flow. Sections 6.3 and 6.4 briefly discuss the system front-
end and highlight the synthesis engine, respectively. The preliminary experimental
results are reported in Sect. 6.5.
6.2 Overall Design Flow
The overall design flow of the AutoPilot synthesis system is shown in Fig. 6.1.

AutoPilot accepts synthesizable C, C++, and/or SystemC as input and performs
four major steps to generate the cycle-accurate RTLs, which includes compilation
and elaboration, advanced code transformation, core behavioral and communication
synthesis, and microarchitecture generation.
In the first step the behavioral description is parsed by a GCC-compatible front-
end compiler, with the extensions to handle the bit-accurate integer data types. For
SystemC designs, elaboration will be invoked to extract processes, ports, channels,
and interconnection topologies and construct a detail-rich system-level synthesis
data model.
102 Z. Zhang et al.
C/C++/SystemC
C/C++/SystemC
Timing/Power/
Timing/Power/
Layout Constraints
Layout Constraints
RTL SystemC &
RTL SystemC &
RTL HDLs
RTL HDLs
Platform
Models
ASICs/FPGAs
ASICs/FPGAs
Implementation
Implementation
=
Simulation
Compilation &
Compilation &

Elaboration
Elaboration
Advance Code
Advance Code
Transformation
Transformation
Behavioral & Communication
Behavioral & Communication
Synthesis and Optimizations
Synthesis and Optimizations
AutoPilot
TM
Common Testbench
User Constraints
User Constraints
ESL Synthesis
Design Specification
Microarchitecture
Microarchitecture
Generation
Generation
Verification
Fig. 6.1 AutoPilot
TM
design flow
On top of the synthesis data model, AutoPilot applies a set of advanced code
transformations and analyses to optimize the input behavior, including traditional
compilation techniques such as constant propagation and dead code elimination, and
hardware-specific passes such as bitwidth analysis and optimization. The AutoPilot
front-end will be discussed in Sect. 6.3.

The code transformation phase is followed by the core hardware synthesis phase.
AutoPilot performs platform-based synthesis and interconnect-centric optimizations
during scheduling and resource binding; these take into account the user-specified
frequency/latency/throughput/resource constraints and generate optimized microar-
chitectures. We shall discuss more details of the synthesis engine in Sect. 6.4.
At the back-end, AutoPilot outputs RTL VHDL/Verilog code together with con-
straint files (e.g., multicycle path constraints, physical location constraints, etc.) to
leverage the existing logic synthesis and physical design toolset for final imple-
mentation on either ASICs or FPGAs. It is worth noting that RTL SystemC code
is also generated, which can be directly compiled and simulated with the original
C/SystemC test bench to verify the correctness of the synthesized RTLs.
6.3 AutoPilot Front-End
In this section we discuss three major aspects of the AutoPilot front end, i.e., the
language support, compiler optimizations, and the platform modeling.
6 AutoPilot: A Platform-Based ESL Synthesis System 103
6.3.1 Language Coverage
6.3.1.1 C/C++ Support
AutoPilot has a broad coverage of the C and C++ language features. It provides
comprehensive support for most of the commonly-used data types, operators, struct/
class constructs, and control flow constructs. Due to the fundamental difference
between the memory models of software and hardware, AutoPilot currently dis-
allows the usage of dynamic pointers, dynamic memory allocations, and function
recursions.
Designers can fully control the data precisions of a C/C++ specification. AutoPi-
lot directly supports single and double precision floating-point types. In addition, it
adds the capabilities (compared to xPilot) in compiling and synthesizing bit-accurate
fixed-point data types, for which standard C and C++ language lack native support.
• Arbitrary-precision integer (APInt) data types: The user can specify that an inte-
ger type’s precision (bit width) is any number of bits up to eight million. For
example, int24 declares an 24-bit signed integer value. Constant values will be

zero or sign extended to the indicated bit width if necessary.
• Arbitrary-precision fixed point (APFixed) data types: AutoPilot provides a syn-
thesizable templatized C++ library, named APFixed, for the designer to describe
fixed-point math. APFixed library implements the common arithmetic routines
via operator overloading and supports the standard quantization and saturation
modes.
• IEEE-754 standard single and double precision floating point data types are fully
supported in AutoPilot for FPGA platforms. Common floating-point math rou-
tines (e.g., square root, exponentiation, logarithm, etc.) can be also synthesized.
6.3.1.2 SystemC Support
AutoPilot fully supports the OCSI synthesizable subset [1] for the SystemC
synthesis.
Designers can make use of SystemC bit-accurate data types (i.e., sc
int/sc uint,
sc
bigint/sc biguint,andsc fixed/sc ufixed) to define the data precisions. Multi-
module hierarchical designs can be specified and synthesized with the SC
MODULE
constructs. Within each module, multiple concurrent processes can be declared with
the SC
METHOD and SC CTHREAD constructs.
6.3.2 Advanced Code Transformations
A variety of compiler optimization techniques are applied to the behavioral descrip-
tion code with the objective to reduce the code complexity, maximize the data
locality, and expose more parallelism. The following transformations and analyses
104 Z. Zhang et al.
are particularly instrumental for AutoPilot hardware synthesis.
• Traditional optimizations such as constant propagation, dead code elimination,
and common subexpression elimination that avoid functional redundancy.
• Strength reductions that replace expensive operations (e.g., multiplications and

divisions) with simpler low-cost operations (e.g., shifts, additions and subtrac-
tions).
• Transformations such as if-conversion and tree height reduction that explicitly
expose fine-grain operator-level parallelism.
• Coarse-grain code restructuring by loop transformations such as loop unrolling,
loop flattening, loop fusion, etc.
• Analyses such as bitwidth analysis, alias analysis, and dependence analysis that
help to reduce the data widths and analyze the data and control dependences.
These transformation are either performed locally within the function bodies, or
applied intraprocedurally across the function call hierarchy.
6.3.3 Platform Modeling
AutoPilot takes full advantage of the target platform information to carry out more
informed synthesis and optimization. The platform specification describes the avail-
abilities and characteristics of the important system building blocks, including the
on-chip computation resources and the selected communication interfaces.
Component pre-characterization is involved in the modeling process. Specifi-
cally, it characterizes the delay, area, and power for each type of hardware resource,
such as arithmetic units (e.g., adders and multipliers), memories (e.g., RAMs,
ROMs and register files), steering logic (multiplexors), and interface logics (e.g.,
FIFOs, and bus interface adapters). The delay/area/power characteristic functions
are derived by varying the bit widths, number of input and output ports, pipeline
intervals and latencies, etc. To facilitate our interconnect-centric synthesis. The het-
erogeneous resources distribution map and the distance-based wire delay lookup
tables are also constructed.
AutoPilot greatly extends the platform modeling capabilities in xPilot. It can sup-
port advanced ASIC process (e.g., TSMC 90 and 65 nm technologies), a wide range
of FPGA device families (e.g., Xilinx Virtex-4/Virtex-5, Altera Stratix II/Stratix
III) and various accelerated computing platforms (e.g., Nallatech [4] and XDI [3]
acceleration boards).
6.4 AutoPilot Hardware Synthesis Engine

This section highlights several important features of the AutoPilot synthesis engine,
including scheduling, resource binding, pipelining, and interface synthesis.
6 AutoPilot: A Platform-Based ESL Synthesis System 105
6.4.1 Scheduling
An efficient and versatile scheduler is implemented in the AutoPilot system to
exploit parallelism in the behavior-level design and determine the time at which
different computations and communications are performed. The core scheduling
algorithm is based on a mathematical programming formulation. It has significant
advantages over the prior approaches in two major aspects:
• Versatility: Our scheduler is able to model a rich set of scheduling constraints
(including cycle time constraint, latency constraints, throughput constraint, I/O
timing constraints, and resource constraints) in the constraint system, and express
different performance metrics (such as worst-case and average-case latency)
in the objective function. Moreover, several important synthesis optimizations
such as operation chaining, structural pipelining, behavioral template, slack
distribution, etc., are all naturally encoded in a single unified mathematical
framework.
• Efficiency and scalability: Our scheduler is highly efficient and scalable when
compared to the other constraint-driven approaches. For instance, typical ILP
formulations uses discrete 0–1 variables to model the assignment relationships
between operations and time steps, this requires lots of variables and complex
equations to express one scheduling constraint since all feasible time steps should
be considered. In our formulation, variables directly represent operation execu-
tion time and are independent of the final schedule latency. This leads to much
more compact constraint system, and the mathematical programming model can
be efficiently solved in a few seconds for very complex designs, as evidenced by
the Xilinx MPEG-4 design (to be discussed in Sect. 6.5).
The first generation of our scheduler was based on the SDC-based scheduling
algorithm and the technical details are available in [7].
6.4.2 Resource Binding

Resource binding determines the numbers of functional units and registers, and the
sharing among compatible operations and data transfers. It has a dramatic impact
on the final design quality as they determine the interconnection network with wires
and steering logic.
AutoPilot is capable of providing optimized binding for various functional units
and memory blocks, such as integer and floating-point arithmetic units, transcen-
dental functions, black-box IP blocks, registers, register files, RAMs/ROMs, etc.
AutoPilot’s binding algorithm can also generate different microarchitectures. For
example, it has an option to generate a distributed register-file microarchitecture
(DRFM) to optimize both data and communication localities.
DRFM has a semi-regular structure which consists of one or multiple islands.
As illustrated in Fig. 6.2, each DRFM island contains a local register file (LRF),
106 Z. Zhang et al.
Island A
Data-
Routing

Logic
Local
Register
File
FUP MUX
Island B
Functional Unit Pool
MUL
AL
AL
Island C
Island D

Input
Island E
Island F
Fig. 6.2 Distributed register-file microarchitecture
a functional unit pool (FUP), and data-routing logic. The LRF serves as the local
storage in an island. Each register file allows a variable number of read ports but
only a fixed number (typically one) of write ports. The LRF stores the results pro-
duced from the local computation units in FUP and provides data to both local FUP
and the external islands. By clustering LRF and FUP into a single island, we are
able to maximize both data/computation locality and communication locality. This
also helps us avoid, to a large extent, the centralized memory structures and global
communications which often become the bottlenecks limiting system efficiency in
performance, area, and power.To handle the necessary inter-island communications,
we use the data-routing logic to route data from the external islands.
DRFM is a semi-regular microarchitecture. The configurations of the LRF, FUP
and the data-routing logic are application-specific. One important objective that
DRFM-based resource binding tries to minimize is the inter-island connections.
This will simplify the data-routing logic in each island and reduce the overall
complexity of the resulting datapath.
The technical details of the DRFM-based resource binding algorithm are avail-
able in [6].
6.4.3 Pipelining
AutoPilot’s synthesis engine (during scheduling, resource binding, and microar-
chitecture generation) supports several forms of pipelining to improve the system
performance.