Forum Discussion
Sorry, I should have mentioned that I was using the OpenCL development flow when encountering the problems I described above, not OneAPI. As I said, I found a workaround for those issues which required compiling the host code on an fpga_compile node (s001-145 to s001-156) for profiling on a pac_a10 board, but required compiling the host code on an fpga_runtime node (s001-081 to s001-102) for emulation.
When I did use the OneAPI flow to build the vector-add example as in "https://devcloud.intel.com/oneapi/get-started/base-toolkit/#get-started-with-the-intel-oneapi-base-toolkit-on-the-devcloud", the instructions said to build the design on an fpga_compile node and to run it on a pac_a10 board in an fpga_runtime node, and I tried followed that pattern when building and and profiling a design using the OpenCL development flow, which is how I encountered the problem I originally described.
However, as the quickstart guide example you referred to does both the build and the run on an fpga_runtime node, is it safe to assume that's a reasonable thing to do, etiquette-wise, or should designs generally be built on fpga_compile nodes, at least if they are likely to take long time?
I did successfully build and run that quickstart example. Is there a way to do profiling using OneAPI?
Thanks,
Dennis