Cannot compile FPGA code for Intel FPGA using OpenCL SDK

[vselhakim1337]

Describe the bug I'm trying to compile a simple SDFG for an Intel FPGA, however I'm getting the following errors:

/usr/include/CL/opencl.hpp: At global scope:
/usr/include/CL/opencl.hpp:1573:1: error: ‘CL_KERNEL_ATTRIBUTES’ was not declared in this scope
 1573 | CL_HPP_PARAM_NAME_INFO_1_2_(CL_HPP_DECLARE_PARAM_TRAITS_)
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/CL/opencl.hpp:1573:1: error: template argument 2 is invalid
 1573 | CL_HPP_PARAM_NAME_INFO_1_2_(CL_HPP_DECLARE_PARAM_TRAITS_)
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/CL/opencl.hpp:1573:1: error: ‘cl_device_partition_property’ was not declared in this scope; did you mean ‘cl_device_partition_property_ext’?
 1573 | CL_HPP_PARAM_NAME_INFO_1_2_(CL_HPP_DECLARE_PARAM_TRAITS_)
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/CL/opencl.hpp:1573:1: error: template argument 1 is invalid
 1573 | CL_HPP_PARAM_NAME_INFO_1_2_(CL_HPP_DECLARE_PARAM_TRAITS_)
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/CL/opencl.hpp:1573:1: error: template argument 2 is invalid
/usr/include/CL/opencl.hpp:1573:1: error: ‘cl_device_partition_property’ was not declared in this scope; did you mean ‘cl_device_partition_property_ext’?
 1573 | CL_HPP_PARAM_NAME_INFO_1_2_(CL_HPP_DECLARE_PARAM_TRAITS_)
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/CL/opencl.hpp:1573:1: error: template argument 1 is invalid
 1573 | CL_HPP_PARAM_NAME_INFO_1_2_(CL_HPP_DECLARE_PARAM_TRAITS_)
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/CL/opencl.hpp:1573:1: error: template argument 2 is invalid
/usr/include/CL/opencl.hpp:1573:1: error: ‘cl_device_affinity_domain’ does not name a type
 1573 | CL_HPP_PARAM_NAME_INFO_1_2_(CL_HPP_DECLARE_PARAM_TRAITS_)
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/CL/opencl.hpp:1573:1: error: ‘CL_IMAGE_ARRAY_SIZE’ was not declared in this scope; did you mean ‘CL_IMAGE_ELEMENT_SIZE’?
 1573 | CL_HPP_PARAM_NAME_INFO_1_2_(CL_HPP_DECLARE_PARAM_TRAITS_)
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/CL/opencl.hpp:1573:1: error: template argument 2 is invalid
 1573 | CL_HPP_PARAM_NAME_INFO_1_2_(CL_HPP_DECLARE_PARAM_TRAITS_)
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/CL/opencl.hpp:1573:1: error: ‘CL_IMAGE_NUM_MIP_LEVELS’ was not declared in this scope
 1573 | CL_HPP_PARAM_NAME_INFO_1_2_(CL_HPP_DECLARE_PARAM_TRAITS_)
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/CL/opencl.hpp:1573:1: error: template argument 2 is invalid
 1573 | CL_HPP_PARAM_NAME_INFO_1_2_(CL_HPP_DECLARE_PARAM_TRAITS_)
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/CL/opencl.hpp:1573:1: error: ‘CL_IMAGE_NUM_SAMPLES’ was not declared in this scope
 1573 | CL_HPP_PARAM_NAME_INFO_1_2_(CL_HPP_DECLARE_PARAM_TRAITS_)
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/CL/opencl.hpp:1573:1: error: template argument 2 is invalid
 1573 | CL_HPP_PARAM_NAME_INFO_1_2_(CL_HPP_DECLARE_PARAM_TRAITS_)
      | ^~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/CL/opencl.hpp: In static member function ‘static cl_int cl::detail::ReferenceHandler<_cl_device_id*>::retain(cl_device_id)’:
/usr/include/CL/opencl.hpp:1851:16: error: ‘::clRetainDevice’ has not been declared; did you mean ‘clRetainDeviceEXT’?
 1851 |     { return ::clRetainDevice(device); }
      |                ^~~~~~~~~~~~~~
      |                clRetainDeviceEXT
/usr/include/CL/opencl.hpp: In static member function ‘static cl_int cl::detail::ReferenceHandler<_cl_device_id*>::release(cl_device_id)’:
/usr/include/CL/opencl.hpp:1862:16: error: ‘::clReleaseDevice’ has not been declared; did you mean ‘clReleaseDeviceEXT’?
 1862 |     { return ::clReleaseDevice(device); }
      |                ^~~~~~~~~~~~~~~
      |                clReleaseDeviceEXT
/usr/include/CL/opencl.hpp: At global scope:
/usr/include/CL/opencl.hpp:2502:15: error: ‘cl_device_partition_property’ does not name a type; did you mean ‘cl_device_partition_property_ext’?
 2502 |         const cl_device_partition_property * properties,
      |               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |               cl_device_partition_property_ext
/usr/include/CL/opencl.hpp: In member function ‘cl_int cl::Device::createSubDevices(const int*, cl::vector<cl::Device>*)’:
/usr/include/CL/opencl.hpp:2506:22: error: ‘clCreateSubDevices’ was not declared in this scope; did you mean ‘createSubDevices’?
 2506 |         cl_int err = clCreateSubDevices(object_, properties, 0, nullptr, &n);
      |                      ^~~~~~~~~~~~~~~~~~
      |                      createSubDevices
/usr/include/CL/opencl.hpp: In member function ‘cl_int cl::Device::createSubDevices(const cl_device_partition_property_ext*, cl::vector<cl::Device>*)’:
/usr/include/CL/opencl.hpp:2553:9: error: ‘clGetExtensionFunctionAddressForPlatform’ was not declared in this scope; did you mean ‘clGetExtensionFunctionAddress’?
 2553 |         CL_HPP_INIT_CL_EXT_FCN_PTR_PLATFORM_(platform, clCreateSubDevicesEXT);
      |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/CL/opencl.hpp: In member function ‘cl_int cl::Platform::unloadCompiler()’:
/usr/include/CL/opencl.hpp:2998:18: error: ‘::clUnloadPlatformCompiler’ has not been declared; did you mean ‘clUnloadCompiler’?
 2998 |         return ::clUnloadPlatformCompiler(object_);
      |                  ^~~~~~~~~~~~~~~~~~~~~~~~
      |                  clUnloadCompiler
/usr/include/CL/opencl.hpp: In constructor ‘cl::ImageGL::ImageGL(const cl::Context&, cl_mem_flags, cl_GLenum, cl_GLint, cl_GLuint, cl_int*)’:
/usr/include/CL/opencl.hpp:5310:21: error: ‘::clCreateFromGLTexture’ has not been declared; did you mean ‘clCreateFromGLTexture3D’?
 5310 |         object_ = ::clCreateFromGLTexture(
      |                     ^~~~~~~~~~~~~~~~~~~~~
      |                     clCreateFromGLTexture3D
/usr/include/CL/opencl.hpp: In constructor ‘cl::Program::Program(const cl::Context&, cl::vector<cl::Device>&, const cl::string&, cl_int*)’:
/usr/include/CL/opencl.hpp:6407:21: error: ‘::clCreateProgramWithBuiltInKernels’ has not been declared; did you mean ‘clCreateProgramWithBinary’?
 6407 |         object_ = ::clCreateProgramWithBuiltInKernels(
      |                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                     clCreateProgramWithBinary
/usr/include/CL/opencl.hpp: In member function ‘cl_int cl::Program::compile(const char*, void (*)(cl_program, void*), void*) const’:
/usr/include/CL/opencl.hpp:6508:26: error: ‘::clCompileProgram’ has not been declared; did you mean ‘clBuildProgram’?
 6508 |         cl_int error = ::clCompileProgram(
      |                          ^~~~~~~~~~~~~~~~
      |                          clBuildProgram
/usr/include/CL/opencl.hpp: In function ‘cl::Program cl::linkProgram(const Program&, const Program&, const char*, void (*)(cl_program, void*), void*, cl_int*)’:
/usr/include/CL/opencl.hpp:6716:25: error: ‘::clLinkProgram’ has not been declared; did you mean ‘linkProgram’?
 6716 |     cl_program prog = ::clLinkProgram(
      |                         ^~~~~~~~~~~~~
      |                         linkProgram
/usr/include/CL/opencl.hpp: In function ‘cl::Program cl::linkProgram(vector<Program>&, const char*, void (*)(cl_program, void*), void*, cl_int*)’:
/usr/include/CL/opencl.hpp:6755:25: error: ‘::clLinkProgram’ has not been declared; did you mean ‘linkProgram’?
 6755 |     cl_program prog = ::clLinkProgram(
      |                         ^~~~~~~~~~~~~
      |                         linkProgram
/usr/include/CL/opencl.hpp: In member function ‘cl_int cl::CommandQueue::enqueueMarkerWithWaitList(cl::vector<cl::Event>*, cl::Event*) const’:
/usr/include/CL/opencl.hpp:8313:15: error: ‘::clEnqueueMarkerWithWaitList’ has not been declared; did you mean ‘enqueueMarkerWithWaitList’?
 8313 |             ::clEnqueueMarkerWithWaitList(
      |               ^~~~~~~~~~~~~~~~~~~~~~~~~~~
      |               enqueueMarkerWithWaitList
/usr/include/CL/opencl.hpp: In member function ‘cl_int cl::CommandQueue::enqueueBarrierWithWaitList(cl::vector<cl::Event>*, cl::Event*) const’:
/usr/include/CL/opencl.hpp:8343:15: error: ‘::clEnqueueBarrierWithWaitList’ has not been declared; did you mean ‘enqueueBarrierWithWaitList’?
 8343 |             ::clEnqueueBarrierWithWaitList(
      |               ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |               enqueueBarrierWithWaitList

To Reproduce I have this minimal example to reproduce the issue:

import dace
import numpy as np

sdfg = dace.SDFG("sdfg")

M, N = 10, 10

sdfg.add_array("X", shape=(M, N), dtype=dace.float32)
sdfg.add_array("Y", shape=(M, N), dtype=dace.float32)
sdfg.add_array("Z", shape=(M, N), dtype=dace.float32)

state = sdfg.add_state("a_state")

Xin = state.add_read("X")
Yin = state.add_read("Y")
Zout = state.add_write("Z")

tasklet = state.add_tasklet("tasklet", {"x": dace.float32, "y": dace.float32}, {"z": dace.float32}, "z = x + y")
mape, mapx = state.add_map("map", {"i": f"0:{M}", "j": f"0:{N}"})

state.add_memlet_path(Xin, mape, tasklet, dst_conn="x", memlet=dace.Memlet("X[i,j]"))
state.add_memlet_path(Yin, mape, tasklet, dst_conn="y", memlet=dace.Memlet("Y[i,j]"))
state.add_memlet_path(tasklet, mapx, Zout, src_conn="z", memlet=dace.Memlet("Z[i,j]"))

sdfg.fill_scope_connectors()
sdfg.validate()

from dace.transformation.interstate import FPGATransformSDFG

sdfg.apply_transformations([FPGATransformSDFG])

X = np.ones((M, N)).astype(np.float32)
Y = np.ones((M, N)).astype(np.float32)
Z = np.empty((M, N)).astype(np.float32)

sdfg(X=X, Y=Y, Z=Z)

np.testing.assert_allclose(Z, 2.0*np.ones((M, N)).astype(np.float32))

and my .dace.conf file is

compiler:
  cuda:
    backend: cuda
    cuda_arch: '35'
    hip_arch: '906'
  fpga:
    vendor: intel_fpga
  intel_fpga:
    board: de10_nano
    enable_debugging: false
    host_flags: -Wno-unknown-pragmas
    kernel_flags: -fp-relaxed -cl-no-signed-zeros -cl-fast-relaxed-math -cl-single-precision-constant
      -no-interleaving=default
    mode: emulator
    path: ''"

In my virtual environment I've only dace and numpy installed. 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:

dace/external/hlslib/include/hlslib/common/OpenCL.h:658:36: error: ‘class cl::CommandQueue’ has no member named ‘get’
  658 |           context_->commandQueue().get(), devicePtr_.get(), CL_TRUE,

[TizianoDeMatteis]

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:

• (if possible) remove the opencl headers, and re-run your DaCe sample (first be sure to remove the cache, usually located under .dacecache/)
• if the above does not work, check with one of those boards (arria10 or stratix10) if you have access to those BSPs (usually arria 10 is included with Quartus)
• if the above do not work, check with another test already included in dace (e.g., python <dace_folder>/samples/fpga/axpy_transformed.py, or other tests under the tests/ folder)

Thank you!

[vselhakim1337]

Okay @TizianoDeMatteis

1. I've uninstalled the package for the headers via my OS' package manager, I've removed the cache folder, and I've run the same Python script. Now dace cannot find the headers:

   hlslib/intel/OpenCL.h:11:10: fatal error: CL/cl2.hpp: No such file or directory

2. Note that I have my 19.1 installation is in my home directory. Note also that I have a separate Quartus Lite 22.1 installation, and that the SDK is standalone installed. There I've sourced the following script in my venv:

   source ~/intelFPGA/19.1/hld/init_opencl.sh

   Then I get the output:

   
   INTELFPGAOCLSDKROOT is set to /home/<user>/intelFPGA/19.1/hld. Using that.

Will use $QUARTUS_ROOTDIR_OVERRIDE= /home//intelFPGA_lite/22.1std/quartus to find Quartus

AOCL_BOARD_PACKAGE_ROOT path is not set in environment. Setting to default a10_ref board. If you want to target another board, do export AOCL_BOARD_PACKAGE_ROOT= and re-run this script Adding /home//intelFPGA/19.1/hld/bin to PATH Adding /home//intelFPGA/19.1/hld/host/linux64/lib to LD_LIBRARY_PATH Adding /home//intelFPGA/19.1/hld/board/a10_ref/linux64/lib to LD_LIBRARY_PATH

Now, after this, I've set the board to `a10_ref` board in my dace conf file, wiped the cache, and run the example again, to get the following error:

Cannot find board_env.xml in /home/deadbeef/intelFPGA/19.1/hld/board/a10_ref Cannot find board_env.xml in /home/deadbeef/intelFPGA/19.1/hld/board/a10_ref CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message): Could NOT find IntelFPGAOpenCL (missing: IntelFPGAOpenCL_INCLUDE_DIRS IntelFPGAOpenCL_LIBRARIES IntelFPGAOpenCL_RPATH) Call Stack (most recent call first): /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:600 (_FPHSA_FAILURE_MESSAGE) /home/deadbeef/Projects/cheetahai/dace/dace/external/hlslib/cmake/FindIntelFPGAOpenCL.cmake:103 (find_package_handle_standard_args) CMakeLists.txt:235 (find_package)

-- Configuring incomplete, errors occurred!

The board is obviously not installed there as claimed. Same goes for your other suggestions. What I have installed are the following boards: `c5soc`, `s5_ref` and the one I've installed myself: `de10_nano`. 
Setting 

export AOCL_BOARD_PACKAGE_ROOT=/home/deadbeef/intelFPGA/19.1/hld/board/c5soc

and sourcing the init script again, then running the Python example now gives:

CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: stdc++_PATH (ADVANCED) linked by target "sdfg" in directory /home/deadbeef/Projects/cheetahai/dace/dace/codegen -- Generating done (0.0s) CMake Generate step failed. Build files cannot be regenerated correctly.

3. Starting in a fresh Python 3.8 environment, installing dace via `pip install -e .` in the repo directory, copying the `.dace.conf` file I used in my example, and then running

python samples/fpga/axpy_transformed.py

gives **exactly** the same errors as encountered before. Not sure what the point of doing this was in the first place.
It is obvious by now that the include paths are not set correctly in the CMake configuration, so there is no point in running the tests. 

**Also** as I've explained in my initial comment, I've tried as a test to set the includes in `hlslib/intel/OpenCL.h` to point to absolute paths, i.e. to

include "/home//intelFPGA/19.1/hld/host/include/CL/cl.hpp"

if !defined(CL_CHANNEL_1_INTELFPGA)

// include this header if channel macros are not defined in cl.hpp (versions >=19.0)

include "/home//intelFPGA/19.1/hld/host/include/CL/cl_ext_intelfpga.h"

endif

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!

[TizianoDeMatteis]

@vselhakim1337 let me start by noting that we are always keen to improve documentation. That's why we always welcome users' inputs (as yours).

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). So I can not really replicate your current issue.

The problem that you are getting can be related to your configuration. So, I can detail my configuration and check with yours.

System

Tested on Ubuntu 20.04 (*), Fedora 37, Centos 8, with Python 3.8 (*), 3.11 and 3.9. The following will refer to the configuration marked with the asterisk(*)

Intel Compiler

We 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

tdematt@fpga0:~$ source /opt/intelFPGA_pro/19.1/hld/init_opencl.sh 
INTELFPGAOCLSDKROOT is not set                                                                                                                                                                                                                
Using script's current directory (/opt/intelFPGA_pro/19.1/hld)                                                                                                                                                                                

Found a Quartus directory at /opt/intelFPGA_pro/19.1/quartus. Using that.                                                                                                                                                                     

AOCL_BOARD_PACKAGE_ROOT path is not set in environment.                                                                                                                                                                                       
Setting to default a10_ref board.                                                                                                                                                                                                             
If you want to target another board, do                                                                                                                                                                                                       
   export AOCL_BOARD_PACKAGE_ROOT=<board_pkg_dir>                                                                                                                                                                                             
and re-run this script                                                                                                                                                                                                                        
Adding /opt/intelFPGA_pro/19.1/hld/bin to PATH                                                                                                                                                                                                
Adding /opt/intelFPGA_pro/19.1/hld/host/linux64/lib to LD_LIBRARY_PATH                                                                                                                                                                        
Adding /opt/intelFPGA_pro/19.1/hld/board/a10_ref/linux64/lib to LD_LIBRARY_PATH

tdematt@fpga0:~$ aoc -list-boards
Board list:
  a10gx
     Board Package: /opt/intelFPGA_pro/19.1/hld/board/a10_ref

  a10gx_hostpipe
     Board Package: /opt/intelFPGA_pro/19.1/hld/board/a10_ref
     Channels:      host_to_dev, dev_to_host

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

DaCe

I cloned a fresh new version of DaCe repository, installed it with pip and executed with success the sample mentioned above

tdematt@fpga0:/tmp$ git clone --recursive https://github.com/spcl/dace.git  
<...>
tdematt@fpga0:/tmp$ cd dace/                                                                                                                                                                                                                  
tdematt@fpga0:/tmp/dace$ pip install --editable . 
<...>
tdematt@fpga0:/tmp/dace$ DACE_compiler_fpga_vendor=intel_fpga DACE_compiler_intel_fpga_board=a10gx python3 samples/fpga/axpy_transformed.py 
Scalar-vector multiplication 24
Applied 1 FPGATransformSDFG.
-- Configuring done
-- Generating done
-- Build files have been written to: /tmp/dace/.dacecache/axpy_fpga_24/build

[ 33%] Built target dacestub_axpy_fpga_24
[ 50%] Generating axpy_fpga_24_emulator.aocx
aoc: Running OpenCL parser....
aoc: OpenCL parser completed successfully.
aoc: Linking Object files....
aoc: Compiling for Emulation ....
[ 50%] Built target intelfpga_compile_axpy_fpga_24_emulator
Scanning dependencies of target axpy_fpga_24
[ 66%] Building CXX object CMakeFiles/axpy_fpga_24.dir/tmp/dace/.dacecache/axpy_fpga_24/src/cpu/axpy_fpga_24.cpp.o
In file included from /home/tdematt/dace/dace/codegen/../runtime/include/dace/dace.h:14,
                 from /tmp/dace/.dacecache/axpy_fpga_24/src/cpu/axpy_fpga_24.cpp:2:
/home/tdematt/dace/dace/codegen/../runtime/include/dace/types.h: In constructor ‘dace::half::half(float)’:
/home/tdematt/dace/dace/codegen/../runtime/include/dace/types.h:92:28: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
   92 |             uint32_t x = *((uint32_t*)&f);
      |                           ~^~~~~~~~~~~~~~
[ 83%] Building CXX object CMakeFiles/axpy_fpga_24.dir/tmp/dace/.dacecache/axpy_fpga_24/src/intel_fpga/host/axpy_fpga_24.cpp.o
In file included from /home/tdematt/dace/dace/codegen/../runtime/include/dace/intel_fpga/host.h:10,
                 from /tmp/dace/.dacecache/axpy_fpga_24/src/intel_fpga/host/axpy_fpga_24.cpp:1:
/home/tdematt/dace/dace/codegen/../runtime/include/dace/types.h: In constructor ‘dace::half::half(float)’:
/home/tdematt/dace/dace/codegen/../runtime/include/dace/types.h:92:28: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
   92 |             uint32_t x = *((uint32_t*)&f);
      |                           ~^~~~~~~~~~~~~~
[100%] Linking CXX shared library libaxpy_fpga_24.so
[100%] Built target axpy_fpga_24

Difference: 0.0

Note: as indicated in the docs, dace confs can be also passed via env variables. In this case I used DACE_compiler_fpga_vendor=intel_fpga DACE_compiler_intel_fpga_board=a10gx. Replace in the latter the board that you used

Testing hlslib

The 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:

tdematt@fpga0:/tmp/dace$ cd dace/external/hlslib/
tdematt@fpga0:/tmp/dace/dace/external/hlslib$ ls
tdematt@fpga0:/tmp/dace/dace/external/hlslib$ mkdir test_intel
tdematt@fpga0:/tmp/dace/dace/external/hlslib$ cd test_intel/
tdematt@fpga0:/tmp/dace/dace/external/hlslib/test_intel$ cmake ..
<...>
tdematt@fpga0:/tmp/dace/dace/external/hlslib/test_intel$ cd intel_test
tdematt@fpga0:/tmp/dace/dace/external/hlslib/test_intel/intel_test$ make build_Jacobi2D_emulator
Generating Jacobi2D_emulator.aocx
aoc: Running OpenCL parser....
aoc: OpenCL parser completed successfully.
aoc: Linking Object files....
aoc: Compiling for Emulation ....
Compiler Warning: 
Compiler Warning: The default channel depths in the emulation flow will be different from the hardware flow depths (0) to speed up emulation; To match the "__attribute__((depth(<depth>)))".
Compiler Warning: or
Compiler Warning: * Use compiler option: "-emulator-channel-depth-model=<model>".
Compiler Warning: For more details run aoc -help.
Built target build_Jacobi2D_emulator

[vselhakim1337]

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. Fresh terminal session in venv:

[user@pc dace]$ source /home/<user>/Projects/fpga_dev/dace/venv/bin/activate
(venv) [user@pc dace]$ source ~/intelFPGA/19.1/hld/init_opencl.sh 
INTELFPGAOCLSDKROOT is set to /home/<user>/intelFPGA/19.1/hld. Using that.

Will use $QUARTUS_ROOTDIR_OVERRIDE= /home/<user>/intelFPGA/19.1/quartus  to find Quartus

AOCL_BOARD_PACKAGE_ROOT path is not set in environment.
Setting to default a10_ref board.
If you want to target another board, do 
   export AOCL_BOARD_PACKAGE_ROOT=<board_pkg_dir>
and re-run this script
Adding /home/<user>/intelFPGA/19.1/hld/bin to PATH
Adding /home/<user>/intelFPGA/19.1/hld/host/linux64/lib to LD_LIBRARY_PATH
Adding /home/<user>/intelFPGA/19.1/hld/board/a10_ref/linux64/lib to LD_LIBRARY_PATH
(venv) [user@pc dace]$ aoc -list-boards
Cannot find board_env.xml in /home/<user>/intelFPGA/19.1/hld/board/a10_ref              
(venv) [user@pc dace]$ export AOCL_BOARD_PACKAGE_ROOT=/home/<user>/intelFPGA/19.1/hld/board/s5_ref/
(venv) [user@pc dace]$ source ~/intelFPGA/19.1/hld/init_opencl.sh 
INTELFPGAOCLSDKROOT is set to /home/<user>/intelFPGA/19.1/hld. Using that.

Will use $QUARTUS_ROOTDIR_OVERRIDE= /home/<user>/intelFPGA/19.1/quartus  to find Quartus

AOCL_BOARD_PACKAGE_ROOT is set to /home/<user>/intelFPGA/19.1/hld/board/s5_ref/. Using that.
Adding /home/<user>/intelFPGA/19.1/hld/bin to PATH
Adding /home/<user>/intelFPGA/19.1/hld/host/linux64/lib to LD_LIBRARY_PATH
Adding /home/<user>/intelFPGA/19.1/hld/board/s5_ref//linux64/lib to LD_LIBRARY_PATH
(venv) [user@pc dace]$ aoc -list-boards
Board list:
  s5_ref
     Board Package: /home/<user>/intelFPGA/19.1/hld/board/s5_ref/

(venv) [user@pc dace]$ cd dace/external/hlslib/
(venv) [user@pc hlslib]$ cd test_intel/
(venv) [user@pc test_intel]$ rm -rf *
(venv) [user@pc test_intel]$ cmake -DHLSLIB_BOARD_NAME=s5_ref ..
-- The C compiler identification is GNU 13.1.1
-- The CXX compiler identification is GNU 13.1.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE  
CMake Warning at cmake/FindVitis.cmake:104 (message):
  vitis_hls used from Vitis 2020.1 and onwards introduces breaking changes to
  hls::stream.  Please pass -D__VITIS_HLS__ or -D__VIVADO_HLS__ in your
  synthesis script depending on which tool you are using to always use a
  working version.
Call Stack (most recent call first):
  CMakeLists.txt:17 (find_package)

-- Could NOT find Vitis (missing: Vitis_COMPILER Vitis_HLS Vitis_INCLUDE_DIRS Vitis_LIBRARIES Vitis_FLOATING_POINT_LIBRARY Vitis_VERSION Vitis_MAJOR_VERSION Vitis_MINOR_VERSION Vitis_PLATFORMINFO) 
-- Found IntelFPGAOpenCL: /home/<user>/intelFPGA/19.1/hld/bin/aocl  
-- Configuring done (0.8s)
-- Generating done (0.0s)
-- Build files have been written to: /home/<user>/Projects/fpga_dev/dace/dace/external/hlslib/test_intel
(venv) [user@pc test_intel]$ cd intel_test
(venv) [user@pc intel_test]$ make build_Jacobi2D_emulator
[100%] Generating Jacobi2D_emulator.aocx
aoc: Running OpenCL parser....
aoc: Compiling for Emulation ....
[100%] Built target build_Jacobi2D_emulator

So, hlslib does not seem to be the problem.

Note: as indicated in the docs, dace confs can be also passed via env variables.

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

(venv) [user@pc dace]$ DACE_compiler_fpga_vendor=intel_fpga DACE_compiler_intel_fpga_board=s5_ref python3 samples/fpga/axpy_transformed.py 
/home/<user>/Projects/fpga_dev/dace/dace/frontend/python/parser.py:181: UserWarning: Using decorator arguments for types is deprecated. Please use type hints on function arguments instead.
  warnings.warn('Using decorator arguments for types is deprecated. '
Scalar-vector multiplication 24
Traceback (most recent call last):
  File "/home/<user>/Projects/fpga_dev/dace/dace/codegen/compiler.py", line 232, in configure_and_compile
    _run_liveoutput("cmake --build . --config %s" % (Config.get('compiler', 'build_type')),
  File "/home/<user>/Projects/fpga_dev/dace/dace/codegen/compiler.py", line 416, in _run_liveoutput
    raise subprocess.CalledProcessError(process.returncode, command, output.getvalue())
subprocess.CalledProcessError: Command 'cmake --build . --config RelWithDebInfo' returned non-zero exit status 2.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "samples/fpga/axpy_transformed.py", line 43, in <module>
    sdfg(A=A, X=X, Y=Y)
  File "/home/<user>/Projects/fpga_dev/dace/dace/sdfg/sdfg.py", line 2341, in __call__
    binaryobj = sdfg.compile()
  File "/home/<user>/Projects/fpga_dev/dace/dace/sdfg/sdfg.py", line 2266, in compile
    shared_library = compiler.configure_and_compile(program_folder, sdfg.name)
  File "/home/<user>/Projects/fpga_dev/dace/dace/codegen/compiler.py", line 241, in configure_and_compile
    raise cgx.CompilationError('Compiler failure:\n' + ex.output)
dace.codegen.exceptions.CompilationError: Compiler failure:
[ 16%] Building CXX object CMakeFiles/axpy_fpga_24.dir/home/<user>/Projects/fpga_dev/dace/.dacecache/axpy_fpga_24/src/cpu/axpy_fpga_24.cpp.o
In file included from /home/<user>/Projects/fpga_dev/dace/dace/codegen/../runtime/include/dace/intel_fpga/host.h:6,
                 from /home/<user>/Projects/fpga_dev/dace/dace/codegen/../runtime/include/dace/dace.h:41,
                 from /home/<user>/Projects/fpga_dev/dace/.dacecache/axpy_fpga_24/src/cpu/axpy_fpga_24.cpp:2:
/home/<user>/Projects/fpga_dev/dace/dace/external/hlslib/include/hlslib/intel/OpenCL.h:11:10: fatal error: CL/cl2.hpp: No such file or directory
   11 | #include "CL/cl2.hpp"
      |          ^~~~~~~~~~~~
compilation terminated.
make[2]: *** [CMakeFiles/axpy_fpga_24.dir/build.make:76: CMakeFiles/axpy_fpga_24.dir/home/<user>/Projects/fpga_dev/dace/.dacecache/axpy_fpga_24/src/cpu/axpy_fpga_24.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:115: CMakeFiles/axpy_fpga_24.dir/all] Error 2
make: *** [Makefile:91: all] Error 2

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?

[TizianoDeMatteis]

Ok:

• note that quartus is still seeing only the s5_ref, for whatever reason.
• regarding hlslib, ok good to know

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

$ aocl compile-config
-I/opt/intelFPGA_pro/19.1/hld/host/include 

and if I double check into the CMakeCache.txt (under `.dacecache/axpy_fpga_24/build)

...
//Intel FPGA OpenCL host code include directories.
IntelFPGAOpenCL_INCLUDE_DIRS:STRING=/opt/intelFPGA_pro/19.1/hld/host/include
...

Note: aocl compile-config is the command hlslib uses to extract OpenCL header paths

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).

[vselhakim1337]

In dace repo dir I did:

python3.8 -m venv venv
pip install -e .

I have opencl-nvidia and ocl-icd packages installed from the official Manjaro repos (or Arch). No other opencl libs installed, besides what comes with those and the Intel SDK stuff.

On your note:

(venv) [user@pc dace]$ aocl compile-config
-I/home/<user>/intelFPGA/19.1/hld/host/include

yields exactly the same results.

Regarding the CMake cache:

(venv) [user@pc dace]$ cat .dacecache/axpy_fpga_24/build/CMakeCache.txt | grep IntelFPGA
IntelFPGAOpenCL_AOC:FILEPATH=/home/<user>/intelFPGA/19.1/hld/bin/aoc
IntelFPGAOpenCL_AOCL:FILEPATH=/home/<user>/intelFPGA/19.1/hld/bin/aocl
IntelFPGAOpenCL_INCLUDE_DIRS:STRING=/home/<user>/intelFPGA/19.1/hld/host/include
IntelFPGAOpenCL_LIBRARIES:STRING=/home/<user>/intelFPGA/19.1/hld/host/linux64/lib/libalteracl.so;/home/<user>/intelFPGA/19.1/hld/board/s5_ref/linux64/lib/libaltera_s5_ref_mmd.so;/home/<user>/intelFPGA/19.1/hld/host/linux64/lib/libelf.so
IntelFPGAOpenCL_MAJOR_VERSION:STRING=19
IntelFPGAOpenCL_MINOR_VERSION:STRING=1
IntelFPGAOpenCL_RPATH:STRING=/home/<user>/intelFPGA/19.1/hld/board/s5_ref/linux64/lib;/home/<user>/intelFPGA/19.1/hld/host/linux64/lib
IntelFPGAOpenCL_VERSION:STRING=19.1
//Details about finding IntelFPGAOpenCL
FIND_PACKAGE_MESSAGE_DETAILS_IntelFPGAOpenCL:INTERNAL=[/home/<user>/intelFPGA/19.1/hld/bin/aocl][/home/<user>/intelFPGA/19.1/hld/bin/aoc][/home/<user>/intelFPGA/19.1/hld/host/include][/home/<user>/intelFPGA/19.1/hld/host/linux64/lib/libalteracl.so;/home/<user>/intelFPGA/19.1/hld/board/s5_ref/linux64/lib/libaltera_s5_ref_mmd.so;/home/<user>/intelFPGA/19.1/hld/host/linux64/lib/libelf.so;/home/<user>/intelFPGA/19.1/hld/host/linux64/lib/libalteracl.so;/home/<user>/intelFPGA/19.1/hld/board/s5_ref/linux64/lib/libaltera_s5_ref_mmd.so;/home/<user>/intelFPGA/19.1/hld/host/linux64/lib/libelf.so][/home/<user>/intelFPGA/19.1/hld/board/s5_ref//linux64/lib;/home/<user>/intelFPGA/19.1/hld/host/linux64/lib][19.1][19][1][v()]

[TizianoDeMatteis]

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?

$ ls /opt/intelFPGA_pro/19.1/hld/host/include/CL
cl.h    cl2.hpp     cl_d3d11.h              cl_dx9_media_sharing_intel.h  cl_ext.h        cl_ext_intelfpga.h  cl_gl_ext.h    cl_va_api_media_sharing_intel.h  opencl.h
cl.hpp  cl_d3d10.h  cl_dx9_media_sharing.h  cl_egl.h                      cl_ext_intel.h  cl_gl.h             cl_platform.h  cl_version.h

[vselhakim1337]

Installation of Quartus runs fine on Manjaro. I didn't run into any major issues, besides this.

$ ls ~/intelFPGA/19.1/hld/host/include/CL/
cl_d3d10.h  cl_ext_intelfpga.h  cl_gl.h  cl.hpp         opencl.h
cl_ext.h    cl_gl_ext.h         cl.h     cl_platform.h

So it seems the cl2.hpp is not there, and I have no idea why. This is a fresh SDK installation. On the other hand:

$ ls ~/intelFPGA/19.1/hld/host/include20/CL/
cl2.hpp     cl_dx9_media_sharing.h  cl_gl_ext.h  cl_platform.h
cl_d3d10.h  cl_egl.h                cl_gl.h      opencl.h
cl_d3d11.h  cl_ext.h                cl.h

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.

[TizianoDeMatteis]

I wonder why is creating another folder (include20), and aocl not returning it properly.

• is this Quartus Pro?
• Can you just copy-paste the content of include20 into include (or link it) and double-check what happens?

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 make RunJacobi2D.exe (under the right subfolder)

[vselhakim1337]

Okay, after renaming:

$ cd ~/intelFPGA/19.1/hld/host/
$ mv include include_tmp
$ mv include20 include
$ ls
arm32  include  include_tmp  linux64

then I ran the python example:

$ DACE_compiler_fpga_vendor=intel_fpga DACE_compiler_intel_fpga_board=s5_ref python3 samples/fpga/axpy_transformed.py 
/home/<user>/Projects/fpga_dev/dace/dace/frontend/python/parser.py:181: UserWarning: Using decorator arguments for types is deprecated. Please use type hints on function arguments instead.
  warnings.warn('Using decorator arguments for types is deprecated. '
Scalar-vector multiplication 24
Difference: 0.0

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.

[vselhakim1337]

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 de10_nano board (BSP from here). Same goes for any Cyclone V soc, I get the error

Traceback (most recent call last):
  File "test.py", line 36, in <module>
    sdfg(X=X, Y=Y, Z=Z)
  File "/home/deadbeef/Projects/cheetahai/dace/dace/sdfg/sdfg.py", line 2341, in __call__
    binaryobj = sdfg.compile()
  File "/home/deadbeef/Projects/cheetahai/dace/dace/sdfg/sdfg.py", line 2266, in compile
    shared_library = compiler.configure_and_compile(program_folder, sdfg.name)
  File "/home/deadbeef/Projects/cheetahai/dace/dace/codegen/compiler.py", line 225, in configure_and_compile
    raise cgx.CompilerConfigurationError('Configuration failure:\n' + ex.output)
dace.codegen.exceptions.CompilerConfigurationError: Configuration failure:
-- The C compiler identification is GNU 13.1.1
-- The CXX compiler identification is GNU 13.1.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Found OpenMP_CXX: -fopenmp (found version "4.5")
-- Found OpenMP: TRUE (found version "4.5") found components: CXX
-- Found IntelFPGAOpenCL: /home/deadbeef/intelFPGA/19.1/hld/bin/aocl
-- Configuring done (1.0s)
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
stdc++_PATH (ADVANCED)
    linked by target "sdfg" in directory /home/deadbeef/Projects/cheetahai/dace/dace/codegen
-- Generating done (0.0s)
CMake Generate step failed.  Build files cannot be regenerated correctly.

[TizianoDeMatteis]

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.

[vselhakim1337]

@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:

FPGA: Xilinx FPGAs require the Vitis suite and Intel FPGAs require the Intel FPGA SDK to be installed.

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.

[TizianoDeMatteis]

@vselhakim1337

Nowhere in there is mentioned which versions to use

Right, we can be more explicit on this, mentioning that has been tested only with Intel FPGA PRO.

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.

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")

[vselhakim1337]

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 a10_ref (this package actually includes a10gx and a10gx_hostch), c5soc, s5_ref. The a10 boards all require the pro version, so I cannot use this. The s5_ref which I assume to be Stratix V works, just as the previous examples. c5soc which I assume to be a Cyclone V SoC reference board gives me the same std++PATH error as before. Notice that this is not even a randomly downloaded board BSP, it's what comes with the installation. It is unfortunate, because I want my development and workflow to target these FPGA's, since these are the type of boards I have at my disposal.

Here are my conclusions so far:

• The CMake system does not automatically find the OpenCL paths from the Intel SDK
• There is a CMakeLists.txt file in codegen, that is separate from the one from hlslib. Note sure if this is relevant, and additional config is needed for more specific types of builds
• One has to make sure that there isn't a system-wide OpenCL header package installed on their system, otherwise dace/hlslib automatically use that instead of the IntelSDK's headers
• Cyclone V socs (and probably other low-density FPGAS) are not supported: seems that this comes from the host code libraries, which for Cyclone V are probably ARM-based, hence why CMake fails to find the standard libs (just a speculation)
• Most of DaCe is predicated on the use for high-end FPGAs that require a Quartus Pro installation (and therefore license)
• The documentation for setting up DaCe is underwhelming/incomplete. I would go as far to say that it is underwhelming in general, with a lack of clear instructions on how to use the tool, but this is a separate issue I am willing to discuss.

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.

[TizianoDeMatteis]

Hi @vselhakim1337,

thanks for the in-depth analysis. Let me go over point by point:

The CMake system does not automatically find the OpenCL paths from the Intel SDK

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.

There is a CMakeLists.txt file in codegen, that is separate from the one from hlslib. Note sure if this is relevant, and additional config is needed for more specific types of builds

Yes, that is normal. They are two independent projects, each one with its building systems.

One has to make sure that there isn't a system-wide OpenCL header package installed on their system, otherwise dace/hlslib automatically use that instead of the IntelSDK's headers

This needs more testing. So far we never had any issues, but thanks for the heads up

Cyclone V socs (and probably other low-density FPGAS) are not supported: seems that this comes from the host code libraries, which for Cyclone V are probably ARM-based, hence why CMake fails to find the standard libs (just a speculation)

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

Most of DaCe is predicated on the use for high-end FPGAs that require a Quartus Pro installation (and therefore license)

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)

The documentation for setting up DaCe is underwhelming/incomplete. I would go as far to say that it is underwhelming in general, with a lack of clear instructions on how to use the tool, but this is a separate issue I am willing to discuss.

As already said, we are working in improving DaCe documentation and users inputs (like yours) are very valuable in this.

[tbennun]

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.

The documentation for setting up DaCe is underwhelming/incomplete. I would go as far to say that it is underwhelming in general, with a lack of clear instructions on how to use the tool, but this is a separate issue I am willing to discuss.

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.

[vselhakim1337]

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.

[vselhakim1337]

@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 if-elseif-else chain in dace/codegen/CMakeLists.txt, lines 57-97 and putting Xilinx on top, the error was resolved. The CPATH variable also seems to interfere.