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

Download PDF
ID 683259
Date 12/18/2019
Public
Document Table of Contents
Document Table of Contents x
1. Intel® HLS Compiler Standard Edition Best Practices Guide 2. Best Practices for Coding and Compiling Your Component 3. Interface Best Practices 4. Loop Best Practices 5. Memory Architecture Best Practices 6. Datatype Best Practices 7. Advanced Troubleshooting A. Intel® HLS Compiler Standard Edition Best Practices Guide Archives B. Document Revision History for Intel® HLS Compiler Standard Edition Best Practices Guide
3. Interface Best Practices x
3.1. Choose the Right Interface for Your Component 3.2. Avoid Pointer Aliasing
3.1. Choose the Right Interface for Your Component x
3.1.1. Pointer Interfaces 3.1.2. Avalon® Memory Mapped Master Interfaces 3.1.3. Avalon® Memory Mapped Slave Interfaces 3.1.4. Avalon® Streaming Interfaces 3.1.5. Pass-by-Value Interface
4. Loop Best Practices x
4.1. Reuse Hardware By Calling It In a Loop 4.2. Parallelize Loops 4.3. Construct Well-Formed Loops 4.4. Minimize Loop-Carried Dependencies 4.5. Avoid Complex Loop-Exit Conditions 4.6. Convert Nested Loops into a Single Loop 4.7. Declare Variables in the Deepest Scope Possible
4.2. Parallelize Loops x
4.2.1. Pipeline Loops 4.2.2. Unroll Loops 4.2.3. Example: Loop Pipelining and Unrolling
5. Memory Architecture Best Practices x
5.1. Example: Overriding a Coalesced Memory Architecture 5.2. Example: Overriding a Banked Memory Architecture 5.3. Merge Memories to Reduce Area 5.4. Example: Specifying Bank-Selection Bits for Local Memory Addresses
5.3. Merge Memories to Reduce Area x
5.3.1. Example: Merging Memories Depth-Wise 5.3.2. Example: Merging Memories Width-Wise
6. Datatype Best Practices x
6.1. Avoid Implicit Data Type Conversions 6.2. Avoid Negative Bit Shifts When Using the ac_int Datatype
7. Advanced Troubleshooting x
7.1. Component Fails Only In Cosimulation 7.2. Component Gets Bad Quality of Results
1. Intel® HLS Compiler Standard Edition Best Practices Guide
2. Best Practices for Coding and Compiling Your Component
3. Interface Best Practices
4. Loop Best Practices
5. Memory Architecture Best Practices
6. Datatype Best Practices
7. Advanced Troubleshooting
A. Intel® HLS Compiler Standard Edition Best Practices Guide Archives
B. Document Revision History for Intel® HLS Compiler Standard Edition Best Practices Guide

3.1.1. Pointer Interfaces

Software developers accustomed to writing code that targets a CPU might first try to code this algorithm by declaring vectors a, b, and c as pointers to get the data in and out of the component.
Using pointers in this way results in a single Avalon Memory-Mapped (MM) Master interface that the three input variables share.

Pointers in a component are implemented as Avalon® Memory Mapped ( Avalon® MM) master interfaces with default settings. For more details about pointer parameter interfaces, see Intel HLS Compiler Default Interfaces in Intel® High Level Synthesis Compiler Standard Edition Reference Manual.

The vector addition component example with pointer interfaces can be coded as follows: 
component void vector_add(int* a,
                          int* b,
                          int* c,
                          int N) {
  #pragma unroll 8
  for (int i = 0; i < N; ++i) {
    c[i] = a[i] + b[i];
  }
}
The following diagram shows the Component Viewer report generated when you compile this example. Because the loop is unrolled by a factor of 8, the diagram shows that vector_add.B2 has 8 loads for vector a, 8 loads for vector b, and 8 stores for vector c. In addition, all of the loads and stores are arbitrated on the same memory, resulting in inefficient memory accesses.
Figure 1. Component View of vector_add Component with Pointer Interfaces


The following Loop Analysis report shows that the component has an undesirably high loop initiation interval (II). The II is high because vectors a, b, and c are all accessed through the same Avalon MM Master interface. The Intel® HLS Compiler uses stallable arbitration logic to schedule these accesses, which results in poor performance and high FPGA area use.

In addition, the compiler cannot assume there are no data dependencies between loop iterations because pointer aliasing might exist. The compiler cannot determine that vectors a, b, and c do not overlap. If data dependencies exist, the Intel® HLS Compiler cannot pipeline the loop iterations effectively.



Compiling the component with an Intel® Quartus® Prime compilation flow targeting an Intel® Arria® 10 device results in the following QoR metrics, including high ALM usage, high latency, high II, and low fMAX. All of which are undesirable properties in a component.
Table 2.  QoR Metrics for a Component with a Pointer Interface1
QoR Metric Value
ALMs 15593.5
DSPs 0
RAMs 30
fMAX (MHz)2 298.6
Latency (cycles) 24071
Initiation Interval (II) (cycles) ~508
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.
Level Two Title