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).
"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."
I think this is your best argument. I believe one of the Big Two did open-source a large aspect of their FPGA's or software a while back. Maybe the bitstream. Nobody cared and they didn't make more money. So, they have no incentive to do that plus negative results that will probably happen.
While I never worked directly with dkarchmer, he was a pretty well respected director at Altera. I value his opinion here highly (not to mention it makes sense).
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.
Hi dkarchmer, thanks for your comments. I'm the author of arachne-pnr, the open-source pnr tool for the Lattice iCE40. One of my hopes is that by creating compelling open-source tools, it might be possible to change the value proposition for FPGA vendors to get involved in opening up the chip internals, although perhaps that's wildly optimistic. One of the hard parts is to get a realistic foothold. I like to think we're making some progress with the Icestorm project. I got a bug report from a user recently, and I quote, "We would like to do what we can to help fix your tools because the workflow is far superior." I know there's a world of difference between a big flagship FPGA and the iCE40.
I still like the analog with CPUs. If there was no gcc or LLVM and the vendors all had their own compilers, there would be little incentive to open up the ISA. In a word with gcc and LLVM, you're dead in the water if there isn't a port.
I was a little surprised to hear a big part of the job is documentation. How do the chip design teams communicate with the tool development teams? Or is there a problem with releasing internal documentation?
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).