Extensions

Accelerators Generated using High-Level Synthesis High-Level Synthesis (HLS) allows designers to write accelerators in a high-level programming lan- guage such as C, and synthesizes them into RTL descriptions. To use our frame- work with HLS-generated accelerators, one way is to analyze the RTL generated by HLS, extract features, and build a predictor by slicing the RTL. However, if analysis can be done during the HLS process, it can potentially enable opti- mizations that can not be easily performed at RTL level. For example, instead of slicing the RTL to obtain a hardware slice, we can use program slicing [110]

on the C code to obtain a software slice that calculates the control flow features, and then synthesize the sliced C code into hardware. The HLS tool can perform optimizations during the synthesis, resulting in a slice that calculates feature values faster. This leaves more time budget to run the accelerator itself, reduc- ing the possibility of deadline misses due to insufficient time budget after slice execution.

md-rtl md-hlsstencil-rtl_stencil-hls

4

2

0

2

4

Prediction Error (%)

md-rtl md-hlsstencil-rtl_stencil-hls

0

2

4

6

8

10

Deadline Misses (%)

Figure 4.19: Comparison of prediction errors and deadline misses between slicing at RTL and HLS level.

We compared these two approaches using the md and stencil accelera- tors [92], which have C versions available. Figure 4.19 shows that the prediction accuracy of both approaches are very high, but when the hardware slice is gen- erated using HLS from sliced C code, the deadline misses are gone. This implies the slice generated using HLS runs faster because we know from Section 4.4.3 that the deadline misses in md and stencil are caused by insufficient time budget left after the slice finishes execution rather than mispredictions. This can be verified by looking at Figure 4.20, which shows the slice execution time for the HLS approach is much shorter.

md-rtl_md-hls

stencil-rtl_stencil-hls

0

5

10

15

20

2530

35

40

Slice Area (%)

md-rtl_md-hls

stencil-rtl_stencil-hls

01

2

3

4

5

6

Slice Energy (%)

md-rtl_md-hls

stencil-rtl_stencil-hls

01

2

3

4

5

6

7

8

9

Slice Time (%)

Figure 4.20: Comparison of area, energy and execution time overhead be- tween slicing at RTL and HLS level.

Software-based Predictors Some accelerators have a software version with the same function, either because they are generated using HLS, or because they have a software implementation (e.g. ffmpeg for H.264). In these cases, instead of building hardware predictor, we can run a software predictor on the CPU to predict the execution time of the accelerator. We experimented with this idea on the H.264 decoder, and achieved good prediction accuracy.

CHAPTER 5

RELATED WORK

This chapter describes the existing work related to this thesis. Section 5.1 dis- cusses high-level design methodologies for accelerators. Section 5.2 discusses previous work on data supply for accelerators. Section 5.3 discusses related work on parallel programming and design methodologies for parallel acceler- ators. Section 5.4 discusses related work on dynamic voltage and frequency scaling and execution time prediction.

5.1

High-Level Design Methodologies for Accelerators

Traditionally, accelerators are designed using a hardware-oriented flow that in- volves writing low-level register transfer level (RTL) code using hardware de- scription languages such as Verilog and VHDL. The high complexity and poor productivity of this flow have lead researchers to look into design methodolo- gies that provide a higher level of abstraction.

5.1.1

High-Level Synthesis

High-Level Synthesis (HLS) compiles high-level languages such as C/C++ [20, 114] into RTL descriptions. A major reason that HLS improves productivity is that it decouples the functional specification from the timing specification of hard- ware design. Most high-level languages are untimed, meaning that program- mers only need to describe the functional behavior of an algorithm or applica- tion. In contrast, RTL design is timed, meaning that the designer needs to specify

both the functionality and exact time each operation takes place, which is te- dious to perform manually. HLS tools allow programmers to focus on the func- tional specification, and uses sophisticated algorithms to automatically generate the timing schedule. Many HLS tools allow programmers to issue high-level di- rectives to guide the scheduling process, which enables generating multiple de- signs with different performance, power, and area profiles from the same func- tional description. This ability to quickly explore the design space is another reason why HLS achieves higher productivity compared to RTL design. Many high-level synthesis frameworks have been proposed, with support for various input languages. Here we describe a number of widely used frameworks.

Bluespec Bluespec is a framework which includes a language and a set of tools for hardware design. The language, Bluespec SystemVerilog (BSV), extends Sys- temVerilog to support describing hardware as a set of Guarded Atomic Actions, which specifies the operations and the rules under which they should fire. The Bluespec compiler then synthesizes BSV into RTL (Verilog) by finding a sched- ule for the operations that satisfies the rules. The BSV language also supports many advanced features of modern programming languages, such as object- oriented interfaces, polymorphic types, static type checking, and first class pa- rameterization [76].

HLS from C Family Languages C family languages such as C/C++, SystemC, and OpenCL are among the most widely supported languages for HLS, with various tools developed by commercial companies [54, 114] and academic in- stitutions [20]. HLS compilers for these languages perform a series of steps including code transformation, resource allocation, operation scheduling, and

resource binding to generate RTL. Due to the procedural nature of these lan- guages, directly mapping the statements in a program to hardware would often be overly serialized and inefficient. Thus, HLS tools often use compiler analy- sis as well as additional user-provided directives to control how the procedural constructs such as loops are mapped to efficient hardware pipelines.

HLS from Domain Specific Languages Domain-specific languages (DSLs) trade off generality for efficiency. DSLs often provide a higher level of abstrac- tion than general-purpose languages, and potentially enable programmers to more productively express certain domain-specific algorithms and allow HLS tools to generate more efficient hardware. Delite Hardware Definition Lan- guage (DHDL) [58] is a DSL for generating accelerators based on a collection of parallel patterns inspired by functional programming languages. Halide [90] is a DSL for generating efficient image processing pipelines, and can be synthe- sized into hardware [84].

The architectural frameworks proposed in this thesis research leverage HLS, but in addition address some challenges faced by existing HLS frameworks, such as not able to tolerate variable memory latency, and insufficient support for dynamic parallelism. Furthermore, the design methodology proposed in this thesis combines the benefits of both HLS and RTL designs, while avoiding their shortcomings. HLS is used to allow accelerator designers to productively describe application logic, and the frameworks use RTL to implement highly optimized and configurable accelerator architectures that are challenging to im- plement in existing HLS tools. The reusable architecture templates allow de- signers to use the accelerator architectures without needing to manually write any RTL.