Atom and Eden Have No Place in ARM’s Garden


  • Page 1 of 1
    Bookmark and Share

As we complete the embedded trade show trifecta with Computex in early June in Taiwan (along with ESC Silicon Valley in April and Embedded World Germany in February), it’s time for board vendors to begin the mad scramble to position their new Eden-Isaiah or Atom-based small form factor SBCs and COM modules. With all of the hubbub over ultra mobility and the strange comparisons we’ve already seen to RISC architectures, it’s time to set the record straight.

Last month, we discussed the mobility initiatives of Intel and VIA, and the outstanding benefits (except the lack of legacy buses) for the small form factor embedded community. The x86 domain is now entitled to be on the same playing field as RISC architectures. But the x86 architecture is like an expansion team–full of former and yet-to-be stars–much potential and a long road to travel. And whoever decided to compare Atom to ARM has been living in x86 fairyland too long. The notion that someone using an ARM-based SoC would suddenly start using Atom or Eden-Isaiah might be absurd even to Dilbert’s pointy-haired boss.

RISC processors and cores such as ARM achieve small die sizes, low cost and low power consumption (DMIPS/Watt) by reducing and simplifying the instruction set and addressing modes compared to CISC (complex instruction set computers) machines such as x86. Small RISC cores mean that more functions can be included in the processor silicon, reducing chip count and perhaps even pin count as I/O devices are connected internally. Hence the processor chip itself can be smaller and the “chipset” device eliminated entirely. This approach yields the smallest possible PCB size as proven by dozens of PDAs, MP3 players and cell phones.

Make no mistake. A two-chip solution is quite an accomplishment for high-performance x86 offerings, and a standing ovation is well earned. But x86 devices are application processors and exist to run a large installed base of legacy applications and operating systems such as Windows and Linux with significant user interface/display requirements. While some x86 boards are used in headless 32-bit control applications, they generally consume much more power and cost more than RISC solutions.

The ARM architecture is commonly associated with millions of cell phones. Besides basic boot and control functions, ARM SoCs have evolved to take on more of the heavy lifting of user interface, color LCD and streaming functions, and a wealth of software and middleware libraries now exist. But this should not be confused with application processor glory like PC-derived x86 processors.

In addition, RISC chips are rightfully used widely in deterministic and hard-real-time (deadline-driven) applications, including automotive, robotics and telecom/datacom. These control applications have minimal UI/display requirements but urgent needs for prompt, efficient I/O processing. Packets dropped (information lost) by desktop-style processors/operating systems that take milliseconds or seconds to service high-priority system tasks can send the application off into the weeds. And Ctrl-Alt-Del is not available under a car seat or in an Internet backbone router.

Here’s the punch line. “Atom versus ARM” gives us entertaining reading, but most folks in our business are savvy enough to know that desktop/notebook/mobility processors and RISC processors get used in different types of devices, each where they are best suited. Requirements are driven by OS or application compatibility, real-time performance, cost and/or power. That said, the Darwin Award is available to the poor misguided engineer who falls for the marketing hype and puts an MID/UMPC processor/chipset in his or her router or robot design.

So opportunities exist for small form factor boards with both RISC and x86 CPUs. For RISC processors, this is old hat. For x86 CPUs, this is truly a new world. Next, we’ll delve into some options on how a small form factor CPU is implemented, either as a single board computer or Computer On Module–an issue that applies regardless of whether a RISC or x86 processor is on board. We welcome your feedback and suggestions for future topics at