For novel ideas about building embedded systems (both hardware and firmware), join the 40,000+ engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.
By Jack Ganssle
Software is Cheap
Firmware is the most expensive thing in the universe.
In his book "Augustine's Laws," Norman Augustine, former Lockheed Martin CEO, tells a revealing story about a problem encountered by the defense community. A high performance fighter aircraft is a delicate balance of conflicting needs: fuel range vs. performance. Speed vs. weight. It seems that by the late 70s fighters were at about as heavy as they'd ever be. Contractors, always pursuing larger profits, looked in vain for something they could add that cost a lot, but which weighed nothing.
The answer: firmware. Infinite cost, zero mass. Avionics now accounts for more than half of a fighter's cost. That's a chunk of change when you consider the latest American fighter, the F-22, costs a cool $257m a pop. Augustine practically chortles with glee when he relates this story.
But why is software so expensive? Tom DeMarco once answered this question with these three words: compared to what? He went on to discuss relatively boring business cases, but that answer has resonated in my mind for years.
Compared to what? With software we routinely create product behaviors of unprecedented complexity. Sure, the code's expensive. But never in the history of civilization has anyone built anything so intricate.
Consider the following bubble sort, lifted shamelessly from Wikipedia and not checked for accuracy:
void bubblesort(int * A, int n) for(int i(0); i < n; ++i) for(int j(0); j < n - i - 1; ++j) if(A[j] > A[j + 1]) std::swap(A[j], A[j + 1]); }
It's a mere 110 non-space characters, perhaps tossed off in an hour or two. Suppose we didn't have software and had to implement a sort using some other strategy. What would it cost?
A mechanical engineer might boast that his profession built sorters long before computers. Consider IBM's 1949-era model 82 card sorter (http://www.columbia.edu/acis/history/sorter.html) with a throughput of 650 cards per minute, rather less than our code snippet might manage even on a 4 MHz Z80. The model 82, of course, only sorted one column of a card at a time; to completely sort a deck could take dozens of passes.
How long did it take to design and build this beast? Years, no doubt. And its functionality pales compared to our code which is so much faster and which can handle gigantic datasets.
But that was 1949. How long would it take to build a bubble sort from electronic components - without FPGAs and VHDL, today's software-like solution to hardware problems?
Every time I start to sketch out a circuit I'm sorely tempted to plop in a CPU. It's the natural solution, but breaks the rules of this game.
In an hour I managed a rough block diagram, one above the chip level (blocks have names like "adder," "16 bit latch" and the like). But the sequencing logic is clearly pretty messy so I've just tossed in a PLD, assuming at some point it wouldn't be too hard to write the appropriate equations. And, yes, perhaps that breaks the no-programmable-logic rule, but to design and debug all that logic using gates in any reasonable amount of time is as unlikely as buck-a-gallon gas.
Assuming 16 bit words and addresses, the circuit will need around a dozen 16 bit latches, adders, and the like. Plus memory. And I have no idea how the unsorted data arrives into the RAM or how the results get exported. Those are unspecified design requirements. The software-only solution naturally resolves these requirements just by the act of writing the function prototype.
Translating the rough block diagram to a schematic might take a day. Then there's the time to design and produce a PCB, order and load parts (and change the design to deal with the unexpected but inevitable end-of-life issues), and then of course make the circuit work. We could be talking weeks of effort and a lot of money for the board, parts and appropriate test equipment.
All this to replace 7 little lines of code. Few real embedded programs are less than 10,000; many exceed a million. How much hardware and how much engineering would be needed to replace a real, super-sized computer program?
Firmware is the most expensive thing in the universe, but only because of the unimaginable complexity of the problems it solves. But it's vastly cheaper than any alternative. So when your boss irritably asks why the software takes so long, you know what to say.
Compared to what?