Design Article
ARM vs incumbent microprocessor architectures
Robert Cravotta, Embedded Insights Inc
11/13/2012 10:09 AM EST
Parts one, two, and three of this series offer a brief overview of the processor architecture ecosystem, identify and map the processing sweet-spot spectrum of mainstream processing architectures, and cover the issues addressed by low-power, small-data-width processors. This part discusses how incumbent microprocessor architectures can compete with ARM-based processors.
The explosion of ARM-based processors contained in mobile devices has caused some people to ask whether ARM will displace other microprocessor architectures in other markets. The incumbent microprocessor architectures, however, have a secret weapon that is analogous to the 8-bit microcontrollers: domain knowledge that is embedded in the architecture and ecosystem of the incumbent architecture.
Consider that specific variants of a microprocessor architecture will include features—developed, tested, and refined over the years—that make those variants especially well suited to the target application’s specific requirements. Also consider the body of software that serves the given market. A strong incumbent microprocessor architecture, much like the 8-bit microcontrollers, is surrounded by a strong and mature ecosystem of developers, tools, operating systems, and middleware that provides a buffer for the incumbent to respond to a challenger.
A specific example of incumbent advantage can be seen in the current battle to determine which microprocessor architecture will ultimately own the tablet space. The ARM architecture currently has the apparent incumbent advantage because many tablet designs treat the device as a large smartphone, and the ARM architecture has many man-years of design knowledge tied up in the hardware and software to support the smartphone market. If the tablet space stays anchored to the smartphone model, the ARM architecture is well positioned. There are tablet products based on other microprocessors, however, that may define tablets differently. For example, if Microsoft can redefine the tablet market to leverage the ecosystem for its Windows OS, the market could be completely different from today’s tablet market.
By some estimates, vendors have introduced more than 200 processor architectures over the past few decades. Most of those have disappeared or have been absorbed into other architectures. The few dozen architectures that currently provide developers with the tools and means to create today’s applications encompass complex ecosystems of processors and development tools, along with domain-specific engineering and software support. Would the developer market be better served if there were even fewer architectures from which to choose?
The massive churn in the processor market is a testament to the complexity and difficulty of figuring out the correct way to serve that market. The uncertainty is not an artifact of the past but remains very much a part of today’s technology. One indicator of that uncertainty is the lingering question of whether 8-bit is dead.
I have recently learned that some companies are quietly exploring ways to increase raw processing performance significantly by reducing the data word size in certain DSP applications. Part of the challenge is determining an acceptable trade-off between the problems that the short word size might introduce and the benefits of the resultant higher performance at lower power. There are some DSPs available today that support 8×8 MACs (multiply-accumulates) within a larger execution engine. In short, is an 8-bit DSP in our future? You never know from what direction the next best idea will come. If we had fewer processor architectures to choose from, there would be fewer opportunities for crazy ideas like an 8-bit DSP to bubble up.
Many commenters argue that if we had fewer architectural choices, software code would be easier to maintain because a larger base of developers would be able to access, use, and maintain it. Would a common architectural base improve the transferability of existing domain expertise and, more important, the development of new domain expertise?
Based on what I see large semiconductor companies doing, I suspect fewer architectural choices would lead to slower innovation because there would be only enough resources within the development support ecosystem to address the engineering issues of the largest volume applications. That could negatively affect efforts toward discovering emergent applications that would otherwise replace the current large-volume applications.
Like the different races of Middle-earth, each available processor architecture encompasses its own unique domain culture or development ecosystem that enables it to be the best at performing some tasks better than the alternatives. Most designs already use multiple processors, and the wide variety of processor offerings lets developers pick and use bestin- class devices and software in their designs. The successful rise of a single architecture to rule them all may be the key to opening up developer productivity—but it could also become a shackle that enforces conformity and limits the direction and opportunity for disrupting innovation.
Be careful what you wish for; you might get it.
Author’s biography
Robert Cravotta is principal analyst and cofounder at Embedded Insights. He covered embedded processors as a technical editor at EDN, and before that he worked in the aerospace industry on electronics and controls for pathfinding projects such as fully autonomous vehicles, space and aircraft power management systems, and space-shuttle payloads, as well as building automation systems. He received a master’s degree in engineering management from California State University Northridge and a bachelor’s degree in computer-science engineering from the University of California, Los Angeles.
Also see:



ajfengr
11/14/2012 3:04 PM EST
With the advent of good C compilers and CPUs with enough power to program that way, the actual CPU choice has become less and less important. For example, one of my employer's customers has stated that all their embedded development must be in C and be as much as possible non-processor specific. As a result, the actual CPU decision is not made by engineering, but by the accounting department as they check latest prices for purchases! The code would work on any of several CPUs.
If there is a push to consolidate into a single CPU architecture for embedded design, that push is NOT based on technical merits. Instead it's based on ARM's desire to maximize volumes with their exorbitant license fees.
We're seeing pressure to jam 8-bit designs into 32-bit CPUs, for non-technical reasons. Honestly, the 4 and 8-bit embedded designs persisted for much longer than anybody thought they would. Why the sudden need to jump to 32 bits?
As it turns out the problem is marketing, not technical. We have some very capable embedded 16-bit CPUs in production these days from vendors such as Renesas, TI and Microchip. However, there are NO capable embedded 16-bit CPUs available on the open IP market. This is the reason for the 32-bit push. ARM sees the market gap with 16-bit CPU IP, but instead of actually filling that gap, they try to scale down their offering and tell people it's what we must use. But check those per-piece royalty charges!
We need reasonable 16-bit CPUs in the IP market, with supported C compilers and IDEs.
Sign in to Reply
Stephen.Evanczuk
11/14/2012 7:43 PM EST
Good points. I hope accounting has at least a list of candidate processors. I know there was a point years back where it looked like processor selection wasn't going to matter because it would all get evened out in software, but that didn't hold up at the time.
I wonder, are you dealing with real-time applications or designs with tight power budgets? I would think a case could be made back to the customer that not all processors are created equal when it comes to things like deterministic performance and system-level power optimization.
Sign in to Reply
ajfengr
11/14/2012 9:06 PM EST
I do have some of the issues you talk about. I agree, CPUs are not blindly interchangeable. In the case I mentioned, the customer was actually buying his own CPUs from other sources and just telling us why he was unimpressed with the mixed-signal embedded CPU chip we were offering which had no C compiler :D
Perhaps I was rambling, but one of the points I tried to make is there's no magic about the ARM architecture which I feel is being forced on us all. It's just another good design that meets some particular combinations of speed, cost and power consumption.
Sign in to Reply
shikantaza
11/15/2012 4:29 PM EST
I go back to the days when a 360/91KK with 4 MBytes of core was one of the largest computers in the world. I've also designed a WIDE range of gizmos.
Three additional issues underlying the selection of a processor: 1) power 2) programmers don't want to write low-level ("on-the-iron") code, and 3) 16-bit architectures, while capable, don't (can't?) provide the substrate for just any ol' embedded app.
1) Power - got an AC cord? Yes? by all means, drop a 32-bitter into the socket, but pay freight for support devices. If SWEPT (Size, Weight, Efficiency, Power, Throughput) isn't an issue, great. If the system has a battery, and it's hard to change, well, that changes the entire complexion of the problem.
2) Low level code. It's a pain. I worked with (ahem) a major aerospace firm on a serious number-crunching architecture that did go to silicon. SWEPT was the key metric of the program, with ops/Watt most important. We brought a RISC architecture to the party; their DSP IP was ALL integer. They also had people who could do the numerology to avoid arithmetic over/under-flows. As their work force turned over, the new generation wanted lotsa memory with floating-point and a cushy OS. Bloat.
3) As a former MSP430 user, I agree that a 16-bit processor can do a lot of work. I just got tired of trying to build AA-powered real-time apps - we never felt safe about whether the processor waking from a serious snooze to service an interrupt. Perhaps a faster CPU would help, but limited memory space and slow context-switching really made it tough. (Funky low-power wireless links didn't help much, either.) Given the processes we had to control, it was tough to satisfy control-loop requirements and stay on budget with power.
I'm sure these issues can be overcome, but they represent a pretty solid challenge to the 16-bit industry - some architectural innovation is needed.
Sign in to Reply
ajfengr
11/16/2012 3:58 PM EST
Hey old-timer! Yes, I learned programming on a 360 with 32K of core and no floating point unit (had to write my own square root for use in my school project). :D I agree that compared to yourself and some others here, my embedded projects are much smaller. 32 bits makes more sense for many, but not always ARM.
Sign in to Reply
przemek
11/21/2012 3:43 PM EST
You can certainly find ARM microcontrollers that do not carry an exorbitant price: NXP LPC800 Cortex M0 costs 39 cents a piece.
Sign in to Reply