Intel® High Level Synthesis Compiler Pro Edition: Best Practices Guide

Download PDF
ID 683152
Date 12/04/2023
Public

A newer version of this document is available. Customers should click here to go to the newest version.

Document Table of Contents
Document Table of Contents x
1. Intel® HLS Compiler Pro Edition Best Practices Guide 2. Best Practices for Coding and Compiling Your Component 3. FPGA Concepts 4. Interface Best Practices 5. Loop Best Practices 6. fMAX Bottleneck Best Practices 7. Memory Architecture Best Practices 8. System of Tasks Best Practices 9. Datatype Best Practices 10. Advanced Troubleshooting A. Intel® HLS Compiler Pro Edition Best Practices Guide Archives B. Document Revision History for Intel® HLS Compiler Pro Edition Best Practices Guide
1. Intel® HLS Compiler Pro Edition Best Practices Guide x
1.1. Pending Deprecation of the Intel® HLS Compiler
3. FPGA Concepts x
3.1. FPGA Architecture Overview 3.2. Concepts of FPGA Hardware Design 3.3. Methods of Hardware Design
3.1. FPGA Architecture Overview x
3.1.1. Adaptive Logic Module (ALM) 3.1.2. Digital Signal Processing (DSP) Block 3.1.3. Random-Access Memory (RAM) Blocks
3.1.1. Adaptive Logic Module (ALM) x
3.1.1.1. Lookup Table (LUT) 3.1.1.2. Register
3.2. Concepts of FPGA Hardware Design x
3.2.1. Maximum Frequency (fMAX) 3.2.2. Latency 3.2.3. Pipelining 3.2.4. Throughput 3.2.5. Datapath 3.2.6. Control Path 3.2.7. Occupancy
3.3. Methods of Hardware Design x
3.3.1. How Source Code Becomes a Custom Hardware Datapath 3.3.2. Scheduling 3.3.3. Mapping Parallelism Models to FPGA Hardware 3.3.4. Memory Types
3.3.1. How Source Code Becomes a Custom Hardware Datapath x
3.3.1.1. Mapping Source Code Instructions to Hardware 3.3.1.2. Mapping Arrays and Their Accesses to Hardware
3.3.2. Scheduling x
3.3.2.1. Dynamic Scheduling 3.3.2.2. Clustering the Datapath 3.3.2.3. Handshaking Between Clusters
3.3.3. Mapping Parallelism Models to FPGA Hardware x
3.3.3.1. Data Parallelism 3.3.3.2. Task Parallelism
3.3.3.1. Data Parallelism x
3.3.3.1.1. Executing Independent Operations Simultaneously 3.3.3.1.2. Pipelining
3.3.3.1.2. Pipelining x
3.3.3.1.2.1. Pipelining Loops Within A Component 3.3.3.1.2.2. Pipelining Across Component Invocations
3.3.4. Memory Types x
3.3.4.1. Component Memory 3.3.4.2. External Memory
4. Interface Best Practices x
4.1. Choose the Right Interface for Your Component 4.2. Control LSUs For Your Variable-Latency MM Host Interfaces 4.3. Avoid Pointer Aliasing
4.1. Choose the Right Interface for Your Component x
4.1.1. Pointer Interfaces 4.1.2. Avalon® Memory Mapped Host Interfaces 4.1.3. Avalon® Memory Mapped Agent Memories 4.1.4. Avalon® Memory Mapped Agent Registers 4.1.5. Avalon® Streaming Interfaces 4.1.6. Pass-by-Value Interface
5. Loop Best Practices x
5.1. Reuse Hardware By Calling It In a Loop 5.2. Parallelize Loops 5.3. Construct Well-Formed Loops 5.4. Minimize Loop-Carried Dependencies 5.5. Avoid Complex Loop-Exit Conditions 5.6. Convert Nested Loops into a Single Loop 5.7. Place if-Statements in the Lowest Possible Scope in a Loop Nest 5.8. Declare Variables in the Deepest Scope Possible 5.9. Raise Loop II to Increase fMAX 5.10. Control Loop Interleaving
5.2. Parallelize Loops x
5.2.1. Pipeline Loops 5.2.2. Unroll Loops 5.2.3. Example: Loop Pipelining and Unrolling
6. fMAX Bottleneck Best Practices x
6.1. Balancing Target fMAX and Target II
7. Memory Architecture Best Practices x
7.1. Example: Overriding a Coalesced Memory Architecture 7.2. Example: Overriding a Banked Memory Architecture 7.3. Merge Memories to Reduce Area 7.4. Example: Specifying Bank-Selection Bits for Local Memory Addresses
7.3. Merge Memories to Reduce Area x
7.3.1. Example: Merging Memories Depth-Wise 7.3.2. Example: Merging Memories Width-Wise
8. System of Tasks Best Practices x
8.1. Executing Multiple Loops in Parallel 8.2. Sharing an Expensive Compute Block 8.3. Implementing a Hierarchical Design 8.4. Balancing Capacity in a System of Tasks
8.4. Balancing Capacity in a System of Tasks x
8.4.1. Enable the Intel® HLS Compiler to Infer Data Path Buffer Capacity Requirements 8.4.2. Explicitly Add Buffer Capacity to Your Design When Needed
9. Datatype Best Practices x
9.1. Avoid Implicit Data Type Conversions 9.2. Avoid Negative Bit Shifts When Using the ac_int Datatype
10. Advanced Troubleshooting x
10.1. Component Fails Only In Simulation 10.2. Component Gets Poor Quality of Results
1. Intel® HLS Compiler Pro Edition Best Practices Guide
2. Best Practices for Coding and Compiling Your Component
3. FPGA Concepts
4. Interface Best Practices
5. Loop Best Practices
6. fMAX Bottleneck Best Practices
7. Memory Architecture Best Practices
8. System of Tasks Best Practices
9. Datatype Best Practices
10. Advanced Troubleshooting
A. Intel® HLS Compiler Pro Edition Best Practices Guide Archives
B. Document Revision History for Intel® HLS Compiler Pro Edition Best Practices Guide

4.1.5. Avalon® Streaming Interfaces

Avalon® Streaming ( Avalon® ST) interfaces support a unidirectional flow of data, and are typically used for components that drive high-bandwidth and low-latency data.

The vector addition example can be coded with an Avalon® ST interface as follows: 
struct int_v8 {
  int data[8];
};
component void vector_add(
    ihc::stream_in<int_v8>&  a,
    ihc::stream_in<int_v8>&  b,
    ihc::stream_out<int_v8>& c,
    int N) {
  for (int j = 0; j < (N/8); ++j) {
    int_v8 av = a.read(); 
    int_v8 bv = b.read(); 
    int_v8 cv; 
    #pragma unroll 8
    for (int i = 0; i < 8; ++i) {
      cv.data[i] = av.data[i] + bv.data[i];
    }
    c.write(cv);
  }
}

An Avalon® ST interface has a data bus, and ready and busy signals for handshaking. The struct is created to pack eight integers so that eight operations at a time can occur in parallel to provide a comparison with the examples for other interfaces. Similarly, the loop count is divided by eight.

The following diagram shows the Function View in the System Viewer that is generated when you compile this example.
Figure 27. System Viewer Function View of vector_add Component with Avalon® ST Interface


The main difference from other versions of the example component is the absence of memory.

The streaming interfaces are stallable from the upstream sources and the downstream output. Because the interfaces are stallable, the loop initiation interval (II) is approximately 1 (instead of exactly 1). If the component does not receive any bubbles (gaps in data flow) from upstream or stall signals from downstream, then the component achieves the desired II of 1.

If you know that the stream interfaces will never stall, you can further optimize this component by taking advantage of the usesReady and usesValid stream parameters.

Compiling this component with an Intel® Quartus® Prime compilation flow targeting an Intel® Arria® 10 device results in the following QoR metrics:
Table 5.  QoR Metrics Comparison for Avalon® ST Interface1
QoR Metric Pointer Avalon® MM Host Avalon® MM Agent Avalon® ST
ALMs 15593.5 643 490.5 314.5
DSPs 0 0 0 0
RAMs 30 0 48 0
fMAX (MHz)2 298.6 472.37 498.26 389.71
Latency (cycles) 24071 142 139 134
Initiation Interval (II) (cycles) ~508 1 1 1
1The compilation flow used to calculate the QoR metrics used Intel® Quartus® Prime Pro Edition Version 17.1.
2The fMAX measurement was calculated from a single seed.
Moving the vector_add component to an Avalon® ST interface, further improved ALM usage, RAM usage, and component latency. The component II is optimal if there are no stalls from the interfaces.
Level Two Title