Are you a hobbyist? Ha, have fun. Digging through the Xilinx forums is also productive.
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.
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.
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 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.
In LiteX, an open source toolset for making FPGA designs, you can embed an oscilloscope into your FPGA: https://github.com/enjoy-digital/litex/wiki/Use-LiteScope-To...
As memory is also limited, you specify a condition like if signal A becomes 0x1234, then log the aforementioned signals for N cycles.
But, you could split project into small parts, connected by some interface (could use triggers or 2-way ram cells), and debug them separate.
Sure, you will loss some capacity, but this is life.
This is not equal to test real solution, because physical arrangement matter, but most probably, you will find most obvious mistakes.
Does the problem not arise in simulation?
edit for clarification: The lack of simulation models is due to the free toolchain. The documentation is fully available, it's just so bad that you don't even know what some of the primitives are meant to do.
1 involving multiple primitives and you can't attach a signal logger to the signal between them because the FPGA doesn't have a path there to use.
The situation somewhat reminds me of the earlier LaTeX days when every tutorial started with "I'm assuming you have already installed LaTeX" as if that wasn't the biggest problem for most users, and then continues explaining the easy stuff that you can easily learn by trial and error.