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.2. Avalon® Memory Mapped Master Interfaces

By default, pointers in a component are implemented as Avalon® Memory Mapped (MM) master interfaces with default settings. You can mitigate poor performance from the default settings by configuring the Avalon® MM master interfaces.

You can configure the Avalon® MM master interface for the vector addition component example using the ihc::mm_master class as follows: 

component void vector_add(

ihc::mm_master<int, ihc::aspace<1>, ihc::dwidth<8*8*sizeof(int)>, 
ihc::align<8*sizeof(int)> >& a,

ihc::mm_master<int, ihc::aspace<2>, ihc::dwidth<8*8*sizeof(int)>, 
ihc::align<8*sizeof(int)> >& b,

ihc::mm_master<int, ihc::aspace<3>, ihc::dwidth<8*8*sizeof(int)>, 
ihc::align<8*sizeof(int)> >& c,

                          int N) {
  #pragma unroll 8
  for (int i = 0; i < N; ++i) {
      c[i] = a[i] + b[i];
  }
  }
The memory interfaces for vector a, vector b, and vector c have the following attributes specified:
  • The vectors are each assigned to different address spaces with the ihc::aspace attribute, and each vector receives a separate Avalon® MM master interface.

    With the vectors assigned to different physical interfaces, the vectors can be accessed concurrently without interfering with each other, so memory arbitration is not needed.

  • The width of the interfaces for the vectors is adjusted with the ihc::dwidth attribute.
  • The alignment of the interfaces for the vectors is adjusted with the ihc::align attribute.
The following diagram shows the Component Viewer report generated when you compile this example.
Figure 2. Component View of vector_add Component with Avalon® MM Master Interface


The diagram shows that vector_add.B2 has two loads and one store. The default Avalon® MM master settings used by the code example in Pointer Interfaces had 16 loads and 8 stores.

By expanding the width and alignment of the vector interfaces, the original pointer interface loads and stores were coalesced into one wide load each for vector a and vector b, and one wide store for vector c.

Also, the memories are stall-free because the loads and stores in this example access separate memories.

Compiling this component with an Intel® Quartus® Prime compilation flow targeting an Intel® Arria® 10 device results in the following QoR metrics:
Table 3.  QoR Metrics Comparison for Avalon MM Master Interface1
QoR Metric Pointer Avalon MM Master
ALMs 15593.5 643
DSPs 0 0
RAMs 30 0
fMAX (MHz)2 298.6 472.37
Latency (cycles) 24071 142
Initiation Interval (II) (cycles) ~508 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.
All QoR metrics improved by changing the component interface to a specialized Avalon® MM master interface from a pointer interface. The latency is close to the ideal latency value of 128, and the loop initiation interval (II) is 1.
Important: This change to a specialized Avalon® MM master interface from a pointer interface requires the system to have three separate memories with the expected width. The initial pointer implementation requires only one system memory with a 64-bit wide data bus. If the system cannot provide the required memories, you cannot use this optimization.
Level Two Title