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

Download PDF
ID 683152
Date 10/04/2021
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
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 Stallable and Stall-Free Memory Systems Strategies that Enable Concurrent Stall-Free Memory Accesses 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

3.3.4.1. Component Memory

If you declare an array inside your component, the Intel® HLS Compiler creates component memory in hardware. Component memory is sometimes referred to as local memory or on-chip memory because it is created from memory resources (such as RAM blocks) available on the FPGA.

The following source code snippet results in the creation of a component memory system, an interface to an external memory system, and access to these memory systems: 

#include <HLS/hls.h>

constexpr int SIZE = 128;
constexpr int N = SIZE - 1;

using HostInterface = ihc::mm_host<int, ihc::waitrequest<true>, 
                                       ihc::latency<0>>;

component void memoryComponent(HostInterface &hostA)
{
    hls_memory int T[SIZE]; // declaring an array as a component memory
    for (unsigned i = 0; i < SIZE; i++)
    {
        T[i] = i; // writing to component memory
    }
    for (int i = 0; i < N; i += 2)
    {
        // reading from a component memory and writing to a external 
        // Avalon memory-mapped agent component through an Avalon
        // memory-mapped host interface
        hostA[i] = T[i] + T[i + 1];
    }
}

The compiler performs the following tasks to build a memory system:

  • Build a component memory from FPGA memory resources (such as block RAMs) and presents it to the datapath as a single memory.
  • Map each array access to a load-store unit (LSU) in the datapath that transacts with the component memory through its ports.
  • Automatically optimizes the component memory geometry to maximize the bandwidth available to loads and stores in the datapath.
  • Attempts to guarantee that component memory accesses never stall.
To learn more about controlling memory system architectures, review the following topics:

Stallable and Stall-Free Memory Systems

Accesses to a memory (read or write) can be stall-free or stallable:
Stall-free memory access
A memory access is stall-free if it has contention-free access to a memory port. A memory system is stall-free if each of its memory operations has contention-free access to a memory port.
Stallable memory access
A memory access is stallable if it does not have contention free access to a memory port. When two datapath LSUs try to transact with a memory port in the same clock cycle, one of those memory accesses is delayed (or stalled) until the memory port in contention becomes available.

As much as possible, the Intel® HLS Compiler tries to create stall-free memory systems for your component.

Figure 22. Examples of Stall-free and Stallable Memory Systems
This figure shows the following example memory systems:
  • A: A stall-free memory system

    This memory system is stall-free because, even though the reads are scheduled in the same cycle, they are mapped to different ports. There is no contention for accessing the memory ports.

  • B: A stall-free memory system

    This memory system is stall-free because the two reads are statically-scheduled to occur in different clock cycles. The two reads can share a memory port without any contention for the read access.

  • C: A stallable memory system

    This memory system is stallable because two reads are mapped to the same port in the same cycle. The two reads happen at the same time. There reads require collision arbitration to manage their port access requests, and arbitration can affect throughput.



A component memory system consists of the following parts:
Port
A memory port is a physical access point into a memory. A port is connected to one or more load-store units (LSUs) in the datapath. An LSU can connect to one or more ports. A port can have one or more LSUs connected.
Bank
A memory bank is a division of the component memory system that contains of subset of the data stored. That is, all the of the data stored for a component is split across banks, with each bank containing a unique piece of the stored data.

A memory system always has at least one bank.

Replicate
A memory bank replicate is a copy of the data in the memory bank with its own ports. All replicates in a bank contain the same data. Each replicate can be accessed independent of the others

A memory bank always has at least one replicate.

Private Copy
A private copy is a copy of the data in a replicate that is created for nested loops to enable concurrent iterations of the outer loop.

A replicate can comprise multiple private copies, with each iteration of an outer loop having its own private copy. Because each outer loop iteration has its own private copy, private copies are not expected to all contain the same data.

The following figure illustrates the relationship between banks, replicates, ports, and private copies:

Figure 23. Schematic Representation of Component Memories Showing the Relationship between Banks, Replicates, Ports, and Private Copies


Strategies that Enable Concurrent Stall-Free Memory Accesses

The compiler uses a variety of strategies to ensure that concurrent accesses are stall-free including:

Despite the compiler’s best efforts, the component memory system can still be stallable. This might happen due to resource constraints or memory attributes defined in your source code. In that case, the compiler tries to minimize the hardware resources consumed by the arbitrated memory system.

Level Two Title