Ounce for ounce, silicon chips are more valuable than gold. A tiny fleck of Intel Core 2 Duo processor silicon sells for hundreds of dollars per gram, versus about $10/gram for pure gold. A single typical microprocessor chip contains millions of transistors, making it one of the most complex things ever devised by humankind. About 100 million transistors are manufactured for every man, woman, and child living on the planet. That’s just in one year, in addition to all the transistors made the previous year, and the year before that, and the year before that. Transistors are probably more plentiful than grains of rice.

Only a small percent of those transistors go into microprocessors. The majority go into DRAMs and other memory chips, analog parts, graphics controllers, peripheral chips, and any number of other components. Yet microprocessors and microcontrollers generate one-third of the revenue for semiconductor vendors. That’s a big profit margin – what an MBA would call financial leverage. At times, making microprocessors has been literally more profitable than printing money (such as when the margin on Intel’s 387 math coprocessor chip exceeded that of the U.S. Treasury printing dollar bills). No wonder so many big chip companies compete in the microprocessor business.

So how does an up-and-coming microprocessor company join this lucrative bandwagon? How do startups enter the market? And most important, how can you get a piece of this action?

The answer is… write software. Lots and lots of software. Then pay people to write some more.

It turns out that designing and building a microprocessor is the easy part. Any second-year engineering student can design a microprocessor, and many have (raise your hand). The hard part is getting people to buy your chip. And that’s getting harder each year.

Ego versus Ergs

Selecting the right microprocessor for an embedded project is a remarkably irrational process for most people. Nearly everyone in the company gets involved. They all have a stake (or think they have a stake) in the choice of microprocessor, so everyone from the CEO to the mail clerk wants a vote. Processors generate strong opinions in a way that DRAMs and diodes don’t. What should be an objective analysis of price, performance, power, peripherals, and pinout (the “five P’s”) turns into a referendum on processor architecture, brand reputation, experience, and gut feel.

Surveys have shown that the lead engineer influences the choice of processor only about two-thirds of the time. His or her staff often weight in, but in about 10 percent of cases neither the hardware manager nor the staff had any say in the matter at all; it was determined by upper management, the marketing department, or even the purchasing department.

Even when engineers make the decisions, they usually don’t pick the fastest chip, nor the cheapest or the most power-efficient. Data sheet specifications go by the wayside when processors are involved. Most developers prefer to stick with the chip they used on a previous project because they’re already familiar with it. (For the same reason, some prefer not to use the same processor.) But experience is subjective and has nothing to do with suitability to the task, price/performance ratios, furlongs/fortnight, or any other objective measure. Besides, different engineers on the same team probably have experience with difference processors. Who wins?

Increasingly, the winning chip is the one with the most software. Compilers win out over computation; debuggers defeat Dhrystones; binaries beat benchmarks. As a rule, embedded developers will choose the processor with the broadest supply of operating systems, kernels, development tools, middleware, and third-party support. The hardware features are secondary to the software repertoire.

Free software is even better. Silicon vendors are expected to provide drivers, middleware, and sometimes even operating systems with their chips. Developers are looking for as much ready-made software as possible because it reduces the amount of code they have to write. Ideally, the chipmaker would hand over the processor with all the application code already loaded and tied up with a nice bow, but we’re not there yet.

The more software, the better. Because development teams often choose their operating system, RTOS, or kernel first and their processor afterwards, the choice of processor is often dictated by the available software ports, not the other way around. If Brand X processor doesn’t run Brand Y operating system, it’s out of the running.

Even more important than operating systems are development tools. There are precious few hardware features compelling enough to make a programmer give up his favorite compiler, debugger, or IDE. Loyalty to development tools runs high, and woe betide the chip vendor who doesn’t support the customer’s preferred tools. Switching processor architectures is relatively easy; switching IDEs requires a near-religious conversion.

How Not to Succeed

Some years ago, a good bar bet would have been to ask the engineer next to you to name the world’s best-selling RISC processor. It wasn’t PowerPC or MIPS or even ARM. It was AMD’s 29000 family and it was hugely popular in printers, network boxes, and nearly everything else. AMD was finally giving Intel a run for its money, and 29K chips were flying off the shelves.

That is, until AMD canceled the entire product line and reassigned the engineering and marketing staff. What happened? Why would you kill off a whole family of chips at the height of their success?

Because they were losing money– that’s why. As popular as the 29K family was, AMD was spending all the profits, and then some, on software. The 29K architecture was still fairly new, and it didn’t have the established software base of Intel’s x86 or the 68000 family from Motorola (now Freescale). Few programmers had much experience with the 29K and even fewer software companies were ready to risk developing 29K ports of their tools, operating systems, or applications. Consequently, AMD was plowing its development budget into software subsidies to keep the third-party software flowing. The software overhead sunk the hardware.

Even now, new microprocessor startups fail every few months because they never develop the “critical mass” of software necessary to entice programmers away from their current chip. Designing the processor is the easy part. Even making chips is comparatively straightforward. But building a healthy base of software for your new jewel takes a very long time… and lots of money.

The lesson for startups is: forget the arcane hardware details and concentrate on the software, particularly the development tools. Few customers are qualified to evaluate the stylish nuances of a new CPU architecture anyway, and fewer still will care. Like buying a new car, customers rarely look under the hood for anything more than a show of feigned competence. The silicon isn’t the real decision here. It’s the software ecosystem that comes with the processor that matters.