Each year Embedded Systems Programming conducts a large-scale survey of embedded systems developers around the world. Starting with this issue we'll be publishing the results of the survey in installments. This month's installment reveals how engineers, programmers, developers, and managers choose a microprocessor. In future issues we'll cover some surprising data about operating systems, popular vendors, programming languages, schedules, budgets, and more.
Silicon chips are more valuable than gold. The Pentium 4 processor die is worth about $100 per gram versus about $10/gram for pure gold. Like many microprocessors, that one chip contains millions upon millions of transistors. About 60 million new semiconductor transistors were manufactured in 2004 for every man, woman, and child living on the planet. That's in addition to all the transistors made the year before, and the year before that. Yet microprocessors make up only about 2% of all the different types of semiconductors made.
That tiny 2% unit volume, though, accounts for about one-third of all the money in the semiconductor business. That's what an MBA would call some serious financial leverage. Making microprocessors is (or at least, can be) an extremely profitable venture. It's no wonder that so many companies produce everything from 4-bit to 64-bit processors for every kind of embedded application. (By the way, PCs are an almost insignificant part of the microprocessor universe. They account for just over 2% of all the microprocessor chips sold, or just 0.04% of semiconductor unit volume. Pentium shipments are, in a sense, a rounding error.)
It's no wonder then that competition among embedded microprocessor vendors is so fierce. Today well over 100 different embedded processors are for sale—and that's just counting the 32-bit chips. How's a poor, overworked engineering manager to choose the best processor? How could someone even evaluate all the choices? To answer these questions and almost a hundred others, we did the empirical thing. We asked them.
Selecting a microprocessor
We surveyed a mix of programmers and hardware engineers, including engineering managers, systems architects, and technical executives. All are involved in embedded development, whether it be in the telecommunications, automotive, consumer, wireless, defense, industrial, or automation sectors. In general, only PC developers were excluded, because they choose their processors for entirely different reasons.
Figure 1: Who influenced the choice of processor and by how much?
One of the first questions we asked our survey group was who influenced the choice of processor they use now? As Figure 1 shows, plenty of people get to vote on the processor. Choosing the right microprocessor isn't like choosing the right resistor, LED, or power supply for your product; with processors, everyone wants to get involved. Not surprisingly, the lead engineer or engineering manager had the greatest influence in most organizations, with 60% of the respondents saying this person had a “great influence” over the choice of processor, and almost another 30% granting this person “some influence.” That leaves just over 10% of the organizations where the lead hardware engineer had “no influence” over the choice of processor.
If the lead hardware developer isn't choosing the processor, who is? Mostly, it's the hardware engineering staff. The breakdown of responses for this category closely mirrors those in the previous response. Clearly, the chief or the chief's direct reports are making the call most of the time. The more enlightened groups involve the whole engineering staff, including software, production, and test personnel. About 38% of our respondents said the entire development staff directed the choice of processor, with another 38% claiming the staff had at least some influence.
After these top three responses the numbers drop sharply. Upper management exerted their strong influence in only 12% of the cases we polled, although another 28% admitted that management had some influence on the decision. When asked about outside influences (such as customer requests or regulatory bodies) only 9% responded that these groups had strong influence, while 25% said they had some influence.
Thankfully for most engineers, the marketing and purchasing departments had very little to say on the choice of processor. Even so, these two groups garnered single-digit percentages. Some engineers told us that some “customers”—such as a system integrator—may have strong feelings about the product's CPU chip. Likewise, the purchasing department may exert some influence on the choice of processor in order to maintain its list of preferred providers. Throwing the doors open to all possible vendors isn't an option for many firms, according to our survey.
How many processors?
Multiprocessing systems were once the domain of high-end research labs. Now they're as common as snowflakes. Our survey asked developers how many processors are in the system they're designing right now. As Figure 2 shows, the average seemed far from average.
Figure 2: The number of processors our respondents use in the systems they are designing
Barely half (52.4%) said they're using only a single processor in their current project. That's slightly higher than we've seen in previous years; the trend is clearly upward. By this time next year we predict the average will tip over and show more multiprocessor systems than single-processor systems.
Of the 48% who are designing or programming multiprocessor systems, how many processors do they have? Not surprisingly, dual-processor systems are the next most-common arrangement, with the averages declining after that. Surprisingly, more than 100 developers said they are currently working on systems with more than 10 processors. That kind of configuration sets up enormous challenges for both the hardware and software teams.
To get an idea of how complex these systems might be, we also asked the multiprocessor developers whether all their processors were the same (a homogeneous architecture) or whether they were different (a heterogeneous configuration). As Figure 3 shows, a strong majority answered that they're using multiple different processor chips. A much smaller percentage (about 5%) said they're integrating different processor “cores” into a single chip. Nevertheless, that's over 60% of developers working with a multiprocessor mix.
Figure 3: Out of multiprocessor developers, the percentage who use hetero- and homogeneous architectures on their processors
Among the chip-level designers, there was a stronger trend toward keeping the processors all the same, as opposed to board-level designers who tend to mix processors. That's probably driven in part by cost. Each processor core costs money and may bear a royalty; licensing multiple different cores for the same chip racks up both nonrecurring-engineering costs and unit costs. Mixing processor bus interfaces on a single chip is also harder to do than it is on a board-level or system-level product where the processors may communicate only occasionally. Processors in close quarters need to communicate amongst themselves (else why integrate them onto a single chip?) so it's more likely they'd share a similar architecture and bus.
The rise of the 32-bitters
Although we didn't select or filter respondents based on system type or industry when reviewing this specific data, a clear preference appeared across industry lines for 32-bit processors. Overwhelmingly, developers said they were using a 32-bit processor (or, in the case of multiprocessor systems, that the main processor was a 32-bitter). This seems surprisingly lopsided considering that 8-bit chips outsell 32-bit processors by a few orders of magnitude. However, in those multiprocessing systems, the 8-bit chips are likely the subordinate processors, with one or more 32-bit chips running the show.
Figure 4: Percentage of processor bit sizes that our respondents are using
Figure 4 breaks down the developers by “bittedness.” The 32-bit users easily outscored all the others put together, with 4-bit designers coming in at less then one-half of one percent. Eight-bit and 16-bit users ranked about the same at around 17% each. The number of 64-bit users came in a little above 5% (this number is growing year by year), and the troubling “I don't know” faction made up nearly 3% of the total. The category for 10-, 12-, and 14-bit processors—clearly the Microchip contingent—got a 1.5% share, but these users often identify their processors as 16-bitters, so this total is probably low.
If we cross-tabulate the multiprocessor users against the 32-bit users, we find there's a correlation. The preponderance of 32-bit processors drops among single-processor developers, to about 48%, an 8% decline versus multiprocessor developers using 32-bit chips. Usage of 64-bit processors drops a lot, by about half. The lost share is made up in the 8-bit and 16-bit categories, both of which grow by about one-quarter of their previous shares. So high-end developers aren't using high-end chips to replace smaller processors, they're using them in conjunction with smaller processors. Systems based on 8-bit or 16-bit processors, in contrast, are more likely to be single-processor systems.
Fast enough to do the job
Starting with an easy question, “how fast is your processor?” produces some surprising results. Looking at the totals in Figure 5 it appears most processors are running at less than 100MHz. Given the prevalence of 32-bit processors among developers, that's a bit surprising. Why use such a high-end processor if you're going to run it so slowly?
Figure 5: Speed of our respondents' microprocessors
Actually, the mean clock frequency was a healthy 337MHz, although the 10 to 99MHz category got the most responses. The higher frequencies were scattered, so to speak, with another peak at the 1-GHz level. In fact, more than 180 developers said their processor was running somewhere north of 1GHz. (Alas, more than 80 said, “I don't know.”) Selecting for just the 32-bit and 64-bit users, we see clock speeds level out with an almost even distribution across all the frequency ranges. Each speed range in our survey got about 20% of the response among 32-bit users; the only weak responses were at the very low end (under 10MHz) and at the 750 to 999MHz range.
Among 8-bit users, almost all the clock rates were below 100MHz, naturally, with about one-third falling below the 10-MHz line. A scant 4% made it above 100MHz with one optimistic engineer reportedly using a
1-GHz 8-bit processor. The 16-bit average was higher, with significant numbers using chips above 250MHz.
Users surprisingly fickle
When we asked developers if they were using the same processor in this project as in the immediately previous project, half of them said no, they'd switched processors. Even more surprising, half of those switching moved to an entirely different processor family. Tossing out old code, tools, and expertise is a big decision, so we asked why.
First, among those who kept the same processor from one project to the next, they cited four main reasons for staying the course. The desire to maintain software compatibility, to keep existing development tools, and to make use of existing expertise were all strong reasons, along with an overall happiness with their current CPU supplier. They simply had no reason to switch. A few said the financial cost of switching processors was too high, or that it would be too time-consuming, or that no other suitable processor was available, but for the most part developers were happy with their current chip.
Well, half of them were. The other half switched processors for a variety of reasons. Chief among them were the lure of processors with better features (49%), faster clock rates (36%), better roadmaps for future expansion (31%), or ones with better development tools (24%). More than 140 developers said they'd switched because their old chip was no longer available and dozens of others said it was because their old chip was too expensive. Sadly, more than 150 said it wasn't their choice—the new processor was forced on them by some outside influence. In fact, that ranked as a fifth most-common reason for switching processors overall.
Software sells the processor
On to the Big Question. When choosing a processor, what's important? What criteria do developers evaluate and what features are unimportant? Here at Embedded Systems Programming we had our own preconceived notions about how the Five Ps—price, performance, power, peripherals, and pinout—would rank.
And the answer is … none of the above. As Figure 6 shows, none of those parameters was ranked first. In fact, some didn't make the top five. Developers overwhelmingly voted for the chip's software-development tools as the most important thing when evaluating a new embedded processor. The most valuable feature of a chip isn't even the chip itself. Compilers and debuggers trump MIPS and megahertz.
Figure 6: Factors considered most important in choosing a microprocessor
Remember that we're not polling just software developers, either. Our survey pool included electrical engineers, managers, and programmers alike. In fact, only about one-third identified themselves as “a software person.” Even when we filter the data to include only “hardware people,” software-development tools still rank first. (Interestingly, the rankings don't change much, and the absolute numbers change only slightly, when filtering for hardware, software, or system-level people. Maybe we're all more alike than we think.)
In more personal interviews, some developers described their reliance on software tools in terms of the way a carpenter relies on the tools of his trade. Whether they're hand tools or power tools, a carpenter's tools are the thing he touches. You can change the workpiece—swap pine for ash, mahogany for cedar—but the tools remain the same. Likewise, embedded developers' hands touch their development tools, not necessarily the workpiece, or processor, underneath them. Take away those tools and you take away their productivity.
The chart in Figure 6 highlights the criteria that are hardware related, with performance and price ranking second and third, respectively. The next hardware-related characteristic is down in seventh position, peripheral mix. Power consumption—often seen as the hot topic these days—ranks a dismal eighth. In contrast, the availability of operating systems, hardware-development tools, and third-party software rank much higher on developers' shopping lists.
It's not even close. Software-development tools are clearly, categorically, and unequivocally the single most important thing about a processor—any processor. For an established processor vendor like Freescale, Texas Instruments, Intel, or many others that's good news. Age has its benefits and one of them is a large and established selection of compilers, debuggers, operating systems, and third-party software.
For startups creating new processors, that's a serious challenge. The speeds and feeds of the chip itself may not be as important as its architects think. Few customers are qualified to evaluate the stylish nuances of a new CPU architecture, and fewer still seem to care. Like buying automobiles, few customers really weigh up the numbers in the brochure or look under the hood for anything more than a traditional show of interest and feigned competence. How many PC buyers really evaluate the specifications, versus simply buying a brand they recognize at a price they can afford? Back in the VHS-versus-Beta days the details of the VCR were far less important than the availability of taped movies for it. And so it is with microprocessors. The software sells the chip.
Embedded processors are far from generic. There are hundreds of varieties available from dozens of vendors, and the chips really are quite different from one another. They're not interchangeable or transposable, and choosing a processor (or processors) is a significant milestone in any development project. Yet the processor itself—the silicon—isn't the real decision here. It's the ecosystem that comes with the processor that matters. As we'll see in future installments of this survey, developers often choose their tools and/or operating system first, and then shop for a processor that supports them. At its most basic, a processor is a means to an end, a way to get certain software to run. Whether the development team is developing that software itself or acquiring it from outside (another topic we'll cover shortly) it's the software that comes first among embedded systems developers.
Jim Turley is the editor in chief of Embedded Systems Programming magazine and the conference director of the Embedded Systems Conference. You can e-mail him at .