1. High-Level Synthesis

2. This presentation is based on ECE 669
Required Reading
The ZYNQ Book
High-Level Synthesis
Chapter 14: Spotlight on High-Level Synthesis
Chapter 15: Vivado HLS: A Closer Look
Vivado Design Suite Tutorial, High-Level Synthesis,
UG871, Nov. 2014
Vivado Design Suite User Guide, High-Level Synthesis,
UG902, Oct. 2014
Introduction to FPGA Design with Vivado High-Level
Synthesis, UG998, Jul
A Zynq Accelerator for Floating Point Matrix multiplication Designed with Vivado HLS, XAPP1170, Jan. 2016
This presentation is based on ECE 669

3. Behavioral Synthesis High-Level Synthesis I/O Behavior Target Library
Algorithm
Behavioral
Synthesis
RTL Design
Logic
Synthesis
Classic RTL Design Flow
Gate level Netlist

4. Need for High-Level Design
High-Level Synthesis
Higher level of abstraction
Modeling complex designs
Reduce design efforts
Fast turnaround time
Technology independence
Ease of HW/SW partitioning

5. Platform Mapping SW/HW Partitioning
High-Level Synthesis
Program
Hardware
(executed in
the reconfigurable
processor
system)
Software
(executed in
the microprocessor
system)

6. SW/HW Partitioning & Coding
Traditional Approach
High-Level Synthesis
Specification
SW/HW Partitioning
SW Coding
HW Coding
SW Compilation
HW Compilation
SW Profiling
HW Profiling

7. SW/HW Partitioning & Coding
New Approach
High-Level Synthesis
Specification
SW/HW Coding
SW/HW Partitioning
SW Compilation
HW Compilation
SW Profiling
HW Profiling

8. Advantages of Behavioral Synthesis
High-Level Synthesis
Easy to model higher level of complexities
Smaller in size source compared to RTL code
Generates RTL much faster than manual method
Multi-cycle functionality
Loops
Memory Access

9. Short History of High-Level Synthesis
Generation 1 (1980s-early 1990s): research period
Generation 2 (mid 1990s-early 2000s):
Commercial tools from Synopsys, Cadence, Mentor Graphics, etc.
Input languages: behavioral HDLs Target: ASIC
Outcome: Commercial failure
Generation 3 (from early 2000s):
Domain oriented commercial tools: in particular for DSP
Input languages: C, C++, C-like languages (Impulse C, Handel C, etc.), Matlab + Simulink, Bluespec
Target: FPGA, ASIC, or both
Outcome: First success stories
High-Level Synthesis

10. Hardware-Oriented High-Level Languages
High-Level Synthesis
C-Based System level languages
Commercial
Handel C -- Celoxica Ltd.
Impulse C -- Impulse Accelerated Technologies
Carte C – SRC Computers
SystemC -- The Open SystemC Initiative
Research
Streams-C -- Los Alamos National Laboratory
SA-C -- Colorado State University, University of California, Riverside, Khoral Research, Inc.
SpecC – University of California, Irvine and SpecC Technology Open Consortium

11. Other High-Level Design Flows
High-Level Synthesis
Matlab-based
AccelChip DSP Synthesis -- AccelChip
System Generator for DSP -- Xilinx
GUI Data-Flow based
Corefire -- Annapolis Microsystems
Java-based
Commercial
Forge -- Xilinx
Research
JHDL – Brigham Young University

12. Handel-C Overview
High-level language based on ISO/ANSI-C for the implementation of algorithms in hardware
Allows software engineers to design hardware without retraining
Clean extensions for hardware design including flexible data widths, parallelism and communications
Well defined timing model
Each statement takes a single clock cycle
Includes extended operators for bit manipulation, and high-level mathematical macros (including floating point)
High-Level Synthesis

13. Handel-C/ANSI-C Comparisons
High-Level Synthesis
ANSI-C
HANDEL-C
Handel-C Standard Library
ANSI-C Standard Library
Preprocessors
i.e. #define
Parallelism
Pointers
Structures
Arbitrary width variables
ANSI-C Constructs
for, while, if, switch
Recursion
Arrays
Bitwise logical operators
Enhanced bit manipulation
Floating Point
Logical operators
Arithmetic operators
RAM, ROM
Signals
Functions
Interfaces

14. Executable Specification
Handel-C Design Flow
High-Level Synthesis
Executable Specification
Handel-C
VHDL
Synthesis
EDIF
EDIF
Place & Route

15. Different Levels of C/C++ Synthesis Abstraction
High-Level Synthesis
The Design Warrior’s Guide to FPGAs Devices, Tools, and Flows. ISBN Copyright © 2004 Mentor Graphics Corp. (

16. Pure Untimed C/C++ Design Flow
High-Level Synthesis
The Design Warrior’s Guide to FPGAs Devices, Tools, and Flows. ISBN Copyright © 2004 Mentor Graphics Corp. (

17. Mentor Graphics – Catapult C
High-Level Synthesis

18. Mentor Graphics – Catapult C
High-Level Synthesis
Catapult C automatically converts un-timed C/C++ descriptions into synthesizable RTL.

19. SystemC -based design-flow alternatives
High-Level Synthesis
Implementation specific, relatively slow to simulate, relatively difficult to modify
Auto-RTL
Translation
Verilog /
VHDL RTL
RTL
Synthesis
SystemC
Gate-level netlist
SystemC
Synthesis
Alternative SystemC flows

20. SystemC Evolution High-Level Synthesis
The Design Warrior’s Guide to FPGAs Devices, Tools, and Flows. ISBN Copyright © 2004 Mentor Graphics Corp. (

21. ECE 448 – FPGA and ASIC Design with VHDL
High-Level Synthesis
Reconfigurable
Supercomputers
ECE 448 – FPGA and ASIC Design with VHDL

22. Reconfigurable Computer?
What is a
Reconfigurable Computer?
High-Level Synthesis
Microprocessor system
Reconfigurable system P
. . . P
FPGA
. . .
FPGA P
memory P
memory
FPGA
memory
FPGA
memory
. . .
. . .
Interface
Interface
I/O
I/O

23. Reconfigurable Supercomputers
High-Level Synthesis
Machine
Released
SRC 6 from SRC Computers
Cray XD1 from from Cray
SGI Altix from
SGI
SRC 7 from
SRC Computers, Inc,
2002
2005
2006

24. Pros and cons of reconfigurable computers
High-Level Synthesis
+ can be programmed using high-level programming
languages, such as C, by mathematicians
& scientist themselves
+ facilitates hardware/software co-design
+ shortens development time, encourages experimentation
and complex optimizations
+ allows sharing costs among users of various
applications
high entry cost (~$100,000)
hardware aware programming
limited portability
limited availability of libraries
- limited maturity of tools.

25. SRC Programming Model Microprocessor FPGA Libraries of macros
High-Level Synthesis
function_1
macro_ macro_2
macro_ macro_4
……………………….
main.c
macro_1(a, b, c)
macro_2(b, d)
macro_2(c, e)
function_1()
function_2()
VHDL
FPGA
function_2
I/O a
macro_3(s, t)
macro_1(n, b)
macro_4(t, k)
Macro_1
ANSI C b c
Macro_2
Macro_2
MAP C
(subset of ANSI C) d e
I/O

26. SRC Compilation Process
High-Level Synthesis
Application sources
Macro sources
.c or .f files
.mc or .mf files . .
vhd or or
.v files
HDL
HDL
sources
sources
Logic synthesis
Logic synthesis
.v files
.v files  P
Compiler
MAP Compiler
Netlists . .
ngo
ngo
files
files
Object
.o files
.o files
files
Place & Route
Place & Route
Linker
Linker
.bin files
.bin files
Configuration
Application
bitstreams
executable

27. Library Development - SRC
High-Level Synthesis
LLL
(ASM)
HLL
(C, Fortran)
HLL
(C, Fortran)
P system
FPGA system
HDL
(VHDL, Verilog)
HLL
(C, Fortran)
HLL
(C, Fortran)
Library
Developer
Application
Programmer

28. SRC Programming Environment
High-Level Synthesis
+ very easy to learn and use
+ standard ANSI C + hides implementation details
+ very well integrated environment
+ mature - in production use for over 4 years with constant
improvements
- subset of C
- legacy C code requires rewriting
- C limitations in describing HW (paralellism, data types)
- closed environment, limited portability of code to
HW platforms other than SRC

29. Application Development for Reconfigurable Computers
High-Level Synthesis
Program
Entry
Platform
mapping
Debugging &
Verification
Compilation
Execution

30. Ideal Program Entry
High-Level Synthesis
Function
Program
Entry

31. Actual Program Entry Program Entry High-Level Synthesis Function
Preferred
Architectures
SW/HW
Partitioning
Use of FPGA
Resources
(multipliers,
μP cores)
FPGA
Mapping
Program
Entry
Data Transfers
& Synchronization
Sequence of Run-time
Reconfigurations
Use of Internal
and External Memories
SW/HW Interface

32. Cinderella Story AutoESL Design Technologies, Inc. (25 employees)
High-Level Synthesis
AutoESL Design Technologies, Inc. (25 employees)
Flagship product:
AutoPilot, translating C/C++/System C to VHDL or Verilog
Acquired by the biggest FPGA company, Xilinx Inc., in 2011
AutoPilot integrated into the primary Xilinx toolset, Vivado, as
Vivado HLS, released in 2012
“High-Level Synthesis for the Masses”

33. Hardware Description Language
Vivado HLS
High-Level Synthesis
High Level Language
C, C++, System C
Vivado
HLS
Hardware Description Language
VHDL or Verilog 33 33

34. HLS-Based Development and Benchmarking Flow
High-Level Synthesis
Reference Implementation in C
Manual Modifications
(pragmas, tweaks)
Test Vectors
HLS-ready C code
High-Level Synthesis
Functional
Verification
HDL Code
Post
Place & Route
Results
Physical Implementation
FPGA Tools
Timing
Verification
Netlist 34

35. Levels of Abstraction in FPGA Design
High-Level Synthesis
Source: The Zynq Book

36. High-Level Synthesis vs. Logic Synthesis
Source: The Zynq Book

37. Algorithm and Interface Synthesis
High-Level Synthesis
Source: The Zynq Book

38. High-Level Synthesis
Vivado HLS
Design Flow
Source: The Zynq Book

39. Design Trade-offs Explored Using HLS
High-Level Synthesis
Source: The Zynq Book

40. C Functional Verification and
C/RTL Cosimulation
in Vivado HLS
High-Level Synthesis
Source: The Zynq Book

41. Vivado HLS 41 41

42. Scheduling and Binding
Vivado HLS
Scheduling and Binding
High-Level Synthesis
Source: The Zynq Book

43. Scheduling and Binding
Vivado HLS
Scheduling and Binding
High-Level Synthesis
Scheduling – translation of the RTL statements interpreted
from the C code into a set of operations, each with an associated
duration in terms of clock cycles.
Affected by the clock frequency, uncertainty, target technology,
and user directives.
Binding - associating the scheduled operations with
the physical resources of the target device.
Source: The Zynq Book

44. Three Possible Outcomes from HLS
Average of 10 numbers
High-Level Synthesis
Source: The Zynq Book

45. Vivado HLS Synthesis Process
Source: The Zynq Book

46. Native Integer Data Types of C
High-Level Synthesis
Source: The Zynq Book

47. Arbitrary Precision Integer Data Types of C and C++ Accepted by Vivado HLS
High-Level Synthesis
Source: The Zynq Book

48. Arbitrary Precision Integer Types of
C and C++
High-Level Synthesis
Source: The Zynq Book

49. Native Floating-Point Data Types of C
High-Level Synthesis
Source: The Zynq Book

50. Fixed-point Word Format
High-Level Synthesis
Source: The Zynq Book

51. Arbitrary Precision Fixed-Point Data Types used in Vivado HLS
High-Level Synthesis
W – total width, I – number of integer bits
Q – quantization mode, O – overflow mode,
N – number of saturation bits in overflow wrap modes
Source: The Zynq Book

52. Quantization modes for for the C++ ap_fixed and ap_ufixed types
High-Level Synthesis
Source: The Zynq Book

53. Truncation to zero
High-Level Synthesis
Source: UG902 Vivado Design Suite User Guide, High-Level Synthesis

54. for the C++ ap_fixed and ap_ufixed types
Overflow modes for
for the C++ ap_fixed and ap_ufixed types
High-Level Synthesis
Source: The Zynq Book

55. Wraparound
High-Level Synthesis
Source: UG902 Vivado Design Suite User Guide, High-Level Synthesis

56. C++ code with the declaration of fixed point variables
High-Level Synthesis
Source: The Zynq Book

57. System C Data Types
High-Level Synthesis
Source: The Zynq Book

58. An Example Top-Level Function for HLS
High-Level Synthesis
Source: The Zynq Book

59. Simplified Interface Diagram for the Example Top-Level Function
High-Level Synthesis
Source: The Zynq Book

60. Synthesis of Port Directions
High-Level Synthesis
Source: The Zynq Book

61. Default Port Level Types and Protocols
High-Level Synthesis
Source: The Zynq Book

62. Port Interface Protocol Types
ap_none — This is the simplest protocol type, with no explicit interface protocol, no additional control signals, and no associated hardware overhead. However, there is an implication that timing of input and output operations is independently and correctly handled.
ap_stable — This is a similar protocol to ap_none, in that it does not involve additional control signals or related hardware. The difference is that ap_stable is intended for inputs (only) that change infrequently, i.e. that are generally stable apart from at reset, such as configuration data. The inputs are not constants, but neither do they require to be registered.
Source: The Zynq Book

63. Port Interface Protocol Types
ap_ack — This protocol behaves differently for input and output ports. For inputs, an output acknowledge port is added, and held high on the same clock cycle as the input is read. For outputs ports, an input acknowledge port is added. After every write to the output port, the design must wait for the input acknowledge to be asserted before it may resume operation.
ap_vld — An additional port is provided to validate data. For input ports, a valid input control port is added, which qualifies input data as valid. For output ports, a valid output port is added, and asserted on clock cycles when output data is valid.
Source: The Zynq Book

64. Port Interface Protocol Types
ap_ovld — This protocol is the same as ap_vld, but can only be implemented on output ports, or the output portion of an inout (bidirectional) port.
ap_hs — The _hs suffix of this protocol stands for ‘handshaking’, and it is a superset of ap_ack, ap_vld, and ap_ovld. The ap_hs protocol can be used for both input and output ports, and facilitates a two-way handshaking process between the producer and consumer of data, including both validation and acknowledgement transactions. As such, it requires two control ports and associated overhead. It is, however, a robust method of passing data, with no need to ensure timing externally
Source: The Zynq Book

65. Port Interface Protocol Types
ap_memory — This memory-based protocol supports random access transactions with a memory, and can be used for both input, output, and bidirectional ports. The only argument type compatible with this protocol is the array type, which corresponds with the structure of a memory. The ap_memory protocol requires control signals for clock and write enables, as well as an address port.
Source: The Zynq Book

66. Port Interface Protocol Types
ap_fifo — The FIFO protocol is also compatible with array arguments, provided that they are accessed sequentially rather than in random order. It does not require any address information to be generated, and therefore is simpler in implementation than the ap_memory interface. The ap_fifo protocol can be used for input and output ports, but not bidirectional ports. The associated control ports indicate the fullness or emptiness of the FIFO, depending on the port direction, and ensure that processing is stalled to prevent overrun or underrun.
Source: The Zynq Book

67. Port Interface Protocol Types
ap_bus — The ap_bus protocol is a generic bus interface that is not tied to a specific bus standard, and may be used to communicate with a bus bridge, which can then arbitrate with a system bus. The ap_bus protocol supports single read operations, single write operations, and burst transfers, and these are coordinated using a set of control signals. In addition to this generic bus interface, specific support for AXI bus interfaces can be integrated at a later stage, using an interface synthesis directive.
Source: The Zynq Book

68. Port Interface Protocol Types
bram — The same as ap_memory, except that when bundled using IP Integrator, the ports are not shown as individual ports, but grouped together into a single port.
axis — This specifies the interface as AXI stream.
s_axilite — This specifies the interface as AXI Slave Lite.
m_axi — This specifies the interface the AXI Master protocol.
Source: The Zynq Book

69. Port Interface Protocol Types
S – Supported, D - default
Source: The Zynq Book

70. Block-level Protocol
There are three types of block-level protocol, and these are listed below according to the terms used in Vivado HLS:
ap_ctrl_none — Choosing this option simply means that a block-level protocol is not added. Instead, control is exerted entirely at the port interface level, using portlevel protocols.
ap_ctrl_hs — A block-level control protocol with handshaking. An ap_start control input is asserted to prompt the block to begin operation, and the block produces three output control signals (ap_ready, ap_idle, and ap_done) to indicate its stage of operation. Specifically, the ap_ready signal indicates that the block is ready for new inputs, the ap_idle indicates when it is processing data, and ap_done is asserted when output data is available. To provide a usage example, the ap_ctrl_hs protocol is appropriate when a single HLS block is to be interfaced with the controlling processor.
Source: The Zynq Book

71. Block-level Protocol
There are three types of block-level protocol, and these are listed below according to the terms used in Vivado HLS:
ap_ctrl_chain —This protocol is similar to ap_ctrl_hs, but has an additional input control signal, ap_continue, and is designed for chaining multiple Vivado HLS blocks together. The ap_continue input indicates the ability of the downstream block to accept new data, and therefore it can exert backpressure on upstream blocks if necessary. If ap_continue is de-asserted, the block will complete its current computation to the stage of presenting the results at the output, but will then stall until ap_continue is set high again.
Source: The Zynq Book

72. RTL Interface Diagram Showing Default Block Level Ports and Protocols
High-Level Synthesis
Source: The Zynq Book

73. Directive Types
There are six types of directive which can be applied to both port-level and block-level interfaces, as reviewed below.
Array Map — Combines several arrays to form one larger array, with the goal of using fewer FIFO or RAM resources and control ports to implement the interface.
Array Partition — Separates array interfaces into several smaller sections, resulting in an expanded set of ports, control signals, and implementation resources, but with increased bandwidth.
Array Reshape — In this case, an original array is partitioned into smaller arrays, which are then recombined to form an array with fewer elements, and wider data elements. This implies fewer memory locations and shorter addresses.
Interface — This directive can be used to explicitly specify a port-level interface protocol as one of the available options (as listed in Table 15.7 on page 300), or the block-level protocol as ap_none, ap_ctrl_block or ap_ctrl_chain, as covered in Section
Source: The Zynq Book

74. Directive Types
There are six types of directive which can be applied to both port-level and block-level interfaces, as reviewed below.
Resource — A particular resource can be chosen to implement the interface. For instance, a one or two port RAM can be specified for an ap_memory interface, or an ap_fifo interface can target a FIFO constructed from a Block RAM or LUTs.
Stream — This directive specifies the interface as a streaming port, utilising FIFOs and permitting the depth of the FIFO to be explicitly chosen.
Source: The Zynq Book

75. Data flow between Vivado HLS blocks
High-Level Synthesis
Source: The Zynq Book