&gt;It&#x27;s not the bitstream format that is stopping you. It&#x27;s the comprehensive tooling in this field that is not open which holds you back. It&#x27;s like not having access to GCC[...]<p>I don&#x27;t think that having a tool that can&#x27;t produce working binaries(bitstream or native code) would be that useful. Can you imagine a GCC that can&#x27;t produce native code but instead have to generate COBOL sources(with almost random feature set) to be compiled by vendors tools?<p>&gt;[...]Intel about their microcode[...]<p>Intel have a widely known instruction set that can be used with their cpus, there are many compilers, interpreters(and more) that generate and use it without problems, so I don&#x27;t see how this analogy is relevant<p>&gt;There is so much more to the process of creating something useful with an fpga.<p>You need tools and potential creators of such tools need access to bitstream format used by fpgas to create useful tools<p>&gt;The most useful tools in fpga dev have little to do with the part of translating the Verilog&#x2F;Vhdl into something the fpga understands.<p>But without the ability to translate your code(any code not just vhdl&#x2F;some variant of verilog) into bitstream, where you would run* it on? It&#x27;s hard to consider tool useful for fpga development when it can&#x27;t produce something that can be run* on fpga...<p>*oh come one, don&#x27;t be pedantic