Visible to Intel only — GUID: sbu1520273788966
Ixiasoft
Product Discontinuance Notification
1. Introduction to Intel® FPGA SDK for OpenCL™ Pro Edition Best Practices Guide
2. Reviewing Your Kernel's report.html File
3. OpenCL Kernel Design Concepts
4. OpenCL Kernel Design Best Practices
5. Profiling Your Kernel to Identify Performance Bottlenecks
6. Strategies for Improving Single Work-Item Kernel Performance
7. Strategies for Improving NDRange Kernel Data Processing Efficiency
8. Strategies for Improving Memory Access Efficiency
9. Strategies for Optimizing FPGA Area Usage
10. Strategies for Optimizing Intel® Stratix® 10 OpenCL Designs
11. Strategies for Improving Performance in Your Host Application
12. Intel® FPGA SDK for OpenCL™ Pro Edition Best Practices Guide Archives
A. Document Revision History for the Intel® FPGA SDK for OpenCL™ Pro Edition Best Practices Guide
2.1. High-Level Design Report Layout
2.2. Reviewing the Summary Report
2.3. Viewing Throughput Bottlenecks in the Design
2.4. Using Views
2.5. Analyzing Throughput
2.6. Reviewing Area Information
2.7. Optimizing an OpenCL Design Example Based on Information in the HTML Report
2.8. Accessing HLD FPGA Reports in JSON Format
4.1. Transferring Data Via Intel® FPGA SDK for OpenCL™ Channels or OpenCL Pipes
4.2. Unrolling Loops
4.3. Optimizing Floating-Point Operations
4.4. Allocating Aligned Memory
4.5. Aligning a Struct with or without Padding
4.6. Maintaining Similar Structures for Vector Type Elements
4.7. Avoiding Pointer Aliasing
4.8. Avoid Expensive Functions
4.9. Avoiding Work-Item ID-Dependent Backward Branching
5.1. Best Practices for Profiling Your Kernel
5.2. Instrumenting the Kernel Pipeline with Performance Counters (-profile)
5.3. Obtaining Profiling Data During Runtime
5.4. Reducing Area Resource Use While Profiling
5.5. Temporal Performance Collection
5.6. Performance Data Types
5.7. Interpreting the Profiling Information
5.8. Profiler Analyses of Example OpenCL Design Scenarios
5.9. Intel® FPGA Dynamic Profiler for OpenCL™ Limitations
8.1. General Guidelines on Optimizing Memory Accesses
8.2. Optimize Global Memory Accesses
8.3. Performing Kernel Computations Using Constant, Local or Private Memory
8.4. Improving Kernel Performance by Banking the Local Memory
8.5. Optimizing Accesses to Local Memory by Controlling the Memory Replication Factor
8.6. Minimizing the Memory Dependencies for Loop Pipelining
8.7. Static Memory Coalescing
Visible to Intel only — GUID: sbu1520273788966
Ixiasoft
10.6.1. Reset Recommendations
Intel® provides recommendations on how to handle resets in your Intel® Stratix® 10 OpenCL designs. The Intel® FPGA SDK for OpenCL™ Offline Compiler applies these recommendations automatically. If you are developing an RTL library, you should implement these guidelines for best performance.
In traditional FPGA RTL for non- Intel® Stratix® 10 devices, it is common practice to reset every register indiscriminately for easy implementation without negative effects on performance. However, to improve the performance of your Intel® Stratix® 10 design, you must minimize the number of resets.
Note: If a register is not reset, the reset fanout signal is reduced by one.
Avoid unnecessary resets in your Intel® Stratix® 10 design for the following reasons:
- The resulting high-fanout signal prevents the Intel® Quartus® Prime Pro Edition software's retimer to find a satisfactory solution.
For more in-depth explanation, refer to the Avoid Broadcast Signals section in the Intel® Stratix® 10 High-Performance Design Handbook. Note that the term "broadcast signals" refers to high-fanout signals.
- In some situations, simply having a reset on a register, regardless of whether it is a high-fanout reset signal, is enough to degrade the performance of your Intel® Stratix® 10 design.
For more in-depth explanation, refer to the Synchronous Resets and Limitations section in the Intel® Stratix® 10 High-Performance Design Handbook.
Intel® recommends the following design guidelines for resets:
- To improve Intel® Stratix® 10 design performance, do not reset registers that do not hold internal states to reduce reset fanout.
- The reset signal is guaranteed to remain asserted for at least 50 clock cycles. Use this guaranteed assertion by "flushing" chains of registers that have internal states, which further reduces the reset fanout.
- You have the option to pipeline the reset signal inside the RTL module for fanout management, to a depth of no more than 15 pipeline registers for stall-free RTL modules, or no more than 25 pipeline registers for stallable RTL modules. If the RTL module is sufficiently large, pipelining the reset signal might improve design performance.