A newer version of this document is available. Customers should click here to go to the newest version.
- 3.4. Listing the Intel® FPGA SDK for OpenCL™ Offline Compiler Command Options (no argument, -help, or -h)
- 7.5. Specifying the Name of an Intel® FPGA SDK for OpenCL™ Offline Compiler Output File (-o <filename>)
- 7.6. Compiling a Kernel for a Specific FPGA Board and Custom Platform (-board=<board_name>) and (-board-package=<board_package_path>)
- 7.13. Converting Warning Messages from the Intel® FPGA SDK for OpenCL™ Offline Compiler into Error Messages (-Werror)
- 7.17. Forcing a Single Store Ring to Reduce Area at the Expense of Write Throughput to Global Memory (-force-single-store-ring)
- 7.18. Forcing Fewer Read Data Reorder Units to Reduce Area at the Expense of Read Throughput to Global Memory (-num-reorder)
18.104.22.168. RTL Reset and Clock Signals
Because of the common clock and reset drivers, an RTL module runs in the same clock domain as the OpenCL kernel. The module is reset only when the OpenCL kernel is first loaded onto the FPGA, either via Intel® FPGA SDK for OpenCL™ program utility or the clCreateProgramwithBinary host function. In particular, if the host restarts a kernel via successive clEnqueueNDRangeKernel or clEnqueueTask invocations, the associated RTL modules does not reset in between these restarts.
The following steps outline the process of setting the kernel clock frequency:
- The Intel® Quartus® Prime software's Fitter applies an aggressive constraint on the kernel clock.
- The Intel® Quartus® Prime software's Timing Analyzer performs static timing analysis to determine the frequency that the Fitter actually achieves.
- The phase-locked loop (PLL) that drives the kernel clock sets the frequency determined in Step 2 to be the kernel clock frequency.
Optionally, an RTL module can access a system-wide clock that runs at twice the frequency of the OpenCL™ kernel clock. This system-wide clock can be connected to an input signal of the RTL module by including an AVALON element of type clock2x. The phase relationship between the clock and clock2x signals is such that the rising and falling edges of clock are coincident with rising edges of clock2x.
Timing failures may occur if one or more signals in your design are not able to satisfy all of the timing requirements of the device. All timing small timing failure can cause problems, so binaries that failed timing should not be used for development and production builds.
If your design failed timing, you have the following options:
- Timing failures can depend on how a design is placed on the FPGA, so running a sweep of different seeds (which results in different component placements) might lead to a passing binary.
- Decreasing the size of the design makes the component placement easier and timing failures less likely.
- Timing failures may be indicative of BSP problems, so if you are using a custom BSP, discuss with your BSP vendor. If you want to investigate it further, the Intel® Quartus® Prime Static Timing Analyzer outputs a *.sta.rpt file that contains more details about the timing analysis performed.
Did you find the information on this page useful?