Open Source for Hardware?

a recent article by Jeremy Bennett.

Open source is well established as a business model in the software world. Red Hat is now approaching the market capitalization of Sun Microsystems, while IBM, the worlds largest patent holder, makes more money from open source than other software (source: BBC Radio 4 “In Business”). Major tools such as the Firefox web browser, the Apache web server and the Eclipse IDE are all open source.


Now here's a novel idea. What about open source for hardware? At first sight this seems a non-starter. Open source relies on the nil marginal cost of software distribution, but hardware has to be manufactured.

But a modern silicon chip is typically built from silicon “intellectual property” (IP), written in a hardware description language such as Verilog or VHDL. Fabless design houses may never produce a chip themselves—one of the largest and best known is ARM in Cambridge, whose processor IP is built by other companies into one billion chips ever month. That IP costs the same amount to produce, whether it goes into one chip or one billion.

Hardware is software, and open-source hardware looks like a red-hot area these days. Do we have any open-source hardware developers lurking on LtU? If so please say hello. :-)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.


Odd that OpenSPARC was not mentioned.

Depends upon how you define "hardware".

Do you mean boards?

Or circuits?

Or bicycles?

One barrier to general open source hardware is that the "real world" is a messy place, and that messiness can hinder adoption. If I open source a circuit that needs soldering and a board that needs fabbing, that's a bit more work than just slurping down some software, typing "configure", and "make". There's lots more variables than just OS version number and architecture (temperature! vibration!).

Hence the reprap.

See It's not all there yet, but I believe they're working on electronics synthesis. IMHO, the reprap is one of the most astonishing and astonishingly little known projects out there. The boards are all single-sided, but I'm sure blowing a few dozen PhD students through it will change its limitations someday, just like programming systems!


The Arduino motherboards you mention seem to be the Free/open design that I hear most about these days. They seem to be the controller of choice for hobbyist robotics.

Soldering together (and then desoldering, and then ...) a project is bread-and-butter to the hobbyist project, but chip & motherboard fabrication is another story. I'd be curious to see a graph of how the cost of having designs fabricated has changed over time.

Designing Hardware from/for LtU-style Computation

This interesting post is missing a connection to the LtU areas of concern, but it can be connected. I would ask:

(1) Where are the FLOS (Free/Libre Open Source) hardware designs which are generated from elegant declarative LtU-style specifications?

(2) Where are the FLOS designs for processors which efficiently support the computation models discussed on LtU?

I see no significant commercial movement towards either of these goals and it may be that FLOS could make the difference. Until such designs can be realized by independent Fabs at costs reasonably comparable to those of conventional processors we are doomed to the mess of mapping elegant computation models to the mediocre but cheap 8086-family processors.

HDLs on LtU

I'm not sure why you say that Luke's post is "missing a connection to the LtU areas of concern". Hardware languages have received pelnty of attention on LtU in the past - in part because, as Luke says, "hardware is software.

Also, I'm curious: what do you consider "LtU-style computation"? I've always seen LtU as a programming languages blog (which encompasses many styles of computation), rather than as an advocate for any specific style of computation.

FLOS hardware design

Academia and corporate research labs are a good source of interesting FLOS hardware.

(1) Where are the FLOS (Free/Libre Open Source) hardware designs which are generated from elegant declarative LtU-style specifications?

There are a number of FLOS designs done in BSV available from MIT.

(2) Where are the FLOS designs for processors which efficiently support the computation models discussed on LtU?

There is the reduceron (which is itself written in a variant of Lava) and also the RAMP project.

The wide availability of FPGA platforms closes a lot of the economic gap between software production and hardware production. I believe it is the increasing capabilities of FPGAs that will make open source hardware really work.

High-level HDL and opencores?

Is there much interaction between the high-level HDL hackers (Lava, MyHDL, ..) and the open-source hardware community (opencores..)? Can I find for example and I2C bus controller written in Lava and ready to integrate with an OpenSPARC System-on-a-Chip? I'd be very interested to see applications like that.

Open hardware and high-level HDLs

Disclaimer: I work for Bluespec.

The vast majority of content on OpenCores is in Verilog and VHDL. All of the high-level HDLs are lumped into the Other language category.

I know that there are H.264, 802.11a and MD6 designs in BSV on opencores -- For some reason they are listed as Other even though there is a Bluespec language category.

My take on things is that there is too little cooperation between the open source hardware folks and the high-level HDL folks. For instance, at Bluespec we have a large library of IP written in BSV that we provide with our tool set. We make the tools and IP available at no cost to academics, but not to the wider community of free hardware hackers. We've discussed this in the past but never come up with a good method to make it happen.

XMOS open-source hardware

Another company making programmable hardware which allows you to wiggle I/O pins from software is XMOS. The dev kits have a lot more oomph than an Arduino and so you can do quite a bit in the way of DSP-like processing -- audio appears to be a popular application if their website is anything to go by.

Looks easier than FPGA work for a software engineer, using C (and some extensions for parallelism) rather than VHDL or Verilog...

(They have a community site at too)

The general point is that

The general point is that you can't have open-source without also having "source", which means that open sourcing stuff brings about (or with it) languages and language-based tools.

Intellectual property

An interesting point in the article:

There is a fly in the ointment—the legal position. Open source software relies on licenses such as the GNU General Public License (GPL) to enforce the “freedom” rules. These in turn are based on copyright law, which has for a long time been held to apply to software and its publication. Most open source hardware projects to date have used the GPL or similar contracts, even though it is explicitly not suitable for hardware use. Although silicon IP is written in a description language, its results are typically disseminated through manufacture, not publication.

Is that true? If I go fetch some GPL C source, compile it to machine code, and then burn the machine code onto an optical disk have I not in effect used the C source as a description language that (partially) specifies the manufacture of a physical product? Yet the GPL appears to say that any recipient of the physical product must also be granted access to the source from which it was built plus license to make changes.

How is the C-to-disk situation different from using source in an HDL to layout a chip?

The Open Graphics Project

I'm doing some work for the Open Graphics Project. The current status is that an FPGA based development board (OGD1) is ready for production, with some prototypes already in use. VGA is almost done, as well as a basic 2D X driver. The target for the first production board is fixed-pipeline 3D rendering engine.

Of special interest here may be the fact that the design includes a very simple CPU (HQ), which is only about 500 lines of Verilog after stripping comments. Its main function is to handle the legacy VGA which historically has accumulated a fair amount of complexity and which doesn't require much processing power on modern technology, so that we don't spend precious hardware on it. The HQ code is written in assembly in a stackless environment, since we have 32 registers and yet no need for recursive calls. It might have been nice to write an LLVM backend to avoid the manual register allocation, but I'm not sure how feasible it is.