[aeruder]

C (or really any traditional programming language) doesn't really map to an FPGA. There are some compilers out there that attempt to convert traditional C code to state machines for FPGAs, but FPGAs are really a completely different paradigm. You're actually describing digital logic, not a sequence of steps.

That being said, there are soft-processors that have been written in VHDL/Verilog and can be incorporated into a FPGA design, and those CPUs do often have GCC support (Microblaze Xilinx, NIOS 2 Altera, plenty of MIPS CPUs out there, etc.).

[simias]

Oh that's not what I was implying, sorry for the confusion. I meant an open source, portable HDL compiler/synthesizer like what GCC/LLVM are for software. As the parent and many others point out in this thread the tooling is a really sore point for FPGA development. It's always big, clunky, often buggy closed source applications (often running on an unhealthy dose of Tcl scripts cobbled together).

And of course if you change supplier you have to relearn everything or pay for an other third-party closed source solution to abstract some of the differences between the environments of Xilinx, Altera/IntelFPGA and friends.

[aeruder]

Understood, and I totally agree that it is an industry ready for some shakeup.

I used to work for a large defense contractor doing FPGA work, and we really went out of our way to try to stick to 100% VHDL to attempt to avoid vendor lock-in. This meant things like writing block ram HDL in a way that it would be inferred by the synthesis tool to use the block ram (and not synthesize out of a bunch of LUTs).

It was a constant struggle to keep things synthesizing correctly. We mostly standardized on using Synopsys Synplify Pro for vendor-neutral synthesis and then using the Altera/Xilinx backend tools for place and route, etc. But even then, we regularly had to whitelist certain good versions of Synopsis' tools.

It was possible to do this with the vendor-specific synthesis tools too, but it was still a massive effort to check that primitives synthesized into the correct elements across different parts/vendors. Ugh, do not miss it.

[gcp]

The sore point of FPGA development is that not only the tooling is beyond terrible, it's also effectively a strong lock in. Changing designs is all but easy, even IF your design is not tied to specific hard fabric on the FPGA.

So you got terrible tooling and then a lock in into that tooling.

Not very appealing. Why the f--- would anyone use FPGA's unless they're the only option?