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

5.3.1. Example: Merging Memories Depth-Wise

Use the hls_merge("<mem_name>","depth") attribute to force the Intel® HLS Compiler Standard Edition to implement variables in the same memory system, merging their memories by depth.

All variables with the same <mem_name> label set in their hls_merge attributes are merged.

Consider the following component code:

component int depth_manual(bool use_a, int raddr, int waddr, int wdata) {
  int a[128];
  int b[128];

  int rdata;

  // mutually exclusive write
  if (use_a) {
    a[waddr] = wdata;
  } else {
    b[waddr] = wdata;
  }

  // mutually exclusive read
  if (use_a) {
    rdata = a[raddr];
  } else {
    rdata = b[raddr];
  }

  return rdata;
}

The code instructs the Intel® HLS Compiler to implement local memories a and b as two on-chip memory blocks, each with its own load and store instructions.

Figure 13. Implementation of Local Memory for Component depth_manual

Because the load and store instructions for local memories a and b are mutually exclusive, you can merge the accesses, as shown in the example code below. Merging the memory accesses reduces the number of load and store instructions, and the number of on-chip memory blocks, by half. 

component int depth_manual(bool use_a, int raddr, int waddr, int wdata) {
  int a[128] hls_merge("mem","depth");
  int b[128] hls_merge("mem","depth");

  int rdata;

  // mutually exclusive write
  if (use_a) {
    a[waddr] = wdata;
  } else {
    b[waddr] = wdata;
  }

  // mutually exclusive read
  if (use_a) {
    rdata = a[raddr];
  } else {
    rdata = b[raddr];
  }

  return rdata;
}
Figure 14. Depth-Wise Merge of Local Memories for Component depth_manual

There are cases where merging local memories with respect to depth might degrade memory access efficiency. Before you decide whether to merge the local memories with respect to depth, refer to the HLD report ( <result>.prj/reports/report.html) to ensure that they have produced the expected memory configuration with the expected number of loads and stores instructions. In the example below, the Intel® HLS Compiler should not merge the accesses to local memories a and b because the load and store instructions to each memory are not mutually exclusive. 

component int depth_manual(bool use_a, int raddr, int waddr, int wdata) {
  int a[128] hls_merge("mem","depth");
  int b[128] hls_merge("mem","depth");

  int rdata;

  // NOT mutually exclusive write

  a[waddr] = wdata;
  b[waddr] = wdata;
  
  // NOT mutually exclusive read

  rdata = a[raddr];
  rdata += b[raddr];
  
  return rdata;
}

In this case, the Intel® HLS Compiler might double pump the memory system to provide enough ports for all the accesses. Otherwise, the accesses must share ports, which prevent stall-free accesses.

Figure 15. Local Memories for Component depth_manual with Non-Mutually Exclusive Accesses
Level Two Title