> Edit: I see you're strictly working with only free/open source tooling. I commend your patience. I also don't see the point. It's not the right choice for either learning or getting things done at the current moment.

A bit late, but my original point was that so many of the tutorials appearing these days that claim to explain FPGA development, especially to people with a software background, don't deal with the practical problems that a SW dev has with FPGA development.

BTW this doesn't only apply to the open toolchain. The segfault problem specifically appeared with closed tools from the FPGA vendor. From a SW dev experience this is definitely new territory because things like javac, tsc, React, Hibernate, and log4j don't segfault if you look at them the wrong way, and even if they did, you can look at the source code and find what is causing the problem. None of this is possible with a closed, vendor-specific synthesis tool nor with a blackbox FPGA primitive with close to no documentation, and while it is often suggested that "FPGA development is hard because you have to think parallel", none of this is even remotely related to that.

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

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.

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.

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