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

Download PDF
ID 683152
Date 12/19/2022
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
1. Intel® HLS Compiler Pro Edition Best Practices Guide x
1.1. Pending Deprecation of the Intel® HLS Compiler
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 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

8.4.1. Enable the Intel® HLS Compiler to Infer Data Path Buffer Capacity Requirements

In many situations, the Intel® HLS Compiler can add buffer capacity automatically to the data path in a system of tasks design to achieve maximum throughput for your design. Follow a few best practices to help the Intel® HLS Compiler effectively add data path buffer capacity to your design when needed.

As an example, consider the following design that runs two independent tasks. This kind of structure can be generated by code like the following example: 
component foo() {
  // Parse/compute data for tasks
  ihc::launch<task1>(data1);
  ihc::launch<task2>(data2);

  auto r1 = ihc::collect<task1>();
  auto r2 = ihc::collect<task2>();
  // Usage of r1, r2
}
The following diagram shows the state of the system of tasks at the start of the third invocation of the component, and the location of data in the overall pipeline from previous invocations.
Figure 43. Data Flow of Multiple Component Invocations Through a System of TasksThe circles represent pipelined stages of the component, while the number indicate the location of data from different invocations of component foo. This digram shows three invocations of the component underway.


In this diagram, Entry represents the two independent launch calls, and the Exit represents the two independent collect calls.

Entry provides work to both tasks only if both tasks can take in data (that is, both task have available buffer capacity). Similarly, Exit consumes the results only when both results are available.

If Task1 and Task2 have the same number of pipeline stages, then the data path performs at full throughput. Some data path buffer capacity is needed in the caller function to ensure that the caller can continue issuing launch calls while the collect calls wait for the task functions to complete. The compiler adds this data path buffer capacity automatically.

If the two tasks have different pipeline depths, then the design encounters a bottleneck because the task with the smaller pipeline depth lacks the buffer capacity to store finished results while waiting for the other task to finish. In this case, you can add buffer capacity to either launch or the collect call of the task with the smaller pipeline depth. For details about adding launch/collect buffer capacity, see Explicitly Add Buffer Capacity to Your Design When Needed.

The Intel® HLS Compiler tries to balance data path buffer capacity automatically, but it can only add data path capacity automatically when your design follows certain practices.

Use the following best practices to obtain the maximum throughput for your system of tasks design:
  • A component or task function should do one of the following things:
    • Do all of the work by itself without launching other tasks.
    • Act as an orchestrator for issuing ihc::launch or ihc::collect calls and do none of the work.
  • If throughput is a priority for your design, avoid using multiple ihc::launch or ihc::collect calls to the same task function unless you are reusing the calls to the function by iterating in a loop.
  • Keep ihc::launch and ihc::collect calls to the same task function within the same block.

    Review the block structure of your design with the Graph Viewer in the High-Level Design Reports to confirm that your calls are in the same block.

  • Avoid guarding your ihc::launch and ihc::collect calls with an if-condition.

    If you are guarding your ihc::launch and ihc::collect calls with an if-condition, use the same if-condition for both the ihc::launch and ihc::collect calls.

Level Two Title