This is the best argument, but doesn’t say that the bitstream has to be open. Here’s why:
There are a lot of trade secrets in Intel and ARM CPUs - in particular how out-of-order execution is implemented and scheduled, how branch prediction is done, and lots of other things. Those will likely be trade secrets in any hardware realization of any RISC-V realization, if only because the vendor needs to retain flexibility to change them without making some users have very high switching costs.
There are many undocumented/undocumentable aspects of Intel and ARM processors as well. For example, memory access ordering, the delay inserted by the PAUSE instruction, the structure and architecture of the QPI signalling or other inter-core signalling in the chip, the precise conditions under which a hardware thread gives up control to its peer thread, etc. These vary from model to model, and are not documented outside the company.
Consequently, what IS documented openly is the ISA and the IO architecture. Those are developer visible.
The lowest level bitstream encoding of an FPGA’s netlist is an encrypted stream, true. However there is a netlist just above that representation that is actually exposed to users if they want to generate tools of their own. The translator between those doesn’t run on the FPGA, it’s true: unlike general purpose systems designed to run Linux, FPGA’s can’t run their own toolset.
So what might be wanted is a way to convert the low level netlist to the FPGA bitstream that exposes an “abstraction” of the FPGA structure that is completely true to the underlying FPGA, up to the expected variation reserved to the FPGA vendor so it can improve in an upward compatible way.
Hiding inside (and not well documented) most of the FPGA toolkits available for free is just such a thing. I don’t know all vendors’ situations. I don’t think it can be distributed in source code form without a lot of work. But I suppose it could.
To make that reasonable and supportable, the FPGA vendor would have to expect that such an exposed interface would allow a rich vibrant tool industry to grow in the Open Source world. Because it would be the only payoff.
I’m sure that Xilinx doesn’t really benefit from the huge cost of maintaining tools, since those tools can only work with Xilinx FPGAs. They still have to expose an interface to other tools vendors (Synopsys, Mentor, …) in some way, and get paid to support them.
So what I’m saying here is that exposing an interface (like the bitstream) is a high risk of causing a high and unpredictable ongoing cost. Not for the business faint of heart.
The best example with RISC-V is the language, OS, and debug tools vendors who have had to spend a LOT of effort. SiFive’s success is absolutely dependent on delivery of quality tools on time from a community that is full of crazy political shit, and not a few people who think actually paying for others’ work is somehow insane.
The decision to work in the open isn’t trivial, and sometimes you have to think through the needs of such parties.
I think that Risk Capital, on the order of the cost of developing and maintaining a whole state of the art FPGA technology, licensing all the patents, … will be needed to achieve this goal.
DARPA or some random Billionaire who lives Open Source - there are almost none of these - get one of these to want it to happen.
Yosys isn’t a great example of the scale of commitment needed. But it’s an example worth putting into the hopper.