Open-Source Hardware

May 31, 2002

Jim Turley-May 31, 2002

Open-Source Hardware
Hardware design's growing abstraction might lead you to think open-source development is just around the corner. Jim says that's not the case.

Open source is a powerful force in software development. So why don't we see the same thing in hardware? Modern chips, including microprocessors, are designed around "soft" reusable components. What's to keep hardware designers from collaborating on chip designs the same way others do operating systems?

Maybe we just have to wait a few more years before the open-source concept catches fire among microprocessor designers. It's more likely, however, that that day will never come. Despite all the advantages claimed by the proponents of open-source software, the same benefits will probably never accrue to hardware developers. Open source doesn't translate into the world of transistors and microprocessors.

On the surface, there's no obvious reason why open-source hardware couldn't work just as well as open-source software. Chip designers use (relatively) high-level languages such as VHDL and Verilog, or, at the very least, they draw schematics on a computer. These files can be shared just like source code. If volunteers can create entire operating systems using open-source techniques, surely a few dedicated engineers can make a microprocessor. Then the mighty dominion of Intel and others would be toppled, the dark soldiers of Big Business would be subjugated, and peace would envelop the land. You know the story.

Actually, they're already here. You can download any number of 8-bit, 16-bit, and 32-bit processors for free. Everything from little 8-bit microcontrollers to bona fide SPARC processors are there for the taking. They've been around for years. This begs the real question, and cuts to the heart of the issue: if you didn't know about these "shareware" processors before, why not? Or, if you did know about them, why aren't you using one?

The first question can be explained away as bad marketing. The commercial chip vendors spend millions of dollars promoting their processors, so naturally they're better known. In Pentium's case, the chip is a household name. (Did you ever think you'd see microprocessor chips advertised on television, sandwiched between light beer and luxury cars?) The second question is more interesting and casts some light on the reason open-source processors aren't more popular.

Why it won't happen

First, we're not talking here about giving away chips for free. "Open-source hardware" refers to the IP-the circuit design or schematics. You still have to make physical chips, and that costs money. Software is essentially free (in the sense of Richard Stallman's free beer) but silicon costs money, regardless of where the design came from. Nobody's promoting free microprocessor chips any more than the Free Software Foundation is giving away free computers.

Part of the charm of open source software is the "do-it-yourself" (DIY) aspect of it. If you find a bug, or just want to improve a feature, there's the possibility you could do so on your own. If you share that enhancement and give it back to the community, so much the better. But microprocessors are fiendishly arcane devices and the gothic horror show lurking within their circuits does not lend itself to DIY improvements. That's not to say big software projects aren't just as complex as microprocessors, only that hardware gates, signals, and pipelines interrelate in a way that lines of commented source code do not.

Alas, hardware is not as modular and compartmentalized as software. Maybe it's that ten-year delay again, but "spaghetti hardware" is as prevalent as spaghetti code used to be. That makes it difficult, if not risky, to modify someone else's hardware design. You may put this down to sloppy work habits, and maybe it is, but the fact remains. A small change to one part of a microprocessor is likely to interact in unforeseen ways with the rest of the processor.

Add to that the problem that hardware bugs can cause physical damage to the chip or to the rest of the system; maybe even to the operator. Granted, software bugs can be just as dangerous (especially in robotics and control).

No visible means of support

Support is another issue that dogs open-source hardware: there isn't any. As with most open-source software products, the support base is looking you in the mirror. For a product that you can edit and modify yourself, that may be fine. But once the complexity of the hardware exceeds the ability of a small group of engineers to wholly understand, support becomes a deep yawning chasm.

In fact, support is what most hardware IP companies are really selling, not the IP per se. Customers might pay $500,000 for a MIPS license, for example, so they can point the finger at MIPS if something goes wrong. (MIPS will likely point right back; its core designs are proven to work.) Dedicated engineers can-and have-designed their own MIPS clones; it's not all that hard. But what you don't get is the backing of MIPS Technologies and its affiliated software developers. You don't get support and your boss doesn't get a warm feeling that your product has a good chance of working. A hardware license fee buys insurance. Or in the worst case, a scapegoat.

This is one reason two microprocessor "cloners" both recently quit the business. Lexra (with its MIPS replica) and PicoTurbo (with its prosthetic ARM) both offered lower-cost alternatives to the genuine processor for less money. Yet neither firm had much success, even though their hardware (oops, IP) was good. Like knock-off perfumes, they didn't offer buyers the same cachet as the authentic product. Customers weren't paying for the processor itself; they were paying for security, compatibility, and accountability.

Open-source oscilloscopes

Compilers and debuggers are a lot cheaper than oscilloscopes, logic analyzers, and wafer probes. In a neat piece of reciprocity, software tools are even available for free under open source. Just about any programmer can afford the minimal start-up costs, but most hardware engineers don't have the fiscal throw weight to buy their own hardware development tools. You need an employer to do that, and institutional employers tend to impose institutional thinking.

Not only is developing hardware expensive, testing and debugging it is expensive, too. Some hardware designs might run fine in simulation or at low speeds, but tip over ungracefully at high speed. At-speed testing is vital, and speed drives cost in direct proportion. Testing a design in programmable logic like an FPGA doesn't do much good if the final chip will be implemented as an ASIC. If the final product has to run at, say, 250MHz you're looking at many thousands of dollars in testing costs.

Spinning an ASIC is hideously expensive. So much so that an entire industry has sprung up to supply pre-silicon verification tools to ASIC developers, all so they can ensure their chip works before the final, fateful silicon is forged.

Which brings us around to the financial incentive. The cheapest part of producing a chip is deciding what you want to do. After that, nearly a million dollars will change hands before you see your first chip. For that kind of outlay, these chips need to be fully characterized at all speeds, temperatures, and voltages. The cost of developing (or licensing) the hardware pales in comparison to the cost of the ASIC design tools and fabrication fees. Thus, there is little financial incentive to economize on an open-source processor.

Free vs. flexible silicon

Okay, so maybe there's no monetary enticement. What about the customization aspect of open-source code? Wouldn't it be great to make a processor that's "just right" and not be constrained by some lowest-common-denominator standard or architecture developed years ago? (This is the free speech corollary to the free beer.) Yes, Virginia, there is a way to do this, but it doesn't involve hacking your own processor. A few processor vendors supply configurable processor IP, ones that can be modified, altered, or customized with a minimum of pain and with some guarantee that the results will be pleasing. It's not open source by a long shot. These cores cost money and you pay for the ability to customize the design (those CPU-modification tools aren't trivial). So ideally you get the benefit of customization and commercial support.

On the flip side, not everyone wants their own custom mix. Oftentimes, it's desirable to make the hardware generic, or at least compatible, to provide access to the biggest software base. What would happen if every PC maker kept changing the hardware around and "improving" the PC? ("We'd have Macintoshes," I hear the devotees saying.)

Open-source software lends itself to collaboration. Programmers all over the world can cooperate on a project by sharing a source code base or by sending changes to each other via e-mail. It's not as fun to FedEx prototype chips back and forth. Hardware is tangible; it has mass and it takes a finite amount of time to transport. It can also get broken or lost in transit. Oh, sure, you can e-mail schematic files or Verilog around the globe, but then everyone on the team needs some way to fabricate prototype chips. More cost, more unreliability, and more uncertainty.

Software has the advantage that it can be updated in the field, or at least later in the product cycle. Hardware needs to be frozen earlier in development so the programmers have something to work on (sound familiar?). That characteristic tends to depress engineers' enthusiasm for repetitive changes or iterative testing. All outward appearances to the contrary, hardware guys would actually like to get their systems working the first time and knock off early. This all forces hardware designers to be more conservative and more likely to rely on existing, proven designs.

Open-source software has obviously captured the popular imagination. It's both an altruistic effort at cooperation and a passive-aggressive stab at the reigning dominant players. It works well for some products, some programmers, and some companies. But open-source techniques aren't getting traction in hardware, and they're not likely to any time soon.

Jim Turley is an independent analyst, columnist, and speaker specializing in microprocessors and semiconductor intellectual property. He was past editor of Microprocessor Report and Embedded Processor Report. For a good time write info@jimturley.com.

Return to June 2002 Table of Contents

Loading comments...

Parts Search Datasheets.com

KNOWLEDGE CENTER