Packaging FPGA bitstreams

RISC-V is an open source instruction set architecture (ISA).

I was broadly looking at what it would take to support RISC-V in
Fedora, and as well as the usual things like kernel, GCC, binutils,
maybe cross-compilers, and all the stuff that's the same for any new
architecture, there is one problem which is specific to RISC-V.

Because no hardware implementation of RISC-V exists that you can
buy[1], currently you have to use an FPGA development kit and use one
of the FPGA implementations -- I'm using lowRISC[2]. There are
affordable FPGA kits for around US$150-$320 based on the Xilinx
Artix-7 FPGA which are supported by lowRISC.

The source for the RISC-V CPU core (called "Rocket") is written in
Verilog and is free software (3-clause no advertising BSD).

In FPGA-land, a "bitstream" is kind of like a binary or a firmware

Unfortunately to compile the source code to a bitstream, things get
very proprietary. For Xilinx, you have to install their proprietary
compiler, Vivado. It's not just proprietary but it has node-locked
licensing so it's user-hostile too.

There is a second sub-problem, but one which is going to be overcome
soon. At the moment there is only a free CPU core. However to talk
to the outside world even on an FPGA, it needs peripherals like a UART
(serial port), SD card reader and some other SPI peripherals. These
are provided by Xilinx and are (of course) proprietary IP. However
lowRISC plan to replace these with free software peripherals later
this year[3].

Once you've compiled your bitstream, you then need to write it to the
FPGA. Writing a bitstream to the FPGA turns the FPGA into a RISC-V
processor and you can boot Linux on it from an SD card.

You can use the proprietary Vivado tool to write the bitstream to the
FPGA, but there are also open source tools to do this. I used
xc3sprog[4] (GPLv2).

This all really works - I've been documenting building everything from
source on my blog[5].

In summary:

- Compiling the Verilog source code to a bitstream requires highly
proprietary tools and will never be possible in Fedora.

- Writing the bitstream to the FPGA is possible with GPL tools.

- There are currently some proprietary bits in the bitstream, but I
hope those will be removed at some point.

Obviously the last point makes this moot right now, but assuming that
can be fixed, here is my question: Can we package these bitstream
files in Fedora? It would allow a more immediate out-of-the-box
experience where you just plug in the development kit and go.


[1] Hardware impls do exist, but they are all research projects so
far, or otherwise not for sale.
[2] <a href="" title=""></a>
[3] <a href="" title=""></a>
[4] <a href="" title=""></a>
[5] <a href="" title=""></a>


Re: Packaging FPGA bitstreams

By Kevin Kofler at 07/27/2016 - 16:28

Richard W.M. Jones wrote:
So this is a binary blob that cannot be rebuilt with Free Software, and thus
not allowed in Fedora.

Kevin Kofler

Re: Packaging FPGA bitstreams

By Richard W.M. Jones at 07/28/2016 - 04:18

On Wed, Jul 27, 2016 at 10:28:38PM +0200, Kevin Kofler wrote:
We ship firmware so this is not (necessarily) true.


Re: Packaging FPGA bitstreams

By Nico Kadel-Garcia at 07/28/2016 - 22:19

On Thu, Jul 28, 2016 at 4:18 AM, Richard W.M. Jones < ... at redhat dot com> wrote:
Still not reasonable for Fedora, I think. Red Hat, and RHEL, can
manage registered licensing to build this binary blob. But binary
blobs with no tool chain to build htem? That's begging for the
insertion of malware or back doors, or even patent and software
violating content. It's certainly a direct violation of the intent of
the GPL licensed tools that form so much of the base of Fedora's build

Re: Packaging FPGA bitstreams

By DJ Delorie at 07/29/2016 - 13:10

Nico Kadel-Garcia < ... at gmail dot com> writes:
The GPL3 no longer requires us to provide tools used to compile such
objects, as long as such tools are general-purpose and used unmodified:

"The “Corresponding Source” for a work in object code form means all
the source code needed to generate, install, and (for an executable
work) run the object code and to modify the work, including scripts
to control those activities. However, it does not include the work's
System Libraries, or general-purpose tools or generally available
free programs which are used unmodified in performing those
activities but which are not part of the work. For example,
Corresponding Source includes interface definition files associated
with source files for the work, and the source code for shared
libraries and dynamically linked subprograms that the work is
specifically designed to require, such as by intimate data
communication or control flow between those subprograms and other
parts of the work."

We can reject such binaries based on Fedora's philosophy, but we cannot
reject them as violating the GPL.

Re: Packaging FPGA bitstreams

By Solomon Peachy at 07/28/2016 - 22:54

On Thu, Jul 28, 2016 at 10:19:07PM -0400, Nico Kadel-Garcia wrote:
So it's okay to ship opaque-but-redistributable binary blobs that don't
run on the host CPU (aka device firmware) without any source code (much
less a toolchain that can build it), but shipping something that comes
with fully redistributable (if not outright Free) source code is bad
because there's no Free toolchain to compile it? That doesn't make

I'm just trying to understand how FPGA "firmware" is any different than
regular device firmware, and how having source code code available
suddenly turns something from okay to include into something we can't.

- Solomon

Re: Packaging FPGA bitstreams

By Nico Kadel-Garcia at 07/29/2016 - 02:19

On Thu, Jul 28, 2016 at 10:54 PM, Solomon Peachy < ... at shaftnet dot org> wrote:
I detest both. Rechecking the published standard at
<a href="" title=""></a>, it
doesn't specifically list "must be compilable by Fedora developers
with Fedora tools", so you've a point.

It's still making me hold my nose and go "eewwww".

Re: Packaging FPGA bitstreams

By Daniel P. Berrange at 07/29/2016 - 05:13

On Fri, Jul 29, 2016 at 02:19:49AM -0400, Nico Kadel-Garcia wrote:
I think all involved really detest the situation and accept that it is
a horrible situation to be in. None the less, Fedora policy explicitly
allows opaque but redistributable firmware blobs. So unless someone wants
to push through a change to the policy I don't see a reason in Fedora policy
that would cause us to treat FPGA firmware differently from existing
firmware blobs we distribute.


Re: Packaging FPGA bitstreams

By Richard W.M. Jones at 07/29/2016 - 04:34

On Thu, Jul 28, 2016 at 10:54:16PM -0400, Solomon Peachy wrote:

I will just note that this code doesn't run "on" the host CPU, it *is*
the host CPU.

In many ways its no different from trusting your hardware. Did you
inspect the EDA tooling that was used to convert your CPU HDL down to
the photomask? Did you even get to see the source HDL for your CPU
(clue: unless you work for <large CPU manufacturer>, no you didn't).

Anyway if you have $350 burning a hole in your pocket, then I
recommend getting this board and playing with it - it's quite fun:

<a href="" title=""></a>

I have an idea to add RISC-V on FPGA as a Fedora "tertiary
architecture" (I made up that term), if anyone is interested in that.


Fedora on RISC-V (was: Re: Packaging FPGA bitstreams)

By Richard W.M. Jones at 07/29/2016 - 10:54

I wrote a rough initial plan, attached.


Re: Packaging FPGA bitstreams

By Solomon Peachy at 07/29/2016 - 08:16

On Fri, Jul 29, 2016 at 09:34:38AM +0100, Richard W.M. Jones wrote:
Heh, even if you work for <chip manufacturer> it's a bit of a rabbit
hole -- and if one thinks Vivado is proprietary and expensive, real EDA
tools are several orders of magnitude worse -- in cost, complexity, and
[in]stability alike.

Incidently, there's no inherent reason why a Xilinx FPGA bitstream file
would not be redistributable -- when you buy a "real" license for
Vivado, you generally get permission to use anything bundled with it
into your design. After all, the resulting bitstream is specific to the
Xilinx FPGA you targeted, and to use it you'll need to buy Xilinx
silicon, preferably in volume... :)

Distributing unencumbered sources is more complicated; You'd have to
take care to exclude any nonredistributable bits -- eg pure HDL IP
blocks only licensed for use on Xilinx FPGAs. However, Vivado is
structured in such a way that makes cleanly separating things relatively
simple, and you can write your project files/scripts so that they will
pull in all Xilinx-encumbered bits when you hit "go".

Anyway, back to the bit mines..

- Solomon

Re: Packaging FPGA bitstreams

By Josh Boyer at 07/29/2016 - 07:07

On Fri, Jul 29, 2016 at 4:34 AM, Richard W.M. Jones < ... at redhat dot com> wrote:
Small sidebar.

I've used the same term in the past, and after thinking about it quite
a bit recently I don't think it accurately reflects what this is.
We're trying to get away from primary/secondary as it is, and
something like this is probably more accurately labeled as an
"experimental architecture".


Re: Packaging FPGA bitstreams

By Peter Robinson at 07/29/2016 - 07:33

On Fri, Jul 29, 2016 at 12:07 PM, Josh Boyer < ... at fedoraproject dot org> wrote:
Yes, I completely agree with this sentiment. I've been actively moving
away from the term Secondary to Alternate architecture when referring
to non x86_64. I think "experimental" is a good term for referring to
RISC-V, MIPS and the the like.


Re: Packaging FPGA bitstreams

By Jason L Tibbitts III at 07/27/2016 - 07:30

"Richard W.M. Jones" < ... at redhat dot com> writes:

Depending on what you actually consider these data to be, this should be
somewhat covered by:

<a href="" title=""></a>

Alternately, this stuff seems to be something we could consider to be
firmware with the added benefit that we have source.

That's always nice. Otherwise I wouldn't see the use of packaging a
random binary blob that you can't actually use for anything.

If considered "firmware", this might not even be an issue depending on
the actual license. I don't know if we've ever had to address the
question of proprietary firmware for which we have source. That's
probably a question for the legal list.

- J<

Re: Packaging FPGA bitstreams

By Przemek Klosowski at 07/26/2016 - 12:05

On 07/26/2016 10:36 AM, Richard W.M. Jones wrote:
By the way, while the FPGA bitstream generation in general is still
highly proprietary, there is a break in the wall: Clifford Wolff
developed an open-source FPGA toolchain for Lattice iCE40 FPGAs
<a href="" title=""></a> .
Now, iCE40 is a fairly simple FPGA---that's why it was possible to
develop a non-proprietary toolchain for it. I am not sure what
limitations it imposes on the RISC-V flavor that fits on it----Clifford
has compiled PicoRV32 which I think is not suitable to run Linux, but I
am sure the rest is just a SMOP :)
<a href="" title=""></a>

Re: Packaging FPGA bitstreams

By Richard W.M. Jones at 07/26/2016 - 14:20

On Tue, Jul 26, 2016 at 12:05:23PM -0400, Przemek Klosowski wrote:
Right, in fact the proprietary bits have a firmware-like license as
was pointed out to me in this comment:

<a href="" title=""></a>

So subject to legal review of that license, maybe we can treat it as

Yes, hopefully this will develop into something we can use one day.

Right now the Artix-7 model that I'm using has > 100K cells, whereas
even the top of the line iCE40 has 7680. (But hey, the first ever
FPGA I used had 32, so we've come a long way.) Plus there are other
things in the Artix-7 that we use like the DDR3 RAM interface and the
UART, and in future one hopes the ethernet & VGA.

By this time next year it may be that lowRISC will have produced
actual silicon -- a 4-core Rocket + 8 "minion" mini cores
(<a href="" title=""></a>)

Architecturally this is going to be a strange bit of kit, because in
order to do any I/O (even a serial port) you will have to use the
minion cores, each running a mini OS. Linux cannot run on those
cores. The lowRISC plan is to run a NetBSD-based unikernel. I don't
know how (or if) we'd deal with that in Fedora.


Re: Packaging FPGA bitstreams

By Josh Boyer at 07/26/2016 - 11:26

On Tue, Jul 26, 2016 at 10:36 AM, Richard W.M. Jones < ... at redhat dot com> wrote:
You probably want to take this to the fedora-legal list. I would
recommend approaching it from the firmware exception viewpoint, and
treating bitstreams as such.