Forum Discussion
Occasional ContributorThe weird aggressive aocl optimization "removing unnecessary storage to local memory"
With respect to functional verification, what I do is that I construct my host code in a way that both run-time and offline compilation are supported, the latter for FPGAs and the former for other devices, and I use AMD's OpenCL SDK for other devices. In this case, as long as the run-time OpenCL driver is installed, the same host code can then be used to execute the same kernel on any type of CPU, GPU or FPGA. You can take a look at the host code/makefiles of the optimized benchmarks in the following repository as example of achieving this:
https://github.com/fpga-opencl-benchmarks/rodinia_fpga
I emulated all of those kernels on CPUs/GPUs using the same host and kernel codes. What I would tell you is that if an NDRange kernel with sufficiently large local and global size performs correctly on a GPU, it should also perform correctly on an FPGA (unless there is a bug in the FPGA compiler). A CPU should also work fine even if the whole kernel runs on one core, since there will still be multiple threads (work-items) running on that core that could be issued out of order and this is usually enough to show concurrency issues but a GPU would likely be more trustworthy in this case.
With respect to, let's say HDL vs. OpenCL, many old-school HDL programmers tend to think that OpenCL or HLS tools in general are insufficient and it is possible to achieve better results using HDL. This is indeed true in some cases like latency-sensitive or low-power applications where clock-by-clock control over the code is required, or applications that are limited by logic resources, but I would not say this is the case for high-throughput applications where limitation is Memory/PCI-E bandwidth or DSP count since these limitations are independent of the programming language. With respect to the particular case of unpipelinable nested loops, HDL or OpenCL would not make a difference. If you have a regular outer loop with an irregular inner loop, the outer loop cannot be pipelined; it doesn't matter how you "describe" the code. There are two ways to approach such loops on FPGAs:
1- Use NDRange and let the run-time work-item scheduler do its best in maximizing pipeline efficiency and minimizing the average loop II.
2- Collapse the nested loop as long as it is not too irregular and get an II of one at the cost of a noticeable Fmax hit. Though by "collapse" I mean manual collapse and not the compiler's "coalesce" pragma. Take a look at Section 3.2.4.3 in this document:
https://arxiv.org/abs/1810.09773
Even though the provided example involves collapsing a regular nested loop, this optimization also sometimes applies to irregular nested loops. I such case, the condition inside the collapsed loop that is used to increment the variable of the original outer loop will have more than one statement (which complicates the critical path and reduces the Fmax). Indeed the possibility also exists to implement parts of your application in HDL and use it as an HDL library in an OpenCL kernel but you are going to run into complications if your HDL library does not have a fixed latency and I highly doubt you would be able to achieve much better results in the end.
Finally, with respect to NDRange vs. Single Work-item, I recommend reading Section 3.1 (and particularly 3.1.4) of the document I posted above.
Super Contributorthe message is actually in the decom.log files. I try it on Q17.1 and it shows that. But using Q19.1 this message no longer there. I will get back to you on this.
Occasional ContributorHi KTan9 @KennyT_Intel and HRZ @HRZ ,
I'm sorry I have to bother you again.
I installed Quartus 19.1 in my home directory successfully, but some bsp related errors happened (I will show them later)
According to this post ("Using A10 PAC BSP with OpenCL SDK 18.1", https://forums.intel.com/s/question/0D50P00004894Hn/using-a10-pac-bsp-with-opencl-sdk-181?language=en_US), one can compile OpenCL kernel using latest intel SDK with older BSP version. Though @FJumaah shows a detailed configuration procedure, I cannot make it by directly using it (at least at Intel vLab's pac_a10, no a generic Arria 10).
And then, I tried the second configuration method:
I copied the configuration directory "/export/fpga/bin" to my home "/fpga/bin" and did the following changes:
1) In ./fpga/bin/sh/fpga_classes, change "fpga_quartus_version[fpga-pac-a10]="17.1.1" to "19.1" (or "18.1", etc.)
2) In all set-*-env files in ./fpga/bin, change "SCRIPT_DIR="/export/fpga/bin" to "$HOME/fpga/bin"
3) In setup-synth-env, for line 52 - line 57, change "/export/fpga/tools/quartus_pro" to "$HOME/intelFPGA_pro"
((For 18.1 and 17.1.1, the 3) are not applied because they are in /export/fpga/tools/quartus_pro)
Then I run "source $HOME/fpga/bin/setup-fpga-env fpga-pac-a10
qsub-fpga"
as before.
I tested the above modified script with 17.1.1, 18.1 and 19.1. Only 17.1.1 can work well. Both 18.1 and 19.1 show bsp related errors. The configured environmental variables and partial errors are shown here respectively (I will attache the file "quartus_sh_compile.log" as well)
INTELFPGAOCLSDKROOT is set to /homes/hiratz/intelFPGA_pro/19.1/hld. Using that.
Will use $QUARTUS_ROOTDIR_OVERRIDE= /homes/hiratz/intelFPGA_pro/19.1/quartus to find Quartus
AOCL_BOARD_PACKAGE_ROOT is set to /export/fpga/release/a10_gx_pac_ias_1_1_pv/opencl/opencl_bsp. Using that.
Adding /homes/hiratz/intelFPGA_pro/19.1/hld/bin to PATH
Adding /homes/hiratz/intelFPGA_pro/19.1/hld/host/linux64/lib to LD_LIBRARY_PATH
Adding /export/fpga/release/a10_gx_pac_ias_1_1_pv/opencl/opencl_bsp/linux64/lib to LD_LIBRARY_PATH
Configured FPGA environment for fpga-pac-a10:
Quartus: /homes/hiratz/intelFPGA_pro/19.1/quartus
Platform: /export/fpga/release/a10_gx_pac_ias_1_1_pv
OPAE: /export/fpga/opae/install/opae-install-20190112
Starting interactive job on queue fpga-pac-a10
qsub: waiting for job 132804.iam-pbs to start
qsub: job 132804.iam-pbs readyYou can see the bsp I'm using is /export/fpga/release/a10_gx_pac_ias_1_1_pv which is the default bsp specifically for pac_a10. (Note that the generic a10 bsp is in /homes/hiratz/intelFPGA_pro/19.1/hld/board/a10_ref/). The SDK I'm using is /homes/hiratz/intelFPGA_pro/19.1/quartus. Both "ALTERAOCLSDKROOT" and "INTELFPGAOCLSDKROOT" are set to "/homes/hiratz/intelFPGA_pro/19.1/hld"
The bsp errors are as follows:
aoc: Linking with IP library ...
aoc: Checking if memory usage is larger than 100%...
aoc: Memory usage is not above 100.
Compiler Warning: addpipe in board_spec.xml is set to 1 which is no longer supported
Compiler Warning: global memory pipeline stage is now implemented in BSP instead
aoc: First stage compilation completed successfully.
Compiling for FPGA. This process may take a long time, please be patient.
Error (16045): Instance "ccip_std_afu|bsp_logic_inst|board_inst" instantiates undefined entity "board" File: /homes/hiratz/ndr-test/decom_co
mp/build/bsp_logic.sv Line: 133
Error (16185): Can't elaborate user hierarchy "ccip_std_afu|bsp_logic_inst|board_inst" File: /homes/hiratz/ndr-test/decom_comp/build/bsp_log
ic.sv Line: 133
Error (16185): Can't elaborate user hierarchy "ccip_std_afu|bsp_logic_inst" File: /homes/hiratz/ndr-test/decom_comp/build/BBB_cci_mpf/hw/rtl
/cci-mpf-if/cci_mpf_if.vh Line: 38
Error (16185): Can't elaborate user hierarchy "ccip_std_afu" File: /homes/hiratz/ndr-test/decom_comp/build/platform/green_bs.sv Line: 183
Error (16186): Can't elaborate top-level user hierarchy
Error: Flow failed:
Error: Quartus Prime Synthesis was unsuccessful. 6 errors, 413 warnings
Error (23035): Tcl error: ERROR: Error(s) found while running an executable. See report file(s) for error message(s). Message log indicates
which executable was run last.
Error (23031): Evaluation of Tcl script a10_partial_reconfig/flow.tcl unsuccessful
Error: Quartus Prime Shell was unsuccessful. 12 errors, 413 warnings
Error: Compiler Error, not able to generate hardwareFor 18.1, it caused similar bsp errors to the above.
Note: The above bsp errors only happened for complete compilation to the hardware. The quick initial compilation for a report (aoc -report -v -rtl -I./device device/decom_comp.cl -board=pac_a10) works well.
kTan9 @KennyT_Intel : My 19.1 compilation showed neither "Aggressive compiler optimization: removing unnecessary storage to local memory" nor "Aggressive compiler optimization: pushing out local memory contents".
So I guess there must be something wrong with my configurations but I just cannot figure it out after I tried it again and again.
Would you please show me a correct configuration procedure you used for pac_a10 with Quartus 19.1 or 18.1? If you need more information, please let me know.
I really appreciate your help!
