Developer Guide

FPGA Optimization Guide for Intel® oneAPI Toolkits

Download PDF
ID 767853
Date 7/13/2023
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
FPGA Optimization Guide for Intel® oneAPI Toolkits Introduction To FPGA Design Concepts Analyze Your Design Optimize Your Design FPGA Optimization Flags, Attributes, Pragmas, and Extensions Quick Reference Additional Information Document Revision History for the FPGA Optimization Guide for Intel® oneAPI Toolkits
Introduction To FPGA Design Concepts x
FPGA Architecture Overview Concepts of FPGA Hardware Design Methods of Hardware Design How Source Code Becomes a Custom Hardware Datapath Scheduling Mapping Parallelism Models to FPGA Hardware Memory Types
FPGA Architecture Overview x
Adaptive Logic Module (ALM) Lookup Table (LUT) Register Digital Signal Processing (DSP) Block Random Access Memory (RAM) Blocks
Concepts of FPGA Hardware Design x
Maximum Frequency (fMAX) Latency Pipelining Throughput Datapath Control Path Occupancy
How Source Code Becomes a Custom Hardware Datapath x
Mapping Source Code Instructions to Hardware Mapping Arrays and Their Accesses to Hardware
Scheduling x
Dynamic Scheduling Clustering the Datapath Handshaking Between Clusters
Mapping Parallelism Models to FPGA Hardware x
Data Parallelism Task Parallelism
Data Parallelism x
Executing Independent Operations Simultaneously Pipelining Example of Vectorization of the Datapath vs. Pipelining the Datapath Pipelining Loops Within a Single Work Item Pipelining Across Multiple Work Items
Memory Types x
Kernel Memory Global Memory
Analyze Your Design x
Analyze the FPGA Early Image Analyze the FPGA Image
Analyze the FPGA Early Image x
Review the FPGA Optimization Report Access HLD FPGA Reports in JSON Format
Review the FPGA Optimization Report x
Loop Analysis Bottlenecks Viewer Area Estimates System Viewer Kernel Memory Viewer Schedule Viewer
Analyze the FPGA Image x
Quartus (Static) Summary Intel® FPGA Dynamic Profiler for DPC++ System-level Profiling Using the Intercept Layer for OpenCL* Applications
Quartus (Static) Summary x
Timing Failures
Intel® FPGA Dynamic Profiler for DPC++ x
Measure Kernel Performance Instrument the Kernel Pipeline with Performance Counters (-Xsprofile) Obtain Profiling Data During Runtime Reduce Area Resource Use While Profiling Profiler Analyses of Example SYCL* Design Scenarios Limitations
Obtain Profiling Data During Runtime x
Invoke the Profiler Runtime Wrapper to Obtain Profiling Data Use Intel® VTune™ Profiler
Use Intel® VTune™ Profiler x
Interpret Performance Counter Data
System-level Profiling Using the Intercept Layer for OpenCL* Applications x
Set Up the Intercept Layer for OpenCL* Applications
Optimize Your Design x
Throughput Resource Use
Throughput x
Single Work-item Kernels NDRange Kernels Memory Accesses Pipes Host
Single Work-item Kernels x
Single Work-item Kernel Design Guidelines Loops Single-Cycle Floating-Point Accumulator for Single Work-Item Kernels
Loops x
Refactor the Loop-Carried Data Dependency Relax Loop-Carried Dependency Transfer Loop-Carried Dependency to Local Memory Minimize the Memory Dependencies for Loop Pipelining Unroll Loops Fuse Loops to Reduce Overhead and Improve Performance Optimize Loops With Loop Speculation Remove Loop Bottlenecks Shannonization to Improve FMAX/II Optimize Inner Loop Throughput Improve Loop Performance by Caching On-Chip Memory
Single-Cycle Floating-Point Accumulator for Single Work-Item Kernels x
Strategies for Inferring the Accumulator
Memory Accesses x
Load-Store Units Global Memory Accesses Optimization Perform Kernel Computations Using Local or Private Memory Local and Private Memory Accesses Optimization Annotating Unified Shared Memory Pointers Zero-Copy Memory Access Additional Recommendations
Load-Store Units x
Load-Store Unit Styles Load-Store Unit Modifiers Load-Store Unit Controls
Global Memory Accesses Optimization x
Global Memory Bandwidth Use Calculation Manual Partition of Global Memory Partitioning Buffers Across Different Memory Types (Heterogeneous Memory) Partitioning Buffers Across Memory Channels of the Same Memory Type Ignoring Dependencies Between Accessor Arguments Contiguous Memory Accesses Static Memory Coalescing
Pipes x
Host Pipes
Host Pipes x
Host Pipe Declaration Host Pipe API Host Pipes RTL Interfaces
Host x
Multi-Threaded Host Application Utilizing Hardware Kernel Invocation Queue Double Buffering Host Utilizing Kernel Invocation Queue N-Way Buffering to Overlap Kernel Execution Prepinning Memory Simple Host-Device Streaming Buffered Host-Device Streaming
Double Buffering Host Utilizing Kernel Invocation Queue x
Applying Double-Buffering Using the Intercept Layer for OpenCL* Applications
Resource Use x
Data Types and Operations Kernel Variable Accesses
Data Types and Operations x
Optimize Floating-point Operation Avoid Expensive Functions Variable-Precision Integer and Floating-Point Support
Variable-Precision Integer and Floating-Point Support x
Advantages and Limitations of Arbitrary Precision Data Types Declare and Use the AC Data Types
Declare and Use the AC Data Types x
Declare the ac_int Data Type Declare the ac_fixed Data Type Declare the ac_complex Data Type Declare the ap_float Data Type
Declare the ap_float Data Type x
Conversion Rules for ap_float Operations with Explicit Precision Controls Comparison Operators Additional ap_float Functions Additional Data Types Provided by the ap_float.hpp Header File Quality of Results and the ap_float Data Type
FPGA Optimization Flags, Attributes, Pragmas, and Extensions x
Optimization Flags Optimization Targets Kernel Variables Kernel Attributes Memory Attributes Loop Directives Floating-Point Pragmas Latency Controls (Beta) FPGA Extensions
Optimization Flags x
Specify Schedule FMAX Target for Kernels (-Xsclock=<clock target>) Create a 2xclock Interface (-Xsuse-2xclock) Disable Burst-Interleaving of Global Memory (-Xsno-interleaving=<global_memory_name>) Force Ring Interconnect for Global Memory (-Xsglobal-ring) Force a Single Store Ring to Reduce Area (-Xsforce-single-store-ring) Force Fewer Read Data Reorder Units to Reduce Area (-Xsnum-reorder) Disable Hardware Kernel Invocation Queue (-Xsno-hardware-kernel-invocation-queue) Modify the Handshaking Protocol Between Clusters (-Xshyper-optimized-handshaking) Disable Automatic Fusion of Loops (-Xsdisable-auto-loop-fusion) Fuse Adjacent Loops With Unequal Trip Counts (-Xsenable-unequal-tc-fusion) Pipeline Loops in Non-task Kernels (-Xsauto-pipeline) Control Semantics of Floating-Point Operations (-fp-model=<value>) Modify the Rounding Mode of Floating-point Operations (-Xsrounding=<rounding_type>) Global Control of Exit FIFO Latency of Stall-free Clusters (-Xssfc-exit-fifo-type=<value>) Enable the Read-Only Cache for Read-Only Accessors (-Xsread-only-cache-size=<N>) Control Hardware Implementation of the Supported Data Types and Math Operations (-Xsdsp-mode=<option>) Generate Register Map Wrapper (-Xsregister-map-wrapper-type)
Optimization Targets x
Minimum Latency Flow Maximum Throughput Without Area Optimization Heuristics Flow
Kernel Attributes x
Specify Schedule FMAX Target for Kernels Specify a Workgroup Size Specify Number of SIMD Work Items Omit Hardware that Generates and Dispatches Kernel IDs Omit Hardware to Support the no_global_work_offset Attribute in parallel_for Kernels Reduce Kernel Area and Latency
Loop Directives x
disable_loop_pipelining Attribute initiation_interval Attribute ivdep Attribute loop_coalesce Attribute max_concurrency Attribute max_interleaving Attribute speculated_iterations Attribute unroll Pragma Loop Fuse Functions and nofusion Attribute max_reinvocation_delay Attribute (Beta)
FPGA Extensions x
Pipes Extension Asynchronous Parallelism Within Kernels (task_sequence) device_global Extension (Beta)
Pipes Extension x
Key Properties of a Pipe Accessing Pipes The pipe Class and its Use I/O Pipes Characteristics of Pipes Restrictions of Pipes Guidelines for Designing Pipes Pipe and Atomic Fence
Asynchronous Parallelism Within Kernels (task_sequence) x
Task Functions task_sequence Use Cases
Quick Reference x
Algorithmic C Data Types Floating Point Pragmas FPGA Accessor Properties FPGA Extensions FPGA Kernel Attributes FPGA Local Memory Function Latency Control Properties (Beta) FPGA LSU Controls FPGA Loop Directives FPGA Memory Attributes FPGA Optimization Flags Pipe API
Document Revision History for the FPGA Optimization Guide for Intel® oneAPI Toolkits x
Notices and Disclaimers
FPGA Optimization Guide for Intel® oneAPI Toolkits
Introduction To FPGA Design Concepts
Analyze Your Design
Optimize Your Design
FPGA Optimization Flags, Attributes, Pragmas, and Extensions
Quick Reference
Additional Information
Document Revision History for the FPGA Optimization Guide for Intel® oneAPI Toolkits

Pipelining

Similar to implementing a CPU with multiple pipeline stages, the compiler generates a deeply pipelined hardware datapath. For more information, refer to Concepts of FPGA Hardware Design and How Source Code Becomes a Custom Hardware Datapath. Pipelining allows for many data items to be processed concurrently (in the same clock cycle) while efficiently using the hardware in the datapath by keeping it occupied.

Example of Vectorization of the Datapath vs. Pipelining the Datapath

Consider the following example of code mapping to hardware:

Example Code Mapping to Hardware

Multiple invocations of this code when running on a CPU would not be pipelined. The output of an invocation is completed before inputs are passed to the next invocation of the code. On an FPGA device, this kind of unpipelined invocation results in poor throughput and low occupancy of the datapath because many of the operations are sitting idle while other parts of the datapath are operating on the data.

The following figure shows what throughput and occupancy of invocations look like in this scenario:

Unpipelined Execution Resulting in Low Throughput and Low Occupancy

The Intel® oneAPI DPC++/C++ Compiler pipelines your design as much as possible. New inputs can be sent into the datapath each cycle, giving you a fully occupied datapath for higher throughput, as shown in the following figure:

Pipelining the Datapath Results in High Throughput and High Occupancy

You can gain even further throughput by vectorizing the pipelined hardware. Vectorizing the hardware improves throughput but requires more FPGA area for the additional copies of the pipelined hardware:

Vectorizing the Datapath Resulting in High Throughput and High Occupancy

Understanding where the data you need to pipeline is coming from is key to achieving high-performance designs on the FPGA. You can use the following sources of data to take advantage of pipelining:

  • Work items
  • Loop iterations

Pipelining Loops Within a Single Work Item

Within a single work item kernel, loops are the primary source of pipeline parallelism. When the Intel® oneAPI DPC++/C++ Compiler pipelines a loop, it attempts to schedule the loop’s execution such that the next iteration of the loop enters the pipeline before the previous iteration has completed. This pipelining of loop iterations can lead to higher performance.

The number of clock cycles between iterations of the loop is called the Initiation Interval (II). For the highest performance, a new iteration of the loop would start every clock cycle corresponding to an II of 1. Data dependencies that are carried from one iteration of the loop to another can affect the ability to achieve an II of 1. These dependencies are called loop carried dependencies. The II of the loop must be high enough to accommodate all loop carried dependencies.

NOTE:

The II required to satisfy this constraint is a function of the fMAX of the design. If the fMAX is lower, the II might also be lower. Conversely, if the fMAX is higher, a higher II might be required. The Intel® oneAPI DPC++/C++ Compiler automatically identifies these dependencies and builds hardware to resolve them while minimizing the II, subject to the target fMAX.

Naively generating hardware for the code in Figure 5 results in two loads: one from memory b and one from memory c. Because the compiler knows that the access to c[i-1] was written to in the previous iteration, the load from c[i-1] can be optimized away.

Pipelining a Datapath with Loop Iteration

NOTE:

The dependency on the value stored to c in the previous iteration is resolved in a single clock cycle, so an II of 1 is achieved for the loop even though the iterations are not independent.

In cases where the Intel® oneAPI DPC++/C++ Compiler cannot initially achieve II of 1, you have several optimization strategies to choose from:

  • Interleaving: When a loop nest with an inner loop II is greater than 1, the Intel® oneAPI DPC++/C++ Compiler can attempt to interleave iterations of the outer loop into iterations of the inner loop to utilize the hardware resources better and achieve higher throughput.
    Interleaving

    For additional information about controlling interleaving in your kernel, refer to max_interleaving Attribute.

  • Speculative Execution: When the critical path affecting II is the computation of the loop's exit condition and not a loop carried dependency, the Intel® oneAPI DPC++/C++ Compiler can attempt to relax this scheduling constraint by speculatively continuing to execute iterations of the loop while the exit condition is being computed. If it is determined that the exit condition is satisfied, the effects of these extra iterations are suppressed. This speculative iteration can achieve lower II and higher throughput, but it can incur additional overhead between the loop invocations (equivalent to the number of speculated iterations). A larger loop trip count helps to minimize this overhead.
    NOTE:

    A loop invocation is what starts a series of loop iterations. One loop iteration is one execution of the body of a loop.

    Loop Orchestration Without Speculative Execution

    Loop Orchestration With Speculative Execution

These optimizations are applied automatically by the Intel® oneAPI DPC++/C++ Compiler, and they can also be controlled through pragma statements and loop attributes in the design. For additional information, refer to speculated_iterations Attribute

Pipelining Across Multiple Work Items

A workgroup (a range of work items) represents a large set of independent data that can be processed in parallel. Since there are no implicit dependencies between work items, at every clock cycle, the next work item can always enter kernel’s datapath before previous work items have completed, unless there is a dynamic stall in the datapath. The following figure illustrates the pipeline in Figure 1 filled with work items:

NOTE:

Loops are not pipelined for kernels that use more than one work item in the current version of the compiler. This will be relaxed in a future release.

Pipelining a Datapath with SYCL* Work Items

Parent topic: Data Parallelism
Level Two Title