Some thoughts on Open Hardware

September 29, 2010 10:00:10 AM CDT

Let me start this off by introducing an acronym: NUSPI. It stands for No User Servicable Parts Inside.

To a large extent, Open Hardware is a reaction against NUSPI. Its ideals include the ability to open, inspect, reimplement, and modify hardware whenever, however, and for whatever reason the user wants.

Let's spin out an extreme example of NUSPI for reference: The device is completely enclosed, and built in a way that makes opening it not only difficult, but dangerous and expensive. Opening the package will almost certainly destroy the device, and even if you can get to the functional parts inside, they're built in a way that makes them essentially impossible to change.

You might be able to guess where I'm heading with all this:

Philosophically, Open Hardware developers have to cope with the fact that integrated circuits -- some of our most fundamental building blocks -- are about as NUSPI as a product can get.

Does that mean I think chips are evil? Hardly. But I do think there are some issues that Open Hardware developers should keep firmly in mind.

Issue 1: ICs are not made for us.

Integrated circuits are built for the commercial electronics market, and that market has different design criteria than we do.

The first rule of NUSPI devices is that it's okay to cram a large NUSPI box full of smaller NUSPI boxes.

The second rule is that NUSPI designers prefer to shove knowledge as far down the hierarchy of boxes as possible.

The person designing a commercial product doesn't want to explore the intricacies of voltage regulation, he wants to slap in a 780x regulator and move on. He doesn't want to be an expert in switching regulators, voltage controlled oscillators, analog-to-digital conversion, or any of a dozen other subjects. He wants to open a catalog and buy that expertise from somebody else.

By commercial standards, there are several advantages to that approach:

  • time-to-market is faster
  • the footprint for a given chunk of functionality will be smaller
  • mass-produced parts are usually cheaper than the equivalent assembly
  • the design will be optimized by experts
  • parts from any reputable vendor have performance guarantees

Superficially, those seem to be good for Open Hardware too, but there are also some problems.

Issue 2: ICs are products.

They have a finite commercial lifespan.

Circuit designs are only valuable as long as you can get the parts. The more of a circuit's functionality is implemented by chips, the more it depends on those chips continuing to be available.

Component vendors, meanwhile, only sell parts as long as a profitable market exists for them.

Now, certain components are so general that they're never likely to go out of production: the LM741 op amp, the NE555 timer, and that sort of thing. They continue to sell even though they've been around forever -- and often in spite of the fact that more highly optimized alternatives exist -- because they're so bloody useful. They're good enough for a wide range of applications, a mature body of engineering knowledge surrounds them, and everyone already knows how to use them.

The more specialized a chip gets, though, the smaller its range of potential application. That translates to a smaller market, and a greater risk that the chip will fail to earn its keep and be discontinued.

Thing is, specialized chips exactly fit the realm where commercial designers would rather buy expertise than solve the problem themselves.

NUSPI allows commercial designers to hide the effects of component obsolescence. Having a critical part go out of production is a major headache, sure, but NUSPI consumers never need to know that the technology under the hood of month's product is completely different from last month's.

Open Hardware developers don't have that option. We specifically demand the right to know what's under the hood. That means our designs are more sensitive to component availability than commercial designs.

Issue 3: NUSPI designs contain hidden assumptions.

That statement is slightly misleading.

Every circuit design makes basic assumptions. When you treat the circuit as a black box that provides certain functions, some of the underlying assumptions get hidden.

The trouble with NUSPI is that those assumptions stay hidden. And when we start talking about ICs, they really stay hidden.

Case in point: did you know that the 780x series of voltage regulators contain an (originally) undocumented 150Hz oscillator? It's part of the thermal overload protection circuit. If the device starts to overheat, the protection circuit shuts off the power, waits for a little while, then connects the power again.

It makes perfect sense once you know about it, but that explanation didn't get into the original datasheets. Bob Pease wrote an article about it some years after the product was released, with an apology to all those engineers who suddenly found their circuits humming away at the D below middle C.

There's another story, in EDN's Tales From the Cube series of war/horror stories, about A DSL modem seeing 50MHz noise while no part of the circuit was designed to oscillate at that rate.

The problem, again, turned out to be an undocumented clock in the CPU which was injecting noise into the ground planes, and the path of least AC impedance happened to run under one of the analog lines. The designers found both problems by pulling the read head out of a floppy drive and moving it over the circuit.

In theory, Open Hardware provides robust protection against gotchas like that. Hidden assumptions stop being hidden when you can break a circuit down to its basic components.. at least generally. You still have to watch out for magic. But every chip is a place where potential surprises can lurk.

Issue 4: NUSPI design principles perpetuate ignorance.

To clarify, I'm using the word 'ignorance' to mean 'a lack of knowledge' without implying anything about the person who lacks the knowledge. Ignorance is the state where everyone starts in a new subject, and is curable by learning.

Unfortunately, learning how to solve a problem is the last option on the NUSPI checklist, to be attempted only when you run out of catalogs.

The thing about ignorance is, it's recursive. If you have enough of it, not only do you lack the information to make an informed choice, you lack the information to know when you're making an uninformed choice.

In Tripping the Light Fantastic, Jim Williams talks about designing a high-efficiency power supply for CCFL laptop backlights. One of the first things he did was to take apart a selection of existing laptops and examine the circuits already on the market.

He was surprised to learn that they sucked. To quote him:

It appeared that most people making lamps were simply filling tubes up with gas and shipping them. In turn, display manufacturers just dropped these lamps into displays and shipped them. Computer vendors bought some "backlight-power-supply" board, wired it up to the display, took whatever electrical and optical efficiency they got, and shipped the computer.

Everyone just assumed that their suppliers knew what they were doing, and everyone was wrong. And these weren't amateurs. These were some of the best engineers some very expensive companies could afford, working on a system that represented up to 50% of the power consumption of a product where battery life was an important issue.

When people that good, with those resources and that motivation, screw up that badly, it's a sign of problems in their fundamental method.

So what does all this mean for Open Hardware?

Mostly it means that ICs aren't automatically in sync with our philosophy. We need to use them responsibly.

If we don't, our designs devolve to this:

and we just push our blind dependence on manufacturers a couple links back in the supply chain. The term 'Open Hardware' devolves to mean creating enclosures that house proprietary chips, and maybe wiring a few buttons.

As Moore's Law marches on, and the optimally profitable transistor budget per square centimeter of silicon doubles every 18 months or so, more and more functionality is being packed into those little black NUSPI boxes. As that happens, the superficial benefit of handing all our decisons over to the IC designers of some large corporation also increases.

We need to keep an eye on that.

I do have some suggestions though, both for individual designers and for the Open Hardware community as a whole.

Suggestion 1: Deprecate ignorance.

Let's face it: "I don't want to have to learn all that" is the last thing a proponent of Open Hardware should say.

If you want to buy functionality without having to know how it works, you're a consumer in the NUSPI marketplace. There's nothing intrinsically wrong with that, but it's not Open Hardware.

As individuals, and as a community, we need to push back against the pressure to let someone else do the thinking for us. We need to stop listening to people who say, "don't waste time reinventing the wheel," and get good at reinventing the wheel.

Close the parts catalogs, don't look at any reference circuits, and design a voltage buffer. The input is a 10k trimpot, the output has to go rail to rail for supply voltages between 3.3v and 12v. The circuit needs to source/sink 50mA. Don't worry about frequency response, assume the output will basically be DC. Do make it linear to within 1% across its full range, though.

No chips.

That kind of problem shows up over and over again in circuit design. Knowing how to solve the problem in various ways.. poorly, adequately, well, and incredibly well.. gives you a range of tools to attack any problem a design throws at you.

Knowing why the bad solution is bad, and what makes the good solution so good, involves knowledge that extends way beyond passing voltage from one place to another.

Without that kind of knowledge, you're stuck plugging someone else's solutions into every problem you see, regardless of how well they fit.

Suggestion 2: Use chips to do things better.

Nobody can be an expert on everything, and there's a risk of infinite navel-contemplation in Learning How Things Work. We have to balance the philosophical purity of knowing everything against the need to build circuits that actually do stuff.

In my opinion, the first and best option is to be able to implement some version of a chip's basic functionality from scratch, then use the chip for its other benefits: smaller footprint, reduced part count, lower cost, optimization by experts, etc.

In other words, feel free to enjoy all the benefits chips offer except, "I can't do X without chip Y."

Suggestion 3: Failing that, be honest.

Suggestion 2 is a bottom-up approach to design.. start with the basics and work up. It sounds nice in theory, but in practice, people tend to start in the middle and work out.

If you find yourself using a chip to acquire functionality you can't implement any other way, that's fine. Just say so.

For each chip in your design, explain what it does and how it justifies its existence. Do you need that LM339 comparator for its linearity, cost, speed, or footprint, or could you get equally good results from a quick and dirty 2-transistor differential amplifier?

Just asking those questions and explaining why the alternatives don't work is good design practice.

Suggestion 4: Document the process, not just the product

Implementations and production drawings are lousy documentation. They show you the final choices that were made, but don't give you any information about why those choices were made, or what alternatives were considered.

Open Hardware people want to know why.

If I'm building a circuit that calls for TL071 op amps, but only have LM258s in my parts bin, I want to know whether I can swap one part out for the other. What specific features of the TL071 justify its place in the design? Do we need that high JFET input impedance or the gain-bandwidth product, or is it wired as a comparator that would be better replaced with an LM339?

There are no Correct answers in engineering. There are requirements of varying importance, and there are tradeoffs between different ways to satisfy those requirements. Just telling me which chip to use doesn't give me any useful information about either one.

As designers, we need to document the reasons behind our choices. As design users, we need to get used to demanding to know the reasons behind design choices. As a community, we need to help each other do both.

Suggestion 5: Accept the fact that Open Hardware has different standards.

A mature Open Hardware design is one that allows you to spend six months and a few hundred dollars worth of basic components to reimplement a $5 chip with a circuit the size of a dinner table.

That makes no sense in commercial terms, but we aren't doing this to be measured by the standards of commercial success. We're in this for knowledge and power over our technology, and the person capable of building the dinner-table version of a chip has both.

We already agree that things like Steve Chamberlin's Big Mess O' Wires homebrew CPU are cool. Jeri Ellsworth is famous for having built a Commodore-64 emulator, and more recently for having fabbed a transistor in her own home lab.

NUSPI society sees these things as curiosities and wasted effort. Interesting, yes, but ultimately the work of someone with WAY too much time on their hands.

We need to recognize projects like that as examples of what we're trying to do, and as models for the kinds of choices we want to include in our own designs. We also need to be able to explain -- clearly -- why we choose to swim against the NUSPI current.