3 ms·

> You're not gonna like this answer but every time I've had some issue like that at work the answer is: file a ticket with your local Xilinx field applications

> You're not gonna like this answer but every time I've had some issue like that at work the answer is: file a ticket with your local Xilinx field applications engineer. Basically this. I've been using the Intel OneAPI tools to write for their FPGA's in SYCL, and seem to have run into a large number of fundamental bugs (including plain routing errors) that makes me wonder how many other people are actually using the tools.

krapht 4y ago
Well, now you know the answer is almost nobody :). Xilinx and Altera have been promising efficient high level C++/openCL/CUDA -> FPGA compilation for decades now and almost everybody I know has been burnt by it at work, so thanks for confirming my bias, I'll avoid OneAPI too for the present. Guess VHDL and Verilog and the old standard tooling will live for another 10 years. Everything is always amazing for the first 80% but the last 20% is impossible to fix and you end up not saving any dev time at all.
- misnome 4y ago
  > I'll avoid OneAPI too for the present. I wouldn't write it off _completely_, for everyone. Compiler bugs notwithstanding, it seems to work reasonably well if you don't mind extremely long compiler cycles for running on the hardware. It gives you pretty reasonable emulation tooling to work out how well it runs, whether things are pipelined and, efficient if you know what you are looking at - but it doesn't seem to save you actually having to learn how the FPGAs work and model data flow. Of course, you are also beholden on drivers/adaptors being written to actually be able to use them.... which at this point is two chipsets, the newer of which has just been deprecated. Evaluating Xilinx HLS is next on my list, at least it seems to have the benefit of being around for much longer, and we have collaborators who have had success with the tooling.
AlteraThrowaway 4y ago
It's not so much that no one is using it. It's more that the only people who are using it have dedicated engineers in the compiler team developing the tool who will dig through the compiler and figure out/fix bugs. Literally even within Intel, internal customers would have to fund head count in the compiler team in order to have a dedicated engineer who could support them in figuring out how to tailor their code for the compiler or fix the compiler to work with their code. And since that process involves hand-hacking the compiler it introduces far more bugs than it fixes.

krapht 4y ago

Well, now you know the answer is almost nobody :). Xilinx and Altera have been promising efficient high level C++/openCL/CUDA -> FPGA compilation for decades now and almost everybody I know has been burnt by it at work, so thanks for confirming my bias, I'll avoid OneAPI too for the present. Guess VHDL and Verilog and the old standard tooling will live for another 10 years. Everything is always amazing for the first 80% but the last 20% is impossible to fix and you end up not saving any dev time at all.

misnome 4y ago
> I'll avoid OneAPI too for the present. I wouldn't write it off _completely_, for everyone. Compiler bugs notwithstanding, it seems to work reasonably well if you don't mind extremely long compiler cycles for running on the hardware. It gives you pretty reasonable emulation tooling to work out how well it runs, whether things are pipelined and, efficient if you know what you are looking at - but it doesn't seem to save you actually having to learn how the FPGAs work and model data flow. Of course, you are also beholden on drivers/adaptors being written to actually be able to use them.... which at this point is two chipsets, the newer of which has just been deprecated. Evaluating Xilinx HLS is next on my list, at least it seems to have the benefit of being around for much longer, and we have collaborators who have had success with the tooling.

AlteraThrowaway 4y ago

It's not so much that no one is using it. It's more that the only people who are using it have dedicated engineers in the compiler team developing the tool who will dig through the compiler and figure out/fix bugs. Literally even within Intel, internal customers would have to fund head count in the compiler team in order to have a dedicated engineer who could support them in figuring out how to tailor their code for the compiler or fix the compiler to work with their code. And since that process involves hand-hacking the compiler it introduces far more bugs than it fixes.