here's a few good reasons why it's hard to make easy-to-use vendor-neutral FPGA tools:
- all the devices/bitstream formats are proprietary with little or no documentation of the logic blocks or programmable interconnect structures. it is probably technically easier to build a new FPGA from scratch and design tools for that, than to reverse engineer existing chips [1]
- there is very little cross-compatibility between vendor products (a 4-lut here, a 6-lut there, some carry-chain logic here, a DSP block there)
- all the optimizations (synthesis, place-and-route) are NP-hard problems
- sequential imperative (C-like) thinking is not the correct way to make parallel systems
- the FPGA vendors compete on tools and offer their software for free to push hardware. hard for an independent vendor to compete.
all the optimizations (synthesis, place-and-route) are NP-hard problems
I suspect this one in particular could be chipped away at pretty successfully if the tooling were less closed. When you get some open benchmarks and let both researchers and systems-builders hack away at it, you can get very good practical solutions to NP-hard problems, as the current crop of SAT-solvers, SMT engines, and TSP-routing tools attest.
Commercial "vendor neutral" tools do exist, Synplicity was a public company which sold such tools for several years before branching into proto board hardware sales and then being acquired by Synopsys [1]. Their tools for synthesis, partitioning and debug are still available [2] and strong sellers to both Altera and Xilinx FPGA developers.
While I find your comment informative, points 3 and 4 do not really explain why vendor-neutral tools cannot exist. Point 2 (my best understanding) should not be a breaking issue if documentation and specifications are available (which is covered by point 1). It seems to me that point 5 is part of the thing they have done to prevent alternative tools to come to market. Lastly, point 1 is exactly what begs for disruption.
The manufacturers also treat the exact implementation details of their FPGAs - how exactly all the routing fabric is structured, the fine details of some of the macros, etc - to be their secret sauce that gives them an edge over their competitors. So they're pretty hostile to the idea of documenting anything.
- all the devices/bitstream formats are proprietary with little or no documentation of the logic blocks or programmable interconnect structures. it is probably technically easier to build a new FPGA from scratch and design tools for that, than to reverse engineer existing chips [1]
- there is very little cross-compatibility between vendor products (a 4-lut here, a 6-lut there, some carry-chain logic here, a DSP block there)
- all the optimizations (synthesis, place-and-route) are NP-hard problems
- sequential imperative (C-like) thinking is not the correct way to make parallel systems
- the FPGA vendors compete on tools and offer their software for free to push hardware. hard for an independent vendor to compete.
[1] some reverse engineering efforts exist. see "From the bitstream to the netlist" http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.117... / http://code.google.com/p/debit/