Cannot compile FPGA code for Intel FPGA using OpenCL SDK #1331
Comments
|
Hi @vselhakim1337, we test DaCe with the very same intel compiler (19.1) but with a different board/bsp (arria 10 or stratix 10). We don't have opencl hpp headers installed (but use the one included with Intel Quartus). Your sample works fine on my computer. Could you please check the following things:
Thank you! |
|
Okay @TizianoDeMatteis
Then I get the output: Now, after this, I've set the board to The board is obviously not installed there as claimed. Same goes for your other suggestions. What I have installed are the following boards: and sourcing the init script again, then running the Python example now gives:
gives exactly the same errors as encountered before. Not sure what the point of doing this was in the first place. Also as I've explained in my initial comment, I've tried as a test to set the includes in which gives me the errors at the bottom of the comment above. I'm really interested in what your setup is, so I can replicate it. As a side note: your documentation about configuring dace is extremely vague and minimal. I highly recommend that you take some time in improving it by including detailed explanations and steps on how to setup one's environment. It took me many days to even get to this point by digging into your source code, and consultations with colleagues that worked on the project. Thank you! |
|
@vselhakim1337 Regarding the issues that you have, in our testbeds (I actually tested this in 3 different setups), nothing specific has been required to run the FPGA samples (that does not mean that it is always the case). The problem that you are getting can be related to your configuration. So, I can detail my configuration and check with yours. SystemTested on Ubuntu 20.04 ( Intel CompilerWe are using the same version of Intel AOC (19.1). Note that which board you have available depends on how did you install it. We use Arria 10 (included in the default installation), but other applies as well. This is not relevant for your issue Note: from your output, it seems that in your configuration you are mixing Quartus 19.1 and 22.1. Also it seems your Quartus is setting the default board to a10_ref DaCeI cloned a fresh new version of DaCe repository, installed it with pip and executed with success the sample mentioned above Note: as indicated in the docs, dace confs can be also passed via env variables. In this case I used Testing hlslibThe problem you are getting originated from your configuration and hlslib not finding the right paths, you can also try to test hlslib directly as well, so we can better isolate the issue: |
|
Ok, I've uninstalled my Quartus 22.1 (apparently 19.1 does not work with a newer version of Quartus), and installed 19.1 that comes packaged with the SDK. I've also included Arria 10 devices in the installation from the setup. So,
I know that you can specify the options through env variables. I prefer a .conf file. Nevertheless, for the sake of consistency I will do as you did. In the same terminal session as before, cd-ing back to root dir of repo, removing the .conf file, and executing I have a very strong suspicion that the CMake file that dace uses defaults to a system-installed version of the OpenCL headers, and not the Intel SDK ones. I also have a suspicion that you have old versions of the headers installed on your system. Could you check that? |
|
Ok:
DaCe uses hlslib found paths, and hlslib should look at vendor specific installations. We don't have any other version of OpenCL header installed other than the ones provided by Intel Quartus and if I double check into the Note: Could you please indicate to me the steps to install your venv (or is that just a plain python3.8 venv?) and what other OpenCL libraries you have installed (if any -- I assume the OpenCL headers have not been re-installed). |
|
In dace repo dir I did: I have On your note: yields exactly the same results. Regarding the CMake cache: |
|
It seems that cmake is getting the right paths. I have the very same configuration (apart from the difference in the board and related paths). I can not reproduce even with a venv. I don't have access to a Majaro system (btw is Quartus supported there?) I'm running out of ideas here: are the include files really there? |
|
Installation of Quartus runs fine on Manjaro. I didn't run into any major issues, besides this. So it seems the I'm questioning how did the hlslib example compile then. By the way, thank you for taking your time into this. It's really frustrating when dealing with this stuff. |
|
I wonder why is creating another folder (
Regarding hlslib: the command that I sent you was just compiling the emulator bitstream, not the host program. And the opencl headers are needed for the host one (my fault). You can compile the host program with |
|
Okay, after renaming: then I ran the python example: Seems to work quite well. And, after doing the same steps as before, my original example also works, finally! :) Thanks for your patience. This is Intel FPGA SDK standard edition, downloaded from here. I'm not sure what is happening with my installation, but now that it is fixed, I will make sure to document these changes. |
|
How can I configure dace to use my custom board? Do I have to make a BSP/platform myself? CMake still gives me errors when I switch to the |
|
Hi @vselhakim1337, glad that this helped. To use another BSP, you should install it, make sure Quartus recognizes it and the use the corresponding DaCe flag to target the desired board (`DACE_compiler_fpga_intel_fpga_boards=<...>) Please, note that we tested DaCe with Quartus PRO edition, not the standard one. There are differences between Standard and Pro edition, in terms of supported hardware and libraries. Just to double-check: are you able to compile plain FPGA programs (not DaCe generated) targeting that board with the Standard edition? From the website you linked, it seems that the BSP is not supported by Quartus v19.1. |
|
@TizianoDeMatteis that's good to know, I was indeed using the standard edition. I unfortunately do not have a license for the pro edition. Nevertheless, I had the impression that this framework is supposed to be vendor tool agnostic. So far I can only see this line in the documentation about installing dace:
Nowhere in there is mentioned which versions to use, and how to set them up to work with DaCe, so I went with that I had installed. When you say "not supported", do you mean that the versions are different? I can try the same spiel with v18.1 and see what happens. |
Right, we can be more explicit on this, mentioning that has been tested only with Intel FPGA PRO.
Regarding the BSP, you should contact the FPGA vendor. From the website, I can only see that their BSP is supported in Quartus 18.1 ("BSP(Board Support Package) for Intel FPGA SDK OpenCL 18.1") |
|
Okay @TizianoDeMatteis, I've freshly installed the Intel FPGA SDK 18.1 standard edition. I had to do exactly the same steps as before to get the basic example to compile with DaCe. This installation comes with preinstalled boards, such as Here are my conclusions so far:
Mind you, I've faced similar issues with the Vivado/Vitis tooling, which prompted me to switch to Intel, but that's a different can of worms. It is unfortunate because these problems really prevent me from using your tool for my specific purpose. |
|
Hi @vselhakim1337, thanks for the in-depth analysis. Let me go over point by point:
hlslib relies on Intel tools to return the right include paths. As you discovered by yourself, Intel returns the wrong path. So this is not an hlslib/DaCe fault, but rather Intel's fault that we can not fix. We can anyway mention this in the documentation (in the troubleshooting), so people can fix Intel installations.
Yes, that is normal. They are two independent projects, each one with its building systems.
This needs more testing. So far we never had any issues, but thanks for the heads up
Yes, it could be the case. We never tested it, as we don't have access to such devices. Being a System on Chip, I can imagine this requires different code to be generate. We clearly also welcome Pull Requests from the community to add support for these kind of devices
Yes, this is worth mentioning that we tested with Quartus Pro, and that this may or may not work. As you noticed, this really depends on the targeted board (see previous point)
As already said, we are working in improving DaCe documentation and users inputs (like yours) are very valuable in this. |
|
I'd like to chime in on this discussion and say that DaCe does not rely on any Pro feature, just tested on it (due to the types of boards we have on our CI system). We obviously do not require users to pay for licenses. From a cursory view of your compile logs, you are facing CMake-related include discovery issues, which are not part of the core DaCe framework. This is good to hear and, if not part of our CMakeLists.txt, potentially something to escalate within the CMake modules of Intel FPGA.
We try to document as best as we can, but documentation is always evolving. There is some pretty extensive documentation on things like installation issues, visual depiction of the IR, optimization guidelines for FPGAs (which are currently being updated), and all the configuration entries available to use. What are you looking for in the documentation that you cannot find? We will be happy to add any information. |
|
Hi @tbennun, thank you for chiming into this. I really hope my experience here helps resolve these compilation issues in DaCe. Regarding the documentation, it would be very helpful if you can include a detailed guide that explains the basics of setting up and compiling a simple DaCe program for an FPGA board, and more specifically for a low-density FPGA like the Zynq 7000 or a Cyclone V SoC. That would greatly help with getting an FPGA engineer into the whole concept of DaCe, and getting a basic reference design going. |
|
@TizianoDeMatteis @tbennun Had a test with Xilinx, and same compilation error occurs. We figured out that it was related to CUDA OpenCL headers taking precedence over Intel and AMD/Xilinx headers. After reordering the |
Describe the bug
I'm trying to compile a simple SDFG for an Intel FPGA, however I'm getting the following errors:
To Reproduce
I have this minimal example to reproduce the issue:
and my
.dace.conffile isIn my virtual environment I've only
daceandnumpyinstalled.Environment
OS: Linux 5.15.120-1-MANJARO #1 SMP PREEMPT Wed Jul 5 21:45:37 UTC 2023 x86_64 GNU/Linux
Python version: 3.8
Dace: 0.14.4 (from main branch)
Intel FPGA OpenCL SDK: 19.1
OpenCL HPP headers: installed via my OS package manager via https://github.com/KhronosGroup/OpenCL-CLHPP
Additional context
I've tried to manually put absolute hardcoded paths to the CL headers included in the Intel FPGA OpenCL SDK, but then I get other deprecation errors like:
The text was updated successfully, but these errors were encountered: