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