Compiler-enabled Hardware Accelerators

Xiaochu LiuDepartment of Computer Science and

EngineeringUniversity of California San Diego

La Jolla, California 92092Email: xil174@eng.ucsd.edu

Abstract—Hardware accelerators are first-class building blocksin modern computing devices. Ranging from data centersto mobile devices, hardware accelerators are designed anddeveloped in order to run certain applications more efficiently.The interaction between hardware accelerator design andcompiler support has continued to become critical in orderto make systems more efficient. In this report, I will describekey efforts in hardware accelerators and their philosophy forinteracting with compilers. Then I will describe my currentwork in building tools to generate and integrate hardwareaccelerators automatically.

1. INTRODUCTION

Chip technology scaling is now a limiting factor of thehardware system efficiencies [1], [2], [3], [4]. Previouslyin classical scaling era, as the transistor size shrinks, thepower to drive more transistors on the same chip area doesnot change [5]. Hence the frequency is increased for free.However in the leakage scaling era (where we are rightnow), the threshold voltage (Vt) does not shrink which stopsthe supply voltage (Vdd) from shrinking any more (refer toTable 1). Given a constraint of the supply power of the chip,only part of the chips can be actively switched on and offat the same time. The other portions that have to be offdue to the limitation of supply power are idle chip areaand are referred to as dark silicon. Trading the dark siliconfor hardware accelerators generally is a profitable choice interms of reducing power consumption.

Hardware accelerators are common building blocksnowadays. In addition to specialized Functional Unit likeFloating-point Unit, Intel processors added AVX for vectorprocessing and AES-NI for cryptography encryption oper-ations [6], [7]. ARM has instructions set extension to sup-port AES encrypt/decrypt and advanced SIMD (NEON) formapping into hardware accelerators [8]. ARM also supportsco-processor (hardware accelerators) integration by physi-cal register mapping. GPUs are essentially large externalaccelerators to perform intensive parallel tasks. The latestApple A9 chip has M9 motion coprocessors as an acceler-ator to gather data from sensors (accelerometer, gyroscope,compass, and barometer) or even receive Siri commands

Param. Description Relation Classicalscaling

Leakagescaling

B power budge 1 1A chip size 1 1Vt threshold voltage 1/S 1Vdd supply voltage Vt 1/S 1tox oxide thickness 1/S 1/SW, L transistor dimen-

sion1/S 1/S

Isat saturation current WVdd/tox 1/S 1p device power Isat Vdd 1/S2 1Cgate capacitance WL/tox 1/S 1/SF device frequency Isat

CgateVddS S

D device per chip A/(WL) S2 S2

P power D× p 1 S2

U utilization B/P 1 1/S2

Table 1: Technology scaling table [3].

[9]. Adding hardware accelerators becomes the consensus inindustry and academia to increase system efficiency facingthe problem of dark silicon.

These hardware accelerators can be built as extensionsfor CPUs/GPUs through either ASIC (Application SpecificIntegrated Circuit) or FPGA (Field-programmable Gate Ar-ray). CPUs and GPUs themselves are general-purpose andtrading efficiency for flexibility. For CPUs, the parallelismand memory bandwidth are limited. GPUs have a massiveamount of parallelism, however they are power hungry andshow variant performance for different domains. Accelera-tors built in ASIC or FPGA can remedy the shortcomingsof CPUs and GPUs. Though ASIC requires higher designand manufacture costs, it can be specialized for high per-formance and low power for a particular application. Sinceit is rare to do any change after computations are hardenedinto ASIC, flexibility of designs becomes very importantfor domain-specific ASIC accelerators. FPGA is less energyefficient than ASIC but is re-programmable which lowers thecost and provides an approach to prototype the hardwarebefore the actual manufacturing.

High-Level Synthesis (HLS) converts programs writtenin high-level programming languages into hardware writtenin Hardware Descriptive Languages (HDL). It automatesthe process of hardware designing by shifting the burden

of hardware design to its software counterpart. SeveralHLS tools are available in production or research proto-types - BlueSpec, Catapult C, C-To-Silicon, LegUp, Vivado[10], [11], [12], [13], [14]. The generated hardware can bemapped to FPGA or ASIC. Leveraging HLS tools to gen-erate hardware accelerators and integrate them into systemscan significantly reduce the design efforts.

This report explores the design decision of recent keyhardware accelerator-based systems and focuses on theircompiler aspects. Compiler aspects of these efforts are syn-thesized. These accelerators are divided into three categoriesbased on their compiler aspects - ISA-based, configuration-based ,and automatically generated. A brief introduction ofmy current work of generating and integrating hardwareaccelerators automatically is also presented in the end.

The rest of the report is organized as following. InSection 2, 3, 4, designs of recent key hardware accelerator-based architectures are described and the compiler aspectsare summarized. In Section 5, my recent works on buildingtools to generate hardware accelerators for irregular code areintroduced. In Section 6, conclusions and future directionsof compiler aspects of hardware accelerators are shown.

2. ISA-based accelerators

Firstly, recent key efforts in ISA-based hardware ac-celerators are described. They serve various domains andhave certain ways of ISA designs inside. The ISA designstarget for high flexibility while maintain specializations ofthe hardware accelerator. I summarize the design decisionson compiler aspects at the end of this section.

2.1. Large-scale neural network accelerator

Diannao is a hardware accelerator targeting large-scaleCNNs (Convolutional Neural Networks) and DNNs (DeepNeural Networks) [15], [16], [17]. It focuses on increasingthe performance and energy efficiency by reducing the run-time memory footprint. Diannao hardware accelerator issynthesized into hardware designs in order to benchmarkthe hardware for the power numbers.

Diannao is designed for large-scale CNNs and DNNs.For small-scale neural networks, memory is only used tostore input and output result. All the neurons and synapsesare hardened in the accelerators which minimizes the execu-tion and communication overhead between neurons. How-ever, this low-overhead design does not scale since a largeneuron network will take too much hardware die area. Ascalable design should involve memory access in the middleof a large neural network.

A Diannao accelerator for large-scale CNNs and DNNsincludes input/output neuron buffer (NBin, NBout), synapticweights buffer (SB) and a Neural Functional Unit (NFU)along with control logic. It decomposes a large neuralnetwork layer into blocks which maps to stages in the NFU.Input neuron buffers issue DMA requests to memory cache.It supports rotations which makes the reuse of neurons toavoid reloading the same neurons again and again.

input

neuron

synapse

weight'

*'

neuron output

+'

synapses *'

+'

table'

x

x

ai bi

hidden layer

output layer

Figure 9. Full hardware implementation of neural networks.

8x8 16x16 32x32 32x4 64x8 128x16

01

23

45

Critical Path (ns)Area (mm^2)Energy (nJ)

Figure 10. Energy, critical path and area of full-hardware layers.

neuron to a neuron of the next layer, and from one synap-tic latch to the associated neuron. For instance, an executiontime of 15ns and an energy reduction of 974x over a corehas been reported for a 90-10-10 (90 inputs, 10 hidden, 10outputs) perceptron [38].

4.2 Maximum Number of Hardware Neurons ?However, the area, energy and delay grow quadratically withthe number of neurons. We have synthesized the ASIC ver-sions of neural network layers of various dimensions, andwe report their area, critical path and energy in Figure 10.We have used Synopsys ICC for the place and route, and theTSMC 65nm GP library, standard VT. A hardware neuronperforms the following operations: multiplication of inputsand synapses, addition of all such multiplications, followedby a sigmoid, see Figure 9. A Tn ⇥ Ti layer is a layer of Tn

neurons with Ti synapses each. A 16x16 layer requires lessthan 0.71 mm2, but a 32x32 layer already costs 2.66 mm2.Considering the neurons are in the thousands for large-scaleneural networks, a full hardware layout of just one layerwould range in the hundreds or thousands of mm2, and thus,this approach is not realistic for large-scale neural networks.

For such neural networks, only a fraction of neurons andsynapses can be implemented in hardware. Paradoxically,this was already the case for old neural network designs

Tn#

NBin%

SB%

NFU)1%

Mem

ory#Interface#

NFU)2% NFU)3%

Inst.#

DMA#

DMA# Inst.#

Tn#x#Tn#

NBout%

Control#Processor#(CP)#

Instruc:ons#

Inst.#

DMA#

Tn#

Figure 11. Accelerator.

such as the Intel ETANN [18] at the beginning of the 1990s,not because neural networks were already large at the time,but because hardware resources (number of transistors) werenaturally much more scarce. The principle was to time-share the physical neurons and use the on-chip RAM tostore synapses and intermediate neurons values of hiddenlayers. However, at that time, many neural networks weresmall enough that all synapses and intermediate neuronsvalues could fit in the neural network RAM. Since this is nolonger the case, one of the main challenges for large-scaleneural network accelerator design has become the interplaybetween the computational and the memory hierarchy.

5. Accelerator for Large Neural NetworksIn this section, we draw from the analysis of Sections 3 and4 to design an accelerator for large-scale neural networks.

The main components of the accelerator are the fol-lowing: an input buffer for input neurons (NBin), an out-put buffer for output neurons (NBout), and a third bufferfor synaptic weights (SB), connected to a computationalblock (performing both synapses and neurons computations)which we call the Neural Functional Unit (NFU), and thecontrol logic (CP), see Figure 11. We first describe the NFUbelow, and then we focus on and explain the rationale for thestorage elements of the accelerator.

5.1 Computations: Neural Functional Unit (NFU)

The spirit of the NFU is to reflect the decomposition ofa layer into computational blocks of Ti inputs/synapses andTn output neurons. This corresponds to loops i and n forboth classifier and convolutional layers, see Figures 5 andFigure 7, and loop i for pooling layers, see Figure 8.

Arithmetic operators. The computations of each layertype can be decomposed in either 2 or 3 stages. For classifierlayers: multiplication of synapses ⇥ inputs, additions of all

Figure 1: Diannao system architecture [15].

2.2. Convolution-operation accelerator

Convolution Engine (CE) is a customized hardware ac-celerator for convolution-operation composed of map andreduce [18]. Using SIMD machines to compute convolutionsneeds many registers (quadratic to the size of the block).GPGPUs increase performance by 10 times comparing withSIMD machine but cost 100 times more energy [19]. CE isdesigned to perform this computation pattern efficiently byreducing the unnecessary operations.

Convolution pattern is widely used in computationalphotography, image and video processing. A standard dis-crete 2-dimensional convolution has a general formula assuch:

(Img × f)[n,m] =

∞∑l=−∞

∞∑k=−∞

Img[k]× f [n− k,m− l]

(1)Function f is a filter and Img is a mapping from location

to pixel values. It contains map (the product of filter func-tion and pixels) and reduce (summation of all the products)operation. Abstracting the two operations to a more generalformat:

(Img × f)[n,m] =

R|l|<c{R|k|<c{Map(Img[k], f [n− k,m− l])}} (2)

CE consists of Interface Unit (IF), shift registers, ALUsand reduce logic. The IF facilitates load/store values toand from register files, preparing values in register files forALUs. The ALUs are multiple sets of array of ALUs (multi-pliers, adders, etc.). The reduce logic contains a InstructionGraph Fusion/Multi-level reduction tree in order to make itmore flexible.

Convolution engine is designed as an extension of ISA.The programmer needs to use its provided primitives tospecify the number of map, reduce operators, co-efficients

2

and convolution size (size of input). Also the main loopto perform computations are also specified. Compiler con-figures Convolution Engine based on these primitives. Theprogramming model is simple since CE is well defined forperforming convolution operations.

2.3. Vector accelerator

HWACHA is a vector extension for RISC-V processors[20], [21], [22]. It is invoked in the commit stage in theprocessor pipeline. The vector instruction is issued to Hazardand Sequencer in HWACHA and stays there until it is ready.Then the instruction is fed into expander which breaks asingle vector instruction into bank micro-ops. Each bankhas an SRAM buffer and vector functional unit (for simpleoperations). Computation flows from one bank to the next ina systolic way. Larger functional units (integer multipliers,floating point operators) are shared across banks. RISC-Vand vector machines have separated instruction memorieswhile they share the same data memory (cache).

Based on the public source code in their compiler,vector operations are identified and mapped by compilerautomatically. The auto-vectorization compiler pass is ableto convert loop into vector primitives based on static codeanalysis. Then vector instructions are mapped to HWACHAvector instructions by the compiler backend.

2.4. Heterogeneous accelerator

Big challenges exist in building next-generation energy-efficiency chip multi-processors [23]. 10X10 is a tiled-architecture each of whose tiles includes six micro-enginesand a general-purpose RISC core [24]. The micro-enginescan be roughly divided into two categories based on theproportion of different operations (data movements or ac-tual computations)- compute-intensive and data-intensive.Compute-intensive workloads have lower requirement fordata movement bandwidth while spend most of thetime on computations. Compute-intensive engines includeBit-Nibble-Byte (BnB), Fast-Fourier-Transform (FFT) andVector-Floating-Point (VFP). BnB is a flexible SIMD vectorprocessing unit as width as 256 bytes. FFT is a widelyused operator in image, audio and digital signal processingapplications. VFP supports 2048-bit vectorized Floating-point operations. Data-intensive workloads are usually bot-tlenecked by the data movement operations. Data-intensiveengines include Sort, Data-Layout-Transformation (DLT)and Generalized-Pattern-Matching (GenPM). DLT facilitatesdata movement (scatter, gather) among main memory andlocal memory. GenPM is designed for Finite-State Machinebased applications. Sort is an universal algorithm in manyapplications. The micro-engines share the same L1-data andL2-unified cache. Each micro-engine has customized in-struction designed for easy integration and programmability.

The compiler invokes each micro-engine by the ISAextensions provided by each micro-engine. The instructionsof each micro-engine include both data movement and actualprocessing which helps improve communication efficiency.

Fig. 1: 10x10 Chip includes tiled 10x10 cores; each is a federation of Micro-engines.

II. FEDERATED HETEROGENEOUS 10X10 ARCHITECTURE

A. 10x10 Core

A 10x10 architecture (Figure 1) employs workload-drivenco-design to customize a set of micro-engines for energyefficiency, and then federates them to achieve general-purposecoverage. Current 10x10 micro-engines are classified as 1)compute-intensive (BnB, FFT and VFP) micro-engines and 2)data-intensive (DLT, GenPM and Sort). The 7th micro-engineis a conventional RISC core.

A 10x10 core includes a federated set of micro-engines shar-ing local memory, L1 data-cache, L2-unified (Figure 1). Eachmicro-engine uses customized instructions, tightly integratedso as to to accelerate at fine-grain. Each micro-engine has itsown general purpose and vector registers, and only one micro-engine executes at a time. Unlike traditional accelerators,the customized micro-engines are tightly coupled, sharing anL1 data cache and local memory. Switching between micro-engines is achieved with a special instruction (under softwarecontrol), that transfers to a different micro-engine. All stateneeded is passed through the caches and local memory. Theprogram exists as a single image in memory, but as a collectionof each micro-engines specialized instruction sequences.

Table I shows the intrinsics for each micro-engine’s customoperations. The micro-engines and their ISA are described indetail in Sections 2.2 and 2.3.

B. Compute-Intensive Micro-engines

1) BnB micro-engine: Transistor density scaling enableswide SIMD vector architectures that can increase both com-putation throughput and energy efficiency of streaming appli-cations. The BnB [8] micro-engine is a fine-grain wide SIMDarchitecture that processes as many as 256 one-byte elementswith one instruction.

The BnB micro-engine includes sixteen 32-bit scalar andsixteen 2048-bit vector registers, supporting typical vectorinstructions (data movement, logic, and fixed point operations(Table I)). Furthermore, the BnB micro-engine supports 4, 8,16, 32, 64, 128 bit element sizes, significantly more flexiblethan SSE (8, 16, 32 bits), and as a result offers higherperformance for “short-data” (< 8 bits) computations namelyencryption (AES), compression (Run Length Encoding), etc.

The BnB micro-engine is often partnered with other micro-engines such as DLT and VFP to improve performance, energyefficiency and workload coverage. Finally, we are workingin an compiler implementation that support compilation ofOpenCL code into C code with BnB intrinsics.

2) Fast Fourier Transform Micro-engine: Fast FourierTransform (FFT) is essential kernel for applications involvingimage, audio, and digital signal processing. It motivates designand integration of an FFT micro-engine in 10x10 to provideprogrammability and energy-efficiency [9]. The FFT computekernel is an optimized custom logic and associated storagestructure generated by Spiral [10] and tightly-integrated intothe pipeline for high programmability.

The FFT micro-engine computes on 64 complex points (16-bit integer real and imaginary 2) in 16 cycles, replacing alarge number of compute and memory instructions with asingle instruction, thereby significantly improving performanceand energy efficiency. The input data of FFT micro-engine isloaded from local memory into vector registers. DLT can beused to move data efficiently from off-chip memory to localmemory, and transpose data in local memory. The ISA of FFTmicro-engine (Table I) can be used to program and acceleratelarger FFTs with low software overhead.

3) Vector Floating Point Micro-engine: Floating point num-bers provide high-dynamic range, error-tolerance, and easyprogramming, compared to fixed point. While the cost offloating point in terms of silicon area and power is decreasingin advanced CMOS process, the VFP micro-engine enablesfloating point applications (e.g. inner-product) to execute withhigh performance on a 10x10 heterogeneous system.

The VFP micro-engine is an 2048-bit wide SIMD ar-chitecture that computes 64 addition or multiplications ofsingle precision (IEEE-754) floating point values in a singleinstruction, to deliver 64 to 256 GFLOPS in 32nm and 7nmprocesses respectively. Like other micro-engines, VFP getsoperands from a 16 entry, vector register file, and is tightlycoupled to enable efficient acceleration of small stretches ofcomputation.

2In [11], we have evaluated and compared relative energy of using 32-bitfloating and fixed point FFT accelerators.

ACM SIGARCH Computer Architecture News 3 Vol. 43 No. 2 May 2015

Figure 2: 10x10 tiled architecture [24].

Each instruction is built in the compiler as intrinsics. Pro-grammers interact with the micro-engines in a fine-grainedway by calling intrinsics.

2.5. Video processing accelerator

This ASIC design improves energy efficiency byalgorithm-specific optimizations [19]. Other than designingenergy-efficient CPUs [25], it attempts to create customizedASIC using new approaches. It uses an extensible processor-based fully chip multiprocessor generator to explore the de-sign space. [26] Five functions are extensively used in H.264application. Integer Motion Estimation (IME) matches eachimage block to a previous image to represent the motion.Fractional Motion Estimation (FME) refines the result fromIME. Intra Prediction (IP) produces a prediction for cur-rent block based on predictions of its neighbouring blocks.Transformation and Quantization (DCT/Quant) generatescoefficients for an image block to construct the pixels. Con-text Adaptive Binary Arithmetic Coding (CABAC) encodesthese coefficients from previous stage. The ASIC is designedto pipeline these functions into customized logic stages. Theoptimizations on each stage focus on three aspects and eachof which is done on register file, instruction decoding anddata path. Firstly, SIMD and precision is customized forparallelism. Secondly, instruction fusion for better instruc-tion density. Thirdly, operations are grouped into blocksfor better instruction density. After these optimizations, theoverhead of instruction fetch and register file access ingeneral-purpose CMP are removed entirely.

This architecture is generated based on Tensilica’s com-piler. Tensilica’s TIE language is used to customize memoryparameters and datapath. The ISA extension allows to spec-ify VLIW slots, SIMD width, register file and instructionextensions. The TIE language generates intrinsics automat-ically for customized instructions (if any). Original algo-rithms can be adapted to call these intrinsics to leverage ISAenhancement in addition to architectural benefits directly.

2.6. Database accelerator

Data Processing Unit (DPU) is a pipelined architecturedesigned for handling data processing requests (queries) [27]

3

[28]. It designs an Instruction Set Architecture (ISA) andexplores the design space of the implementation of architec-tures. The architecture contains eleven tiles for performingeleven data-processing related operations. The partitionersplits large table into smaller ones. The joiner performsinner-join operation of two tables. The ALU performs op-erations on two SIMD column registers to produce onecolumn register. The boolGen compares a column with aconstant and generates a new column for the result. Thecolumnfilter takes a column and a bool column as inputand produces a new column with rows ruled out based onthe bool column. The aggregator achieves The columnselector and stitcher extracts columns from a table oraggregates columns into a table. The column concatenatorconcatenates two columns into a new column with entriesfrom both columns. The appender appends one table toanother table with the exact same schema. Memory is usedfor communication among tiles (storing temporary result andfinal result).

DPU is used for data processing and so does its pro-gramming model. Programmers have to program each queryusing assembly instructions since it does not have compileror parser to parse the queries written in Structure Query Lan-guage (SQL). The benchmark (TPC-H) has to be modifiedin order to satisfy the hardware constraints.

2.7. Analysis

The accelerators described above have different consid-erations for ISAs. Diannao has blurring interface to thecompiler. The input, output and intermediate results arestored in scratchpad memory. ControlPath (CP) supports 5control instructions to issue DMA request to buffers andperform arithmetic computations on NFU. These instruc-tions can control the topology of the Neural Networks.These instructions have to be hand-coded and stored inan SRAM attached with the CP. Convolution engine addsinstruction set extensions and leverages compiler intrinsicsto use these extensions. The intrinsics are most essentially aone-to-one mapping from programming language constructsto architecture instructions. Configuration instructions areused to set the size of the kernel and ALU operationtypes. Load/store instructions are used to orchestrate datamovement between the appropriate register files and mem-ory. Convolution instructions are used to perform actualconvolutions on the data in the register files. HWACHA usesintrinsic-style approaches (like convolution engine). 10X10uses another intrinsic-style approaches. But it uses TensilicaLISA compiler to ease the development. DPU designs anISA but applications are hand coded without query compil-ers. Each dynamic instruction of the ISA corresponds to aninstance of one type of tile (accelerator). H.264 uses anotherintrinsic-style approaches. It uses Tensilica TIE compiler togenerate hardware ISA-extensions and compiler intrinsicsfor programmers to use.

ISA-based accelerators borrow the design wisdom fromgeneral-purpose processors. These accelerators have a de-coder in the accelerator (DianNao) or share the decoder

of the host processors (10x10). Instructions are stored ininstruction memories (host processor’s instruction memoryor small DRAMs attached to the accelerators). Domain-specific computations (SQL, etc.) need no support for com-plex control flow (Q100). Arbitrary computations (C++, etc.)needs support for arbitrary instruction jumping and it canbe built as ISA extensions of host processors (ConvolutionEngine). In the case of ISA extension, the acceleratorsneed no initialization (configuring computations) time. Inthe other case of stand-alone ISA, the accelerators still haveto spend the time to be initialized with instructions. ISA-based accelerators can only perform operations whateverISA supports.

3. Configuration-based accelerators

In this section, another category of hardware accelera-tors - configuration-based accelerators are described. Theytarget different application domains and leverage differentdomain knowledge and technologies for the configurations.I summarize the design decisions on compiler aspects at theend of this section.

3.1. Dynamically configurable accelerator

Dynamically Specializing Execution Resources(DySER) is a hardware accelerator integrated withan out-of-order processor pipeline [29]. It achievesspecialization in both functionality and parallelism.Functionality specialization has dedicated datapath forcertain functions [30], [31], [32], [33], [34]. DySER usesan array of heterogeneous functional units with configurableswitch in order to achieve functionality specialization. Sucha design eliminates the decode, fetch, commit, registerfile read/write for any instruction otherwise executed in aprocessor by combining sequences of instructions togetherinto a big operation. A valid-credit system is used in aDySER to support pipelined execution. In order to achieveparallelism in DySER, a few compiler optimizations areapplied to the original code. Loop unrolling (UNR) andscalar expansion (SCX) are used to grow the parallel coderegion when the code region is too small to fully utilize theDySER. Subgraph mapping is used to break large regionsinto smaller ones to fit into a DySER. Strip-mining (STR)and Vector port mapping (VEC) are used to vectorize theDySER communication.

The compiler plays the role of optimizing and generatingthe DySER configurations. It first performs transformationson the code to increase its parallelism. Then it identifies theregion of code and generates DySER configurations out ofit. Finally the communication instructions are filled in theoriginal code to configure and invoke DySER.

3.2. General-purpose neural networks accelerator

This particular system includes programming languagesupport [35], compiler, NPUs (neural processing units), and

4

the interface between host processor and the NPUs [36].Neural networks are found to be very useful in emulatingimperative code on software as well [37]. The program-ming language and compilation framework train the neuralnetworks and transform the original code to take advantageof this neural network. The host processor which has thenon-approximate part of the program running on it invokesthe NPUs by special instruction set extensions.

The programming model allows the programmers tohave total control over the approximation. The approximatepart has to be hot code otherwise the overhead of invokingNPU might contradict the benefit it brought in. The targetis annotated by programmers as the potential approximatepart. The compiler can test output quality of each of theannotated parts to decide whether to approximate it or not.The annotated part has to be pure which means no functioncall or global data access is allowed. The input and outputsize has to be fixed and known. Pointer input is transformedinto the data it points to and size of which is fixed andknown.

In order to train the neural networks, training data iscollected for the annotated kernel. The compiler instrumentsthe annotated functions and records the input-output pairsof executions given training data. An MLP (multi-layer per-ceptron) model is trained using back-propagation algorithmon the recorded data. The compiler generates a configurationfor the NPU and instructions to invoke it in the main pro-gram. The configuration contains topology parameters andweights. The NPUs are configured by compiler generatedconfigurations and the main program invokes them whenthey run into the annotated functions.

Annotated source code

Imperative source code

Trained neural networks

Training inputs

Instrumented CPU binary

NPU config

Programmer

CPU

Trainer

Code generator

CPU NPU

Figure 3: The Parrot transformation flow for NPU [36].

The system consists of NPUs that are integrated into thepipeline of the host processor. The NPU communicates withthe host processor via FIFOs. Three FIFOs were used forsending/receiving the configurations of NPUs, sending theinput to NPUs and receiving the outputs from NPUs. Fourinstructions were added as ISA extensions to manipulatethe 3 FIFOs (enq.c, deq.c, enq.d and deq.d). The instructionscheduler treats all NPU instructions to be access to a singlearchitectural register which makes sure that all the NPUinstructions are issued in order. It issues the enqueue requestonly when the queue is not full and the dequeue request onlywhen the queue is not empty. The NPU starts executionwhen the input FIFO is full.

NPU is implemented as digital design on FPGA orASIC. Two levels of approximation is reflected by the natureof neural networks and approximated hardware circuit. Inthis particular design, each NPU has eight PEs (Process-ing engines), config FIFO, input FIFO, output FIFO andscheduling buffer. This design is determined by speeduptesting. The scheduling buffer is used to organize the ex-ecution order of each neuron which is allocated to a PE.Each PE contains weight buffer, input buffer, output bufferand a sigmoid unit which computes the activation function.

The valuation is performed on a benchmark of diversedomains. It achieves a 2.3× speedup and energy saving of3.0× with quality loss less than 10% for whole application.

3.3. Neural network SoC accelerator

SNNAP (systolic neural network accelerator in pro-grammable logic) leverages the FPGA on an SoC to ac-celerate computations that are error-tolerant using neuralnetworks [38]. FPGA has been demonstrated to be goodat accelerating certain algorithms [39]. It uses one of thetwo compilation approaches proposed to transform regionsin the source code to generate code to invoke neural networkaccelerators (with the same parameters as in the originalsource code). The software batches the invocations andsends them to the accelerators to increase their throughputdue to the latency between host processor and accelerators.Then a callback function was written to copy the result backto the host processor. The invocation is asynchronous whichmeans the execution of host processor and accelerators caninterleave.

Two compilation approaches were introduced. The firstapproach uses an approximate programming language toannotate the approximate part in the program. The annotatedpart which is usually a function is replaced with an invoca-tion to the neural processing unit instead of the original func-tion. The second approach provides a lower-level interfaceor an API for programmers to specify the communicationbetween CPU and the accelerators and the computationson accelerators. This approach uses an asynchronous modelwhere the program configures and starts the accelerator andwaits until the results come back from it. The first approachis more automatic while the second one provides more fine-grained control over how exactly CPU interacts with theaccelerators.

5

The architecture design is built based on PSoC (Pro-grammable System-on-Chips). It has a Dual Core ARMCoretex-A9 processor and an FPGA. The accelerator wasconfigured on the FPGA chip. The host processor (ARM)configures the accelerator using GPIOs (General PurposeI/Os) interface. Specifically AXI(Advanced Extensible In-terface) is used to implement DMA transfer to memorymapped-registers between ARM and FPGA. The inputs (pa-rameters) were sent to accelerator using ACP (AcceleratorCoherency Port). It allows the FPGA to request data fromhost processor’s cache. To invoke the accelerator, the hostprocessor uses ARMv7 SEV/WFE instructions.

MLP (multi-layer perceptron) neural networks is used tobe implemented as accelerator. MLP has an input, an outputand many hidden layers in between. A layer is composedof neurons and each neuron is calculated as the sum ofweights of neurons of its previous layer after an activationfunction (sigmoid often).

x0

x1

x2

x3

x4

x5

x6

x7

x8

x9

y0

y1

Input Layer Output LayerHidden Layers

Figure 4: MLP example with 2 hidden layers. x7 =sigmoid(w47 · x4 +w57 · x5 +w67 · x6), where wxy standsfor the weight on edge between x and y [38].

The accelerator hardware implements a neural networkusing systolic arrays. It contains a scheduler, bus and manyPUs (Processing Unit). Each PU has a scratchpad memory,controller, sigmoid unit and many PEs (Processing Element).One PU computes the weight product of one neuron andpasses the accumulated result to next PU for the nextneuron on the same layer. Weights are stored in BRAMs(block-RAMs) and temporary results are stored in a FIFOaccumulator until one layer is completed.

The evaluation demonstrates that SNNAP gains an av-erage of 3.8× speedup and 2.8× energy savings with a lessthan 10% error rate.

3.4. GPU neural networks accelerator

Unlike previous neural accelerators attached to CPUs,accelerators attached to GPUs have a different set of designconstraints. GPUs have more cores than CPUs and each of

x1 fx2 x30 x1’ x2

’ x3’

w21

w22

w23

.

w11

w12

w13

w31

w32

w33

.

.

𝑓𝑤11 𝑤21 𝑤31

𝑤12 𝑤22 𝑤32

𝑤13 𝑤23 𝑤33

∙𝑥1𝑥2𝑥3

= (𝑥1′𝑥2′𝑥3′

)

(a)

(b)

Figure 5: Systolic scheduling of neuron network layers [38].

them is less sophisticated in terms of design. Re-applyingneural accelerators designed for CPUs to GPUs directly willtake too much die area which makes the architecture lessprofitable. The workloads that usually run on GPUs fit forapproximate computing [40], [41]. GPU neural acceleratorseliminate costly operations instead of increasing parallelism[42]. It eliminates fetch/decode logic and memory access. Itreuses multiply-add functional unit inside each GPU stream-ing multiprocessor(SM). It simulates sigmoid operators ineach neuron with a look-up tables.

The system contains a programming language, compi-lation flow, ISA extensions and a GPU-accelerator archi-tecture. It leverages CUDA programming languages withpragma extensions to specify the code section to approxi-mate. For the specified code section, inputs are the valuesthat are alive or referred inside the section and outputs arethe values that are alive or modified in the section. To get thetraining/testing data set, the code section was compiled andexecuted for input/output pairs. The neural network model tobe trained is a limited-sized Multi-layer Perceptron (MLP).The compilation flow replaces the original code sectionwith a invocation to the trained neural accelerators (builtin hardware).

u ch a r 4 p=tex2D ( img , x , y ) ;. . .#pragma ( b e g i n a p p r o x )a=min ( r , min ( g , b ) ) ;b=max ( r , max ( g , b ) ) ;z = ( ( a+b )>254)? 2 5 5 : 0 ;#pragma ( end approx ). . .d s t [ img . wid th∗y+x ]= z ;

The architecture integrates accelerators to each GPUstreaming multiprocessors (SMs) instead of each processingunit (PU). Each SM has a set of accelerators with a sharedweight buffer and control logic. Each PU inside an SM hasits own sigmoid operators (LUT simulated) and input/outputbuffers (for intermediate result between neuron layers and

6

MetadataStructures

Pre-Core(user-def)

Pre-Core

Pre-Core

PartitionReader

Control

SpillFSM

Partition Allocator+ Writer

DRAM

HW Post-Core(user-def)

Post-Core

Post-Core

SWCore Core

L2

Figure 7: LINQits hardware template for partitioning, grouping, and hashing.

The Join operator also poses similar challenges, as shownin Figure 6. In a Join, two large data collections are matchedby a common key followed by a user-defined function thattakes both values associated with the common key and com-putes an output (also based on a user-defined function). Forvery large data set sizes, a hash join is typically used to avoidan expensive nested, pairwise comparison. In the hash join,elements from the smaller of the two partitions are insertedinto a hash table. Elements of the larger partition are thenused to probe the hash table for matching keys. Like inGroupBy, implementing a naive hash join similarly exhibitspoor caching and memory behavior.

Partitioning. Partitioning is a well-known software strat-egy for improving the locality and performance of GroupBy

and Join queries in databases [16, 12, 41] and distributedrun-times [24]. As illustrated in Figure 5 (bottom), a pre-processing step is first carried out by computing a key par-tition function on each key value. In the example, the par-tition function divides the initial collection into two disjointsub-partitions, each with non-overlapping keys. In the finalGroupBy, the two disjoint sub-partitions are processed withindependent hash tables with non-overlapping key values.

During the partitioning steps, fewer random accesses aremade to DRAM because sub-partitions are built up contigu-ously (versus writing in one pass to the final partitions di-rectly). Partitioning comes at the cost of O(np) operations,where n is the collection size and p is the number of parti-tioning passes. At the end of the partitioning phase, each in-dividual sub-partition would be inserted into a private hashtable scaled to fit within on-chip memories. The same opti-mization can be applied to Join (bottom, Figure 6). Here,two disjoint sub-partitions are created followed by smallerhash-joins that can potentially fit in smaller data structuressuch as caches.

6. GENERAL HARDWARE APPROACHOur key idea behind the LINQits hardware template is

to adopt the same divide-and-conquer approaches used insoftware to make hardware-based hash tables practical toimplement for queries that operate on large-scale datasetsizes. In the context of a small SoC such as ZYNQ, theHAT must operate with a limited amount of on-die mem-ory storage (typically 1MB or less). Naively implementinga hardware-based hash table using this limited storage canhurt performance due to excessive conflicts and spills. Akey strategy we take is to develop hardware that performsin-place, multi-pass partitioning prior to actually carrying

PartitionMeta

Free List

DataArrays

KeyNext

DataRootSize

PartitionHeader

Next Partition

Data Array Next~1-4KB

Data Array Next

Data Array

Figure 8: Data Structures for LINQits partitions.

out the final hash operation needed in a multi-level GroupByor Join. We also observe that both hashing and partition-ing can leverage the same physical structures with minimalimpact to hardware complexity and area.

Figure 7 illustrates the physical organization of our pro-posed HAT architecture, spanning both hardware and soft-ware on the ZYNQ platform. The heart of the HAT is adata steering and storage engine that enables fine-grained re-partitioning of data into multiple hash entries, implementedusing a network-on-chip and physical queues.

At run-time, data is streamed in from main memory andprocessed by a collection of pre- and post-core modules thatimplement the user-defined functions described in Section 2;the outputs of the pre-cores are used by the network-on-chipfor steering key-value pairs into destination queues. Whena queue reaches capacity, it is streamed out into main mem-ory to form new sub-collections that become the sources forsubsequent invocations of the HAT.

For operators that associate computation with items al-ready sorted into queues (e.g., Aggregate), post-cores areplaced in the back-end of the HAT pipeline to handle post-processing operations. Finally, the metadata structuresshown in Figure 7 contain information about created parti-tions (i.e., partition ID and address table), groups, keys, ele-ment counts, and other relevant information required to tra-verse the data structures for the various passes of the LINQoperators. In the next sections, we discuss two importantmodes of operation: partitioning and hashing. Section 6.3will later describe how these building blocks implement sixout of the seven essential LINQ operators from Section 2.

6.1 Partitioning ModeFigure 9 (top) shows the hardware structures for operating

the HAT in partitioning mode.

Partition Reader. The partition reader is a specializedDMA engine responsible for reading bulk data stored in par-

Figure 6: LINQits hardware templates [43].

final result). All the PUs inside an SM executes in a lock-step mode controlled by the shared logic.

The quality degradation is controlled by invocation rateof the neural accelerators. The invocation rate is the numberof warps invoking the neural accelerators over the totalnumber of warps. Based on the evaluation, neural accel-erators can 2.4x performance speedup and 2.8x less energyconsumption within less than 10% quality loss.

3.5. Query processing accelerator

LINQits is a Hardware Template (HAT) based accel-erator for data processing language [43]. The acceleratorcan be implemented using either FPGA-based SoC or ASICwith different design flavors. It leverages LINQ which is anadvanced query language from Microsoft’s .NET framework[44]. In addition to traditional SQL, it supports some user-defined functions and supports lazy evaluation to avoid un-necessary query. The compilation process includes a queryplan optimizer, mapping to hardware template and run-timescheduling. The reconfigurable part of the accelerator residesin post and pre-cores. Pre-cores are used to synthesize theanonymous functions while the post-cores are used for theaggregate and join.

LINQits leverages domain-specific languages (LINQ)for compilation. The ARM core is responsible for initial-izing the partitions of the Partition Reader which has to beexplicitly coded by the user (the paper does not explain thispart in details). High-level synthesis tool AutoESL is usedto generate post and pre-cores.

3.6. Datacenter search engine accelerator

Catapult is an FPGA-based reconfigurable architectureto accelerate large-scale datacenter applications [45]. Insteadof using native bus provided by the host CPU like otherFPGA-based CPU systems [46], [47], Catapult designedtheir own PCIe bus driver. The FPGA was designed on aboard along with 8 GB of DRAM, PCIe and inter-FPGAconnections. A rack consists of a tuple of 24 1U serverwith a torus network connection between FPGA boards.The inter-FPGA connection speed can go up to 20 Gb/s.This infrastructure is deployed to production server in thecompany.

The programming interface needs to consider softwareinterface and board resource interface. CPU allocates bufferin user-level memory space to communicate with FPGA.

The FPGA performs DMA request to the buffer by periodi-cally checking the full bit. A shell is developed to manageall the FPGA board resources. Developers only need towrite the role part which is the actual application logic.Though programmers do not need to have knowledge ofboard resource of Catapult, the Hardware Description Lan-guage (HDL) requirement is necessary. From this point ofview, Catapult is programming friendly mostly for hardwaredesigners.

3.7. Analysis

The accelerators described above have different consid-erations for configuration designs. DySER heavily dependson the compilers to generate code. The compiler identifiesmemory sub-regions which includes load/store instructionsand converts them into instructions to invoke DySER. Thecompiler also identifies computation sub-regions and con-verts them into configurations that can be used to configureDySER. The configurations happen sometime before theinvocations. NPU uses compiler to generate code as wellas generating configurations. The compiler transforms theannotated code (a function) into a neural network by per-forming an off-line training process on some training data.The generated configuration includes the weights of eachneuron (neural network topology is fixed). The compilerinstruments the CPU code to configure, send data to andinvoke the accelerators. ISA extensions are added to supportthe communication of data and configurations. SNNAP usesa similar approach but in addition it builds a C library towrap the invocations into an asynchronous streaming model.A similar approach goes to GPU neural accelerator as welland it chooses to annotate a code region in a function insteadof the entire function. Catapult does not leverage compilerat the moment. The programmer has to have domain knowl-edge of both application and hardware. But the knowledgeof this particular platform is unnecessary since a shell isdeveloped to hide the details. LINQits leverages HLS togenerate configurations for pre and post cores.

Configuration-based accelerators need a configurationstage before performing the actual computation. The con-figurations can be stored in registers (DySER, NPU, etc.) inthe accelerators. An interface is used or designed to send theconfigurations to the accelerators efficiently. With the abilityof configurations, the accelerators become more flexibleand gain the capabilities to perform more operations. Achallenge is to schedule the configurations stage to overlapwith computations so that it will not affect overall efficiency.Correctly designing the configuration point is essential toreduce the total amount of configurations.

Configuration-based accelerators are flexible and effi-cient. They remove instruction-related overhead by havingno ISA at all. They achieve flexibility by setting the re-configurable parameters in the accelerators. A design spaceexists to balance reconfigurable parameters. For acceleratorsattached to host processor’s pipeline (DySER) or the onesattached to the same bus with the host (NPU, SNNAP),configuration has different designs. The former is more

7

sensitive towards configuration overhead if the acceleratorsare designed to change configuration regularly. The latter isless sensitive since usually configuration happens once andcan be reused over iterations.

4. Automatically generated accelerators

The third category of hardware accelerators are the auto-matically generated ones. These accelerators use toolchainto convert software pieces into their functional-equivalenthardware counterpart.

4.1. ASIC-based accelerators

The utilization wall prohibits scaling of frequencies ofmicro-processor designs. Due to the limitation of supplyvoltage (related to threshold voltage), power does not scaledown along with the scaling-down of transistor dimensions.As transistor dimensions shrink, power budget reaches apoint where only a portion of transistors on a chip die can bepowered up to switch no at one time. A real-world indicationfrom Intel is that their CPUs frequency became stable since2004 and the other is the support for turbo mode whichboosts one core’s frequency by turning off all other cores.

An effective approach to conquer this problem is Con-servation Cores proposed by UCSD [3], [48], [49]. It tradeschip area for less energy consumption and uses applicationspecific accelerators to remove inefficiencies in general pur-pose processors (instruction fetch, register file access, etc.).It contains a general purpose host processor and a group ofc-cores each of which performs a particular function that isoffloaded from the host. The host and c-cores communicateby L1 cache and scan chains. The L1 cache consistencybetween them is maintained explicitly by forcing a particularmemory access order. The scan chains is used by the host tochange any state inside the c-core (register values, controlsignals, etc.). Patch is also supported by scan chains in casethe applications are updated.

The c-cores are generated by a toolchain from high-levelapplication source code. A profiling tool identifies the hotregions (functions) of the program and the toolchain turnsthem into c-cores. At runtime, the host processor initiates thec-cores with arguments and other data through scan chainsand then starts the c-core. The functions executed on c-coresare more energy-efficient than on the host since the over-head incurred by the pipeline stages and instruction mem-ory access (instruction fetch latency, branch mis-predictionpenalty) in general-purpose processors is removed.

The essential part of the tool chain is a translation tool. Ittakes arbitrary functions written in C language as input andproduces c-core hardware written in Hardware DescriptionLanguage (HDL). It uses selective depipelining techniqueto schedule instructions [48]. Each c-core has two clocks -a slow clock and a fast clock. The slow clock drives theexecution of basic blocks and the fast clock drives eachinstruction inside a basic block. One instruction could takemore than a cycle to finish (load/store, floating point, etc.)in which case two copies of this instruction are scheduled (a

OCN

I-Cache D-Cache

CPU

C-core

C-core

C-core

Figure 7: Conservation core system architecture [3].

send copy and a receive copy). The instructions were givenpriorities based on the each critical path. Then based on pri-ority, instructions are scheduled among each fast clock. Thepolicy is a heuristic which assigns as many instructions aspossible inside a fast clock under certain timing constraints.Then deferred instructions (missing timing constraints) areattempted to be scheduled again in next fast clock. Allthe two-stage operations have state registers to store theirtemporary values across the boundary of fast clocks.

Based on the experiments, functions on c-cores canachieve up to 16x more energy efficient while the systemenergy efficiency can increase by up to 2.1X.

4.2. FPGA-based accelerators

AutoPilot HLS is the predecessor of Xilinx Vivado HLStool [14], [50]. It provides a high-level synthesis systemfor integration and verification of the designs. AutoPilotoutputs RTL descriptions which can be used for simulationand verification. It also generates report for power/perfor-mance/area like any other IC compilers. It supports C,C++ ,and SystemC as frontend high-level programming lan-guages. Floating-point operations are mapped to precision-variant IP blocks.

AutoPilot uses commonly-used compiler techniques tooptimize and generate code. It leverages the Static Single-Assignment (SSA) of LLVM infrastructure to performanceoptimizations and code generation. It uses llvm-gcc as thecompiler frontend. Several LLVM passes are mentioned bythis work to be important for high-level synthesis optimiza-tions. Global value numbering-based approaches includingconstant propagation, dead code elimination and redundantcode elimination are generally useful. Strength reduction

8

replaces expensive operators with cheap operators to reducethe design constraints. Range analysis shows the potentialto reduce the precision (bit width) of operations. Looprelated optimizations can expose more parallelism whichimproves performance. Memory related optimizations canreduce memory access frequencies. The HLS process needsto resolve an efficient scheduling, optimizations under con-straints, efficient resource sharing and memory operationoptimizations.CONG et al.: HIGH-LEVEL SYNTHESIS FOR FPGAS: FROM PROTOTYPING TO DEPLOYMENT 477

second-generation of HLS tools showed interesting capabilitiesto raise the level of design abstraction, most designers werereluctant to take the risk of moving away from the familiarRTL design methodology to embrace a new unproven one,despite its potential large benefits. Like any major transitionin the EDA industry, designers needed a compelling reason orevent to push them over the “tipping point,” i.e., to adopt theHLS design methodology.

Another important lesson learned is that tradeoffs must bemade in the design of the tool. Although a designer might wishfor a tool that takes any input program and generates the “best”hardware architecture, this goal is not generally practical forHLS to achieve. Whereas compilers for processors tend tofocus on local optimizations with the sole goal of increasingperformance, HLS tools must automatically balance perfor-mance and implementation cost using global optimizations.However, it is critical that these optimizations be carefullyimplemented using scalable and predictable algorithms, keep-ing tool runtimes acceptable for large programs and the resultsunderstandable by designers. Moreover, in the inevitable casethat the automatic optimizations are insufficient, there mustbe a clear path for a designer to identify further optimizationopportunities and execute them by rewriting the original sourcecode.

Hence, it is important to focus on several design goals fora HLS tool.

a) Capture designs at a bit-accurate, algorithmic level. Thesource code should be readable by algorithm specialists.

b) Effectively generate efficient parallel architectures withminimal modification of the source code, for paralleliz-able algorithms.

c) Allow an optimization-oriented design process, wherea designer can improve the QoR by successive codemodification, refactoring and refinement on synthesisoptions/directives.

d) Generate implementations that are competitive withsynthesizable RTL designs after automatic and manualoptimization.

We believe that the tipping point for transitioning to HLSmethodology is happening now, given the reasons discussed inSection I and the conclusions by others [14], [85]. Moreover,we are pleased to see that the latest generation of HLStools has made significant progress in providing wide lan-guage coverage and robust compilation technology, platform-based modeling, and advanced core HLS algorithms. We shalldiscuss these advancements in more detail in the next fewsections.

III. State-of-Art of HLS Flow for FPGAs

AutoPilot is one of the most recent HLS tools, and is repre-sentative of the capabilities of the state-of-art commercial HLStools available today. Fig. 1 shows the AutoESL AutoPilotdevelopment flow targeting Xilinx FPGAs. AutoPilot acceptssynthesizable ANSI C, C++, and OSCI SystemC (based on thesynthesizable subset of the IEEE-1666 standard [115]) as inputand performs advanced platform-based code transformations

Fig. 1. AutoESL and Xilinx C-to-FPGA design flow.

and synthesis optimizations to generate optimized synthesiz-able RTL.

AutoPilot outputs RTL in Verilog, VHDL or cycle-accurateSystemC for simulation and verification. To enable automaticco-simulation, AutoPilot creates test bench (TB) wrappers andtransactors in SystemC so that the designers can leverage theoriginal test framework in C/C++/SystemC to verify the cor-rectness of the RTL output. These SystemC wrappers connecthigh-level interfacing objects in the behavioral TB with pin-level signals in RTL. AutoPilot also generates appropriate sim-ulation scripts for use with third-party RTL simulators. Thus,designers can easily use their existing simulation environmentto verify the generated RTL.

In addition to generating RTL, AutoPilot also creates syn-thesis reports that estimate FPGA resource utilization, as wellas the timing, latency, and throughput of the synthesizeddesign. The reports include a breakdown of performanceand area metrics by individual modules, functions, and loopsin the source code. This allows users to quickly identifyspecific areas for QoR improvement and then adjust synthesisdirectives or refine the source design accordingly.

Finally, the generated HDL files and design constraints feedinto the Xilinx RTL tools for implementation. The Xilinxintegrated synthesis environment (ISE) tool chain (such asCoreGen, XST, and PAR) and Embedded Development Kit(EDK) are used to transform that RTL implementation into acomplete FPGA implementation in the form of a bitstream forprogramming the target FPGA platform.

IV. Support of High-Level Programming Models

In this section, we show that it is important for HLS toprovide wide language coverage and leverage state-of-the-artcompiler technologies to achieve high-quality synthesis results.

Figure 8: AutoPilot HLS tool design flow [50].

4.3. SoC based accelerators

LegUp is a high-level synthesis system to build FPGA-based CPU-accelerators architectures [13]. It is composed ofa MIPS soft processor and an automatic generated hardwareaccelerator. The soft processor and the accelerator reside onthe same reconfigurable fabric and communicate through abus interface. The soft processor handles irregular code likeany other CPU-based architectures while the co-processoraccelerates the more regular code.

The compilation process takes several stages. The sourcecode (written in modular C++) is compiled using standardC++ MIPS compiler into binary code. This binary code isexecuted on a MIPS soft processor which is enhanced witha profiling module. The profiling module reports executioncycles, power, cache miss rates, etc. as results. Based onthis profiling results, certain code regions are targeted. AHigh-level synthesis tool is built to convert target coderegion into Register-Transfer Level (synthesizable Verilog)representation of the corresponding hardware acceleratormodules. The original software source code is enhanced byreplacing the targeted code region with code of invoking the

hardware modules. Then the enhanced software runs on theMIPS-coprocessor which is hardened into the reconfigurablefabric.

Program code

C CompilerProcessor

(MIPS)

Self-ProfilingMIPS Processor

Profiling Data:

Execution CyclesPower

Cache Misses

High-levelsynthesis Suggested

programsegments to

target to HW

FPGA fabric

µP Hardenedprogramsegments

Altered SW binary (calls HW accelerators)

....y[n] = 0;for (i = 0; i < 8; i++) {

y[n] += coeff[i] * x[n-i];}....

1

2

3

LegUp

6

5

4

Figure 1: Design flow with LegUp.

runs on an FPGA-based MIPS processor. We evaluatedseveral publicly-available MIPS processor implementationsand selected the Tiger MIPS processor from the Universityof Cambridge [11], based on its full support of the MIPSinstruction set, established tool flow, and well-documentedmodular Verilog.

The MIPS processor has been augmented with extra cir-cuitry to profile its own execution. Using its profiling abil-ity, the processor is able to identify sections of program codethat would benefit from hardware implementation. Specif-ically, the profiling results drive the selection of programcode segments to be re-targeted to custom hardware fromthe C source. Profiling a program’s execution in the proces-sor itself provides the highest possible accuracy. Presently,we profile program run-time at the function level.

Having chosen program segments to target to custom hard-ware, at step ➂ LegUp is invoked to compile these segmentsto synthesizeable Verilog RTL. LegUp’s hardware synthe-sis and software compilation are part of the same compilerframework. Presently, LegUp HLS operates at the functionlevel: entire functions are synthesized to hardware from theC source. The RTL produced by LegUp is synthesized toan FPGA implementation using standard commercial toolsat step ➃. In step ➄, the C source is modified such thatthe functions implemented as hardware accelerators are re-placed by wrapper functions that call the accelerators (in-stead of doing computations in software). This new modifiedsource is compiled to a MIPS binary executable. Finally, instep ➅ the hybrid processor/accelerator system executes onthe FPGA.

Our long-term vision is to fully automate the flow in Fig. 1,thereby creating a self-accelerating adaptive processor in whichprofiling, hardware synthesis and acceleration happen trans-parently without user awareness. In the first release of ourtool, however, the user must manually examine the profilingresults and place the names of the functions to be acceler-ated in a file that is read by LegUp.

Fig. 2 elaborates on the target system architecture. Theprocessor connects to one or more custom hardware accel-erators through a standard on-chip interface. As our initialhardware platform is the Altera DE2 Development and Edu-cation board (containing a 90 nm Cyclone II FPGA), we usethe Altera Avalon interface for processor/accelerator com-munication [2]. A shared memory architecture is used, withthe processor and accelerators sharing an on-FPGA datacache and off-chip main memory. The on-chip cache memoryis implemented using block RAMs within the FPGA fabric(M4K blocks on Cyclone II). Access to memory is handledby a memory controller. The architecture in Fig. 2 allows

FPGA

MIPS ProcessorHardware

Accelerator

AVALON INTERCONNECT

Hardware Accelerator

Memory ControllerOn-Chip Cache

Off-Chip Memory

Figure 2: Target system architecture.

processor/accelerator communication across the Avalon in-terface or through memory.

The architecture depicted in Fig. 2 represents the targetsystem most natural for an initial release of the tool. The ar-chitecture of processor/accelerator systems is an importantdirection for future research.

4. DESIGN AND IMPLEMENTATION4.1 High-Level Hardware Synthesis

High-level synthesis has traditionally been divided intothree steps [4]: allocation, scheduling and binding. Alloca-tion determines the amount of hardware resources availablefor use, and manages other hardware constraints (e.g., speed,area, and power). Scheduling assigns each operation in theprogram being synthesized to a particular clock cycle (state)and generates a finite state machine. Binding saves areaby sharing functional units between operations, and sharingregisters/memories between variables.

LegUp leverages the low-level virtual machine (LLVM)compiler framework. At the core of LLVM is an inter-mediate representation (IR), which is essentially machine-independent assembly language. C code is translated intoLLVM’s IR then analyzed and modified by a series of com-piler optimization passes. LLVM IR instructions are sim-ple enough to directly correspond to hardware operations(e.g., an arithmetic computation). Our HLS tool operatesdirectly with the LLVM IR, scheduling the instructions intospecific clock cycles. LegUp HLS algorithms have been im-plemented as LLVM passes that fit neatly into the existingframework. Implementing the HLS steps as distinct passesalso allows easy experimentation with different HLS algo-rithms; for example, one could modify LegUp to “plug in” anew scheduling algorithm.

The initial release of LegUp uses as-soon-as-possible (ASAP)scheduling [5], which assigns an operation to the first stateafter its dependencies are available. In some cases, we canschedule an instruction into the same state as one of its de-pendencies. This is called operation chaining. Chaining canreduce hardware latency (# of cycles for execution) withoutimpacting the clock period.

Binding consists of two tasks: assigning operators fromthe program being synthesized to specific hardware units,and assigning program variables to registers (register allo-cation). When multiple operators are assigned to the samehardware unit, or when multiple variables are bound tothe same register, multiplexers are required to facilitate thesharing. We make two FPGA-specific observations in ourapproach to binding. First, multiplexers are relatively ex-pensive to implement in FPGAs using LUTs. A 32-bit mul-tiplexer implemented in 4-LUTs is the same size as a 32-bitadder. Consequently, there is little advantage to sharing allbut the largest functional units, namely, multipliers and di-viders. Likewise, the FPGA fabric is register rich and shar-

Figure 9: Design flow of LegUp [13].

The HLS tools takes three steps: allocation, schedul-ing, and binding [51]. Scheduling assigns each softwareinstruction to a particular clock cycle. LegUp schedules eachinstruction as soon as all its dependencies are met. Bind-ing determines which hardware resource (functional units,registers, etc.) the operation of an instruction uses. LegUpsolves binding as a bipartite matching problem. In practice,high-cost functional units (integer multiplier, floating-pointunits) are shared more frequently than registers and low-costfunctional units (integer adder, etc.) are rarely shared.

4.4. Summary

The hardware accelerators described above are all gener-ated automatically from software. C-Core targets for ASICand has been built to integrate into a host processor. Au-toPilot targets for FPGA. LegUp targets for FPGA-basedSoC.

5. Our work

We are developing a framework to build acceleratorsand integrate them into existing systems automatically. Ourwork falls into the category of automatically generatedaccelerators; It can be potentially used in micro-controllers.

5.1. System overview

A toolchain is developed to turn software written in high-level programming languages (C language) into hardwaredesign represented by Hardware Description Language (Ver-ilog). The toolchain goes through several stages includinginstruction scheduling, basic block generation, control blockgeneration ,and datapath generation in order to generatean intermediate representation (IR) for digital circuits. TheIR is then processed by a converter to industry standardhardware design specifications (Verilog). This product canbe used as input to any CAD tool to generate hardware

9

state 0

state 1

state 2

state 3

state 4

state 5

state 6

state 7

state 8

p a

t3

b c

t14 t25

t11(send)

t11(recv)t6(send)

t6(recv)

t12(send)

t12(recv)

t17(send)

t17(recv)

t18(send)

t18(recv)

int foo(int *p,int a,int b,int c)

{

int t0=p[a]*p[b];

t0=t0*p[c];

return t0;

}

define i32 @foo(i32* p, i32 a, i32 b, i32 c)

{

call_conv:

br label entry

entry:

t3 = getelementptr p, a

t6 = load t3,

t14 = getelementptr p, b

t11 = load t14

t12 = mul t11, t6

t25 = getelementptr p, c

t17 = load t25

t18 = mul t12, t17

ret i32 t18

}

(a)

(b)

(c)ControlBlock Module

Basic Block Module(call_conv)

Basic BlockModule(entry)

(d)

Figure 10: Code generation process. (a) C source code; (b) Software-IR; (c) automatic instruction schedule for basic block’entry’; (d) architecture diagram of generated hardware accelerator.

design ready to ship for fabrication. The generated hardwareaccelerator is compatible with host processor in terms ofcalling conventions. It can be invoked by software runningon host processor with similar overhead comparing invokinga software function. The calling convention interface isdesigned to be flexible so that the efforts of re-targetingthe hardware accelerator to other host processor is mini-mized. The generated hardware accelerator is able to lever-age the Split-Phase Multiplexed Operator (SPMO whichis explained in later section) interface to access peripheralmodules (memory, etc.) like the host processor. This givesthe hardware accelerator enough opportunity to replace morefunctionality usually performed by the host general-purposeprocessors.

5.2. Granularity and instruction scheduling

The hardware accelerator is generated in the unit offunction. A hardware module is generated for the targetedfunction. Its interface supports reading and writing statesin hardware accelerator from host processor, reading andwriting peripherals from the hardware accelerator.

The toolchain schedules instructions in the unit of basicblocks. Inside each basic block, a data dependency graph is

built for all instructions. The instruction scheduling is two-pass process. In the first-pass, each instruction is assigned apriority based on their latest starting time in the critical path.In the second-pass, it uses a work-list algorithm to iteratethrough each instruction. For each instruction, it schedulesthe instruction to the timing slot based on its priority andupdates the work-list. After instruction scheduling, the soft-ware basic blocks are mapped into hardware basic blocks.The translation heuristics is described in Figure 10.

5.3. Control logic and execution model

The control logic drives the execution of the entire hard-ware accelerator module. The state machine inside controlflow keeps a state for each instruction as well each basicblock. It is generated after instruction scheduling is done. Ithas state signals indicating the current basic block and theparticular instruction inside that basic block. The controlflow is either sequential inside a basic block or jumps toa new basic block based on the jump instruction in theprevious block. It supports multiple instruction issuing andexecution at the same cycle as long as they do not havedependencies or share the same functional unit. The controllogic inside a basic block is designed so that the execution

10

model can be as efficient as a data flow fashion with the onlylimiting factor being the multiplexed external modules.

5.4. Interface between hardware acceleratorand host processor

The accelerator has a standard interface to interact withthe host processor and memory system. The interface is cus-tomizable in order to achieve load overhead access to periph-erals. We designed an interface to handle an arbitrary callingconvention at run-time. Taking MIPS ISA for example, atinvoking time the host processor sets the stack pointer,global pointer and registers in the accelerator. The hostprocessor is able to change the state (parameters, temporaryvalues holding between cycles) of hardware accelerator viaa tree structure pipelined multiplexer. Each register in thehardware accelerator has a unique address in its own registeraddress space. The interface provides support for the hostprocessor to read or modify any register in that space.The more complicated calling conventions (passing morethan four parameters, passing union/struct, etc.) are handledby shared data memory cache in the host processor. Thenthe host processor keeps probing the attention signal fromaccelerators for the execution finish.

5.5. Split-phase multiplexed operator (SPMO)

Split-phase Multiplexed Operator (SPMO) is a scalableand efficient mechanism for hardware accelerators to accessthe shared resources. It achieves silicon sharing across accel-erator, host processor and external peripherals. The toolchaingenerates SPMO automatically for the hardware accelera-tors. It uses a valid/enable protocol to access peripherals.For each instruction, it generates a send and receive copyof it for the purpose of scheduling. The only restrictions forachieving maximum parallelism are the number of sharedresources of each type (ports as well).

6. Conclusion

Leakage-dominated technology scaling has to resolve tohardware accelerators for taking system efficiency to thenext level. In order to leverage dark silicon, designers areadding more and more accelerators into their system. Theproblem of integrating and managing increasing amount ofhardware accelerators demands more design considerationsfrom compiler aspects. Hardware accelerators have contin-ued to be redesigned from compiler aspects. The supportshardware accelerators provide to and the supports they re-quire from compilers interact to make system architecturemore efficient and cost-effective. Proposing new design ofcompiler aspects or choosing between existing designs playsa critical role in accelerators’ overall quality.

Automatically generated hardware accelerators providesanother way of designing hardware accelerators. Instead ofmanually designing hardware, it synthesizes the programsto be accelerated into accelerator directly. The generated ac-celerators can fall into the category of configuration-based.

However, it is automatically generated which is fundamen-tally different from manually designed configuration-basedaccelerators. Examples of the configuration parameters arethe calling conventions in traditional ISA from the host pro-cessors. This reduces the manual design efforts of hardwarerooted from the reason that hardware code can rarely bereused in the scale as software. This enables a quick designexploration of integrating hardware accelerators in a newsystem for a new application.

References

[1] Michael B Taylor. Is dark silicon useful?: harnessing the fourhorsemen of the coming dark silicon apocalypse. In Proceedings ofthe 49th Annual Design Automation Conference, pages 1131–1136.ACM, 2012.

[2] Michael Bedford Taylor. A landscape of the new dark silicon designregime. Micro, IEEE, 33(5):8–19, 2013.

[3] Ganesh Venkatesh, Jack Sampson, Nathan Goulding, Saturnino Gar-cia, Vladyslav Bryksin, Jose Lugo-Martinez, Steven Swanson, andMichael Bedford Taylor. Conservation cores: reducing the energyof mature computations. In ACM SIGARCH Computer ArchitectureNews, volume 38, pages 205–218. ACM, 2010.

[4] Hadi Esmaeilzadeh, Emily Blem, Renee St Amant, KarthikeyanSankaralingam, and Doug Burger. Dark silicon and the end ofmulticore scaling. In Computer Architecture (ISCA), 2011 38thAnnual International Symposium on, pages 365–376. IEEE, 2011.

[5] Robert H Dennard, VL Rideout, E Bassous, and AR LeBlanc. Designof ion-implanted mosfet’s with very small physical dimensions. Solid-State Circuits, IEEE Journal of, 9(5):256–268, 1974.

[6] Chris Lomont. Introduction to intel advanced vector extensions. IntelWhite Paper, 2011.

[7] Shay Gueron. Advanced encryption standard (aes) instructions set.Intel, http://softwarecommunity. intel. com/articles/eng/3788. htm, ac-cessed, 25, 2008.

[8] http://www.arm.com/products/processors/.

[9] https://en.wikipedia.org/wiki/Apple motion coprocessors.

[10] http://www.bluespec.com/high-level-synthesis-tools.html.

[11] https://www.mentor.com/hls-lp/.

[12] http://www.cadence.com/products/sd/silicon compiler/pages/default.aspx.

[13] Andrew Canis, Jongsok Choi, Mark Aldham, Victor Zhang, AhmedKammoona, Jason H Anderson, Stephen Brown, and Tomasz Cza-jkowski. Legup: high-level synthesis for fpga-based processor/accel-erator systems. In Proceedings of the 19th ACM/SIGDA internationalsymposium on Field programmable gate arrays, pages 33–36. ACM,2011.

[14] http://www.xilinx.com/products/design-tools/vivado/integration/esl-design.html.

[15] Tianshi Chen, Zidong Du, Ninghui Sun, Jia Wang, Chengyong Wu,Yunji Chen, and Olivier Temam. Diannao: A small-footprint high-throughput accelerator for ubiquitous machine-learning. In ACMSigplan Notices, volume 49, pages 269–284. ACM, 2014.

[16] Yunji Chen, Tao Luo, Shaoli Liu, Shijin Zhang, Liqiang He, Jia Wang,Ling Li, Tianshi Chen, Zhiwei Xu, Ninghui Sun, et al. Dadiannao:A machine-learning supercomputer. In Proceedings of the 47thAnnual IEEE/ACM International Symposium on Microarchitecture,pages 609–622. IEEE Computer Society, 2014.

[17] Zidong Du, Robert Fasthuber, Tianshi Chen, Paolo Ienne, Ling Li,Tao Luo, Xiaobing Feng, Yunji Chen, and Olivier Temam. Shidian-nao: shifting vision processing closer to the sensor. In Proceedings ofthe 42nd Annual International Symposium on Computer Architecture,pages 92–104. ACM, 2015.

11

[18] Wajahat Qadeer, Rehan Hameed, Ofer Shacham, Preethi Venkatesan,Christos Kozyrakis, and Mark A Horowitz. Convolution engine:balancing efficiency & flexibility in specialized computing. In ACMSIGARCH Computer Architecture News, volume 41, pages 24–35.ACM, 2013.

[19] Rehan Hameed, Wajahat Qadeer, Megan Wachs, Omid Azizi,Alex Solomatnikov, Benjamin C Lee, Stephen Richardson, ChristosKozyrakis, and Mark Horowitz. Understanding sources of inefficiencyin general-purpose chips. In ACM SIGARCH Computer ArchitectureNews, volume 38, pages 37–47. ACM, 2010.

[20] Yunsup Lee, Andrew Waterman, Rimas Avizienis, Henry Cook, ChenSun, Vladimir Stojanovic, and Krste Asanovic. A 45nm 1.3 ghz 16.7double-precision gflops/w risc-v processor with vector accelerators.In European Solid State Circuits Conference (ESSCIRC), ESSCIRC2014-40th, pages 199–202. IEEE, 2014.

[21] Albert Ou, Quan Nguyen, Yunsup Lee, and Krste Asanovic. A casefor mvps: Mixed-precision vector processors.

[22] Huy Vo, Yunsup Lee, Andrew Waterman, and Krste Asanovic. Acase for os-friendly hardware accelerators. Proc. of WIVOSCA, 2013.

[23] Shekhar Borkar and Andrew A Chien. The future of microprocessors.Communications of the ACM, 54(5):67–77, 2011.

[24] Andrew A Chien, Tung Thanh-Hoang, Dilip Vasudevan, YuanweiFang, and Amirali Shambayati. 10x10: A case study in highly-programmable and energy-efficient heterogeneous federated architec-ture. ACM SIGARCH Computer Architecture News, 43(3):2–9, 2015.

[25] James Balfour, William J Dally, David Black-Schaffer, Vishal Parikh,and JongSoo Park. An energy-efficient processor architecture forembedded systems. Computer Architecture Letters, 7(1):29–32, 2008.

[26] Alex Solomatnikov, Amin Firoozshahian, Wajahat Qadeer, OferShacham, Kyle Kelley, Zain Asgar, Megan Wachs, Rehan Hameed,and Mark Horowitz. Chip multi-processor generator. In Proceedingsof the 44th Annual Design Automation Conference, pages 262–263.ACM, 2007.

[27] Lisa Wu, Andrea Lottarini, Timothy K Paine, Martha A Kim, andKenneth A Ross. Q100: the architecture and design of a databaseprocessing unit. In ACM SIGPLAN Notices, volume 49, pages 255–268. ACM, 2014.

[28] Lisa Wu, Raymond J Barker, Martha A Kim, and Kenneth A Ross.Navigating big data with high-throughput, energy-efficient data par-titioning. ACM SIGARCH Computer Architecture News, 41(3):249–260, 2013.

[29] Venkatraman Govindaraju, Chen-Han Ho, Tony Nowatzki, JatinChhugani, Nadathur Satish, Karthikeyan Sankaralingam, andChangkyu Kim. Dyser: Unifying functionality and parallelism spe-cialization for energy-efficient computing. IEEE Micro, (5):38–51,2012.

[30] Zhi Alex Ye, Andreas Moshovos, Scott Hauck, and Prithviraj Baner-jee. CHIMAERA: a high-performance architecture with a tightly-coupled reconfigurable functional unit, volume 28. ACM, 2000.

[31] Timothy J Callahan, John R Hauser, and John Wawrzynek. The garparchitecture and c compiler. Computer, 33(4):62–69, 2000.

[32] Nathan Clark, Jason Blome, Michael Chu, Scott Mahlke, Stuart Biles,and Krisztian Flautner. An architecture framework for transparentinstruction set customization in embedded processors. In ACMSIGARCH Computer Architecture News, volume 33, pages 272–283.IEEE Computer Society, 2005.

[33] Seth Copen Goldstein, Herman Schmit, Mihai Budiu, SrihariCadambi, Matt Moe, and R Reed Taylor. Piperench: A reconfigurablearchitecture and compiler. Computer, 33(4):70–77, 2000.

[34] Mahim Mishra, Timothy J Callahan, Tiberiu Chelcea, GirishVenkataramani, Seth C Goldstein, and Mihai Budiu. Tartan: evaluat-ing spatial computation for whole program execution. ACM SIGOPSOperating Systems Review, 40(5):163–174, 2006.

[35] Adrian Sampson, Werner Dietl, Emily Fortuna, Danushen Gnanapra-gasam, Luis Ceze, and Dan Grossman. Enerj: Approximate datatypes for safe and general low-power computation. In ACM SIGPLANNotices, volume 46, pages 164–174. ACM, 2011.

[36] Hadi Esmaeilzadeh, Adrian Sampson, Luis Ceze, and Doug Burger.Neural acceleration for general-purpose approximate programs. InProceedings of the 2012 45th Annual IEEE/ACM International Sym-posium on Microarchitecture, pages 449–460. IEEE Computer Soci-ety, 2012.

[37] Lawrence McAfee and Kunle Olukotun. Emeuro: A framework forgenerating multi-purpose accelerators via deep learning. In Pro-ceedings of the 13th Annual IEEE/ACM International Symposium onCode Generation and Optimization, pages 125–135. IEEE ComputerSociety, 2015.

[38] Thierry Moreau, Mark Wyse, Jacob Nelson, Adrian Sampson, HadiEsmaeilzadeh, Luis Ceze, and Mark Oskin. Snnap: Approximatecomputing on programmable socs via neural acceleration. In HighPerformance Computer Architecture (HPCA), 2015 IEEE 21st Inter-national Symposium on, pages 603–614. IEEE, 2015.

[39] Scott Sirowy and Alessandro Forin. Where’s the beef? why fpgas areso fast. Microsoft Research, Microsoft Corp., Redmond, WA, 98052,2008.

[40] Mehrzad Samadi, Janghaeng Lee, D Anoushe Jamshidi, Amir Hor-mati, and Scott Mahlke. Sage: Self-tuning approximation for graphicsengines. In Proceedings of the 46th Annual IEEE/ACM InternationalSymposium on Microarchitecture, pages 13–24. ACM, 2013.

[41] Mehrzad Samadi, Davoud Anoushe Jamshidi, Janghaeng Lee, andScott Mahlke. Paraprox: Pattern-based approximation for data par-allel applications. In ACM SIGARCH Computer Architecture News,volume 42, pages 35–50. ACM, 2014.

[42] Amir Yazdanbakhsh, Jongse Park, Hardik Sharma, Pejman Lotfi-Kamran, and Hadi Esmaeilzadeh. Neural acceleration for gputhroughput processors. In Proceedings of the 48th InternationalSymposium on Microarchitecture, pages 482–493. ACM, 2015.

[43] Eric S Chung, John D Davis, and Jaewon Lee. Linqits: Big dataon little clients. In ACM SIGARCH Computer Architecture News,volume 41, pages 261–272. ACM, 2013.

[44] Yuan Yu, Michael Isard, Dennis Fetterly, Mihai Budiu, U Erlingsson,Pradeep Kumar Gunda, Jon Currey, Frank McSherry, and KannanAchan. Some sample programs written in dryadlinq. Technical report,Tech. Rep. MSR-TR-2008-74, Microsoft Research, 2008.

[45] Andrew Putnam, Adrian M Caulfield, Eric S Chung, Derek Chiou,Kypros Constantinides, John Demme, Hadi Esmaeilzadeh, JeremyFowers, Gopi Prashanth Gopal, Jordan Gray, et al. A reconfigurablefabric for accelerating large-scale datacenter services. In ComputerArchitecture (ISCA), 2014 ACM/IEEE 41st International Symposiumon, pages 13–24. IEEE, 2014.

[46] David Slogsnat, Alexander Giese, Mondrian Nussle, and UlrichBruning. An open-source hypertransport core. ACM Transactionson Reconfigurable Technology and Systems (TRETS), 1(3):14, 2008.

[47] Liu Ling, Neal Oliver, Chitlur Bhushan, Wang Qigang, Alvin Chen,Shen Wenbo, Yu Zhihong, Arthur Sheiman, Ian McCallum, JosephGrecco, et al. High-performance, energy-efficient platforms usingin-socket fpga accelerators. In Proceedings of the ACM/SIGDAinternational symposium on Field programmable gate arrays, pages261–264. ACM, 2009.

[48] Jack Sampson, Ganesh Venkatesh, Nathan Goulding-Hotta, SaturninoGarcia, Steven Swanson, and Michael Bedford Taylor. Efficient com-plex operators for irregular codes. In High Performance ComputerArchitecture (HPCA), 2011 IEEE 17th International Symposium on,pages 491–502. IEEE, 2011.

[49] Ganesh Venkatesh, Jack Sampson, Nathan Goulding-Hotta, Sravan-thi Kota Venkata, Michael Bedford Taylor, and Steven Swanson. Qs-cores: Trading dark silicon for scalable energy efficiency with quasi-specific cores. In Proceedings of the 44th Annual IEEE/ACM In-ternational Symposium on Microarchitecture, pages 163–174. ACM,2011.

12

[50] Jason Cong, Bin Liu, Stephen Neuendorffer, Juanjo Noguera, KeesVissers, and Zhiru Zhang. High-level synthesis for fpgas: Fromprototyping to deployment. Computer-Aided Design of IntegratedCircuits and Systems, IEEE Transactions on, 30(4):473–491, 2011.

[51] Philippe Coussy, Daniel D Gajski, Michael Meredith, and AndresTakach. An introduction to high-level synthesis. IEEE Design & Testof Computers, (4):8–17, 2009.

13