Freedom FPGA?

Now that SiFive successfully created the Freedom E310 and Freedom U540 chips, I was wondering, what do people think about creating a Freedom FPGA following the same principles?

It would be well documented, and it would take advantage of foss development tools. This would make it possible to completely develop using foss tools, without the need to reverse engineer anything like is done with the ice40.

I think a Freedom FPGA that is tuned to help instantiate efficient soft riscv cores would be awesome!

I also think it should be easier to create than the E310 and U540, since it could be made with a simple regular structure like the simplest ice40’s.

Any use?

Disclaimer - I work for Microchip/Microsemi on this stuff. :slight_smile:

Where can I download the bitstream format specification?

What bitstream format specification?

@tgm : the bitstream is the configuration file used to configure the FPGA. All FPGA compagnies keep this description secret, your company too :wink:

If we want the specification we have to do reverse-engineering on bitstream like it was done for ice40:

But without bitstream specification, it’s impossible to have a fully open-source toolchain for FPGA.

Still not totally sure what you mean.
The tools in question (Libero SoC) generate a programming files in STAPL file format which is an open format.
Unless you mean that format of the actual FPGA programming data that the STAPL file carries as a payload?
To be fair our FPGAs are not open source and are commercial offerings so maybe not exactly what you are looking for here?
I just thought that when you were asking about RISC-V on FPGA then our stuff might have been of interest to you.

Hope this helps.

So How much is microsemi’s development system?

Hi Phil

For Libero SoC (the EDA tools) licensing see here - there are a couple of free license options:

For SoftConsole see here (it’s totally free):

Hope this helps.

From the lack of responses, I take it nobody cares about a freedom FPGA? Am I the only one who cares about this?

1 Like

I for one would be interested, but I can also envision it as being a diversion of focus for the SiFive effort.

I’m not an expert on that, but I think it would be a huge and maybe fatal diversion. SiFive is doing processors. The processes and design methods for FPGA, SRAM, DRAM, Flash are all very different from processors (and from each other).

It’s inevitable that you’ll start to see RISC-V processor hard cores embedded in FPGAs, Flash and maybe other things from companies specialised in those fields e.g. Western Digital (Sandisk) or Microsemi (FPGAs).

It would be nice if some of those were well documented and open but that’s really up to those companies. RISC-V is permissively licensed, not GPL.


As you are here and as you work for an FPGA company I have some questions…

What is not clear about this?

If we want to create an Open Source tool chain to turn HDL into a Microsemi FPGA bitstream we cannot. Not without some huge reverse engineering effort.

Why? Why is the bitstream format not documented and published?

This is not just a question for Microsemi but all FPGA companies.

Imagine having to buy an Intel or ARM CPU with no documentation of their instructions sets? Having to use their closed source C/C++ compilers and other tools?

Crazy idea isn’t it? But that is where FPGA’s are. Kind of stone age in that respect.

Imagine if Microsemi opened their bitstream format. Documented what was needed to create a working FPGA. Then the likes of Clifford Wolf and others, of Yosys fame, would soon create open source tooling. The world would rejoice. Microsemi would live up to the RISC V hype it puts out.

It would be a hit. A Unique Selling Point among FPGA vendors.

Why not?

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.