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.1. Example: Overriding a Coalesced Memory Architecture

Using memory attributes in various combinations in your code allows you to override the memory architecture that the Intel® HLS Compiler Standard Edition infers for your component.

The following code examples demonstrate how you can use the following memory attributes to override coalesced memory to conserve memory blocks on your FPGA:

  • hls_bankwidth(n)
  • hls_numbanks(n)
  • hls_singlepump
  • hls_numports_readonly_writeonly(m,n)

The original code coalesces two memory accesses, resulting in a memory memory system that is to 256 bits wide by 64 bits wide (two on-chip memory blocks): 

component unsigned int mem_coalesce_default(unsigned int raddr,
                                            unsigned int waddr,
                                            unsigned int wdata){
    unsigned int data[512];
    data[2*waddr] = wdata;
    data[2*waddr + 1] = wdata + 1;
    unsigned int rdata = data[2*raddr] + data[2*raddr + 1];
    return rdata;
}

The following images show how the 256x64 bit memory for this code sample is structured, as well how the component memory structure is shown in the high-level design report (report.html)

Figure 10. Memory Structure Generated for mem_coalesce_default

The modified code implements a simple dual-port on-chip memory block that is 512 words deep by 32 bits wide with stallable arbitration: 

component unsigned int mem_coalesce_override(unsigned int raddr,
                                             unsigned int waddr,
                                             unsigned int wdata){
    //Attributes that stop memory coalescing
    hls_bankwidth(4) hls_numbanks(1)
    //Attributes that specify a simple dual port
    hls_singlepump hls_numports_readonly_writeonly(1,1)
    unsigned int data[512];
    data[2*waddr] = wdata;
    data[2*waddr + 1] = wdata + 1;
    unsigned int rdata = data[2*raddr] + data[2*raddr + 1];
    return rdata;
}
Tip: Instead of specifying the hls_singlepump and hls_numports_readonly_writeonly(1,1) attributes, you can specify this configuration with the hls_simple_dual_port_memory attribute.

The following images show how the 512x32 bit memory with stallable arbitration for this code sample is structured, as well how the component memory structure is shown in the high-level design report (report.html).

Figure 11. Memory Structure Generated for mem_coalesce_override

While it might appear that you save hardware area by reducing the number of RAM blocks needed for the component, the introduction of stallable arbitration increases the amount of hardware needed to implement the component. In the following table, you can compare the number ALMs and FFs required by the components.



Level Two Title