Power and Integration—ARM Making More Inroads into More Designs
Page 1 of 1
It’s about power—low power; almost no power. A huge and burgeoning market is opening for devices that are handheld and mobile, have rich graphics, deliver 32-bit multicore compute power, include Wi-Fi, web and often 4G connectivity, and that can last up to ten hours on a battery charge. The most obvious among these are smartphones and tablets, but there is also an increasing number of industrial and military devices that fall into this category. Increasingly the choice for such applications is turning out to be an ARM-based processor.
The rivalry between ARM and Intel in this arena is predictably intense because try as it will, Intel has not been able to bring the power consumption of its Atom CPUs down to the level of ARM-based designs. With Atom running in the 1 to 4 watt range and a single ARM Cortex-A9 core in the 250 mW range—to which must be added the consumption of on-chip peripherals along with a second core—the gap in power consumption is still pretty wide. In addition, one needs to add to the Atom design the peripheral controller hub (PCH) and any off-chip peripheral devices. Despite all this, the choice is far from simple.
Part of it depends on whether you want to build the processor into a custom board or are looking for a module such as a small form factor SBC. In the latter case, Atom-based board modules are available in vast profusion from PC/104 and its variants to COM Express, EPIC, Q7 and more. For ARM-based OEM boards, not so much. On the other hand, an ARM approach falls into the growing trend to move away from SFF board-based designs and put as much functionality as possible onto an IC.
An Atom works well on a COM board, for example, because of its straightforward interface, which can be brought out to a standard connector like a SUMIT or PCIe connector. On the other hand, there is very little among the many ARM implementations that would resemble a standard interface let alone a pinout. Many peripherals that would be accessed on the COM or carrier board in an Atom design are accessed for the ARM on chip by the internal AMBA bus. The external pins are often specific to the on-chip peripherals and these vary among design and manufacturer.
This is not to say that there are not board-level ARM products, but the vendor of such modules has to select a manufacturer and members of that vendor’s ARM family to support on that form factor or arrange for a design and fab with a semiconductor vendor. In any event, the external interfaces on such a board will depend on the interfaces of the processor. Another vendor’s ARM implementation will not work if moved to that board. Despite their differences in power consumption, ARM and Atom appear to be tailored for two different if sometimes overlapping worlds.
It is much more difficult for an ARM processor (pick one out of hundreds) to work on a standard module like COM Express because so much of the functionality associated with ARM resides on-chip and that does not lend itself to the world of standard connectors that interface generic CPU boards to custom carrier cards. By the same token, integrating an Atom into a smartphone appears awkward because—aside from the power consumption—other discrete devices would have to be added to make it all work.
Now having said all this does not mean that these things are not being done successfully from both directions. ARM processors are being offered on SBC modules, and Atom processors are definitely being deeply integrated into a vast number of small devices. Still there are considerations that have made an ARM choice increasingly attractive in a certain set of instances. These appear to be highly integrated small devices that will be produced in a significant volume so as to justify a certain level of NRE expenses such as increased development effort and custom board design.
This has always been important when deciding to go with an ASIC or SoC because of the significant up-front expenses and risks. An ARM processor with a given mix of peripherals is not application-specific per se, but it can be said to be application class-specific. Thus, selecting an ARM approach does make sense for higher volumes, though these need not be nearly as high as those needed to justify an SoC approach.
The availability of devices like ARM and all its variants does reinforce the trend for embedded designs to move from board-level to more IC-level implementations. If the demand for a design increases to a certain point, it can also make sense to go to a full-ASIC implementation. One thing is certain beyond the specific details—higher integration will be the choice as soon as it makes financial sense.