The compound problem of this in reality is that finding the right people who have the right strain of semi-insanity to do this really well, is very slim. And most of them are tied up with a massive salary from some aerospace company such as Raytheon, GE, Honeywell, or someone like Philips (building medical devices).
Add to that compile times of an hour or a day, and you have a glacial development cycle on your hands.
The gist of which is you can now actually uncheck products you don't need to install, preventing them from being installed.
1. The optimization problems that EDA tools have to solve are about as hard as it gets - NP-hard and sigma 2p problems at a massive scale. I'd argue that these are among the hardest optimization problems in modern computer science today.
2. The number of people with the CS + EE training to develop this software is decreasing. Not a lot of people are getting PhDs in EDA anymore, because:
3. Regular software houses (Google, Amazon, etc.) have about 2-3x the comp as EDA companies. Trust me I've seen a lot of incredibly smart EDA people jump to Google and more than double their salary overnight.
I doubt Intel is going to shift the balance here. It's not easy to develop a fast and efficient SP&R flow.
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.).
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.
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.
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?
That would be more than neat, revolutionary really. But it would require buy-in from the major vendors, in the form of publishing many low-level device details.
I wish I had the time to play with it!
Tooling is 100% the thing keeping FPGAs back.
The big consumers of FPGAs don't care if the tooling is terrible, because they're coming from 80s development environments and practices and can afford to dedicate 50-person teams to the job function.
Smaller companies won't touch it because it's terrible, and the vendors won't improve it because there's no demonstrated market for improvements.
Or maybe the market economics work out, but are small relatively compared to the big players, so it moves glacially.
The ability for anyone to develop software for CPUs at zero-cost is an amazing freedom. You literally cannot do that on certain fpgas--not only do they cost thousands, so do the tools to actually create a working design.
Until that changes, FPGAs will always be niche.