dkarchmer

A little of both :-)

I was one of the biggest champions of opening our SW and worked hard to create open APIs to give access the device database and timing engine, even where there was no real business justification. The limitation was always what we could make usable without shipping an Altera engineer with the SW. A fair amount is available but unfortunately undocumented. If you look close enough, a some of the features in Quartus are written in plain Tcl, which you can reverse engineer.

It is not the bitstream per say that you want, but the full description of the Device Database (defining every programmable switch in the FPGA).

Somebody asked why are FPGA EDA tools so large. Well, this is the number one reason.

So, at the end of the day, the real reason why FPGA companies don't open source their bitstream (and as I said, the actual database) is simply because it will be a major undertaking for them to document in any way that will actually make it possible for the community to use. An FPGA is NOT a processors so it not as easy to document as documenting an instruction set.

So, very hard to do, and not enough of a business justification to do so (combined with old school management that don't really understand the value of open source). That is it.

BTW, it will actually be relatively doable to document the basic Logic Cell, but the problem is that in today's modern FPAGs, the logic portion is a relatively small portion (when considering complexity) compared to the very complex I/O interfaces.

I think the best you can hope for (and what I believe both X and A are moving towards) is a more flexible tool flow, and heavy use of technologies like Partial Reconfiguration, which should allow you to build lots of tools and simply use the FPGA tools (mostly P&R and Timing Analysis) as "smaller" black boxes, while allowing open source or third party to build higher level system integration tools (which IMO, is what is more needed today).