Ignoring security or subversion concerns, there&#x27;s still plenty of reasons to want access to the bitstream. The brilliant work below gives several use cases in its opening section along with a clever workaround:<p><a href="https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20150906122018&#x2F;http:&#x2F;&#x2F;www.isi.edu&#x2F;~nsteiner&#x2F;publications&#x2F;soni-2013-bitstream-fccm13.pdf" rel="nofollow">https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20150906122018&#x2F;http:&#x2F;&#x2F;www.isi.ed...</a><p>Back to my analogy, the current situation is like having everything to produce assembler or binary but no tools to work with those. You can&#x27;t debug them, modify, hotload, do JIT&#x27;s, app restructuring... any improvement to your software that requires access to assembler or binary in RAM. Quite limiting eh, esp given JIT benefits?<p>Situation is similar for FPGA&#x27;s with open bitstreams allowing them to be manipulated in situations that would improve performance, flexibility, and so on. Instead, we get these closed bitstreams done all at once by inefficient tools. Poses artificial limits esp for embedded or dynamic scenarios. Opening them up opens up the full power of academic and OSS innovation to those areas. Much of the best innovations in ASIC and FPGA came out of academia so we want the rest opened for improvements.