New Architectures for COM Modules

ARM-Based COM Modules? Let’s Take a Step Back and Look at This

There is a movement underway to create standard COM-type modules based on the ARM processor, waking expectations of the kinds of scenarios associated with x86-based COM Express boards. Things are, however, looking to be somewhat more complicated given the nature of the ARM ecosystem.


  • Page 1 of 1
    Bookmark and Share

Article Media

By now most people in this industry have become aware of a new trend in the form of ARM-based small form factor modules that are beginning to appear from a number of vendors. While ARM, along with major architectures like MIPS and the Power architecture, has been a major player in the embedded world for years, with ARM playing by far the major role, it is still significant that a non-x86 architecture is beginning to appear in what are by some being called COM modules. Other appearances to date have also been on previously x86-based Qseven boards, and we can expect more variants in the near future such as, perhaps, Mini-ITX SBCs and the like.

There are arguments to be made that any of these three other architectures are technically more appropriate to embedded systems than the x86. Indeed, they are widely used in many embedded designs that are not based on a small form factor board—let alone a standard board—but more often where the processor is simply designed into the target system on a board along with other components such as memory and system peripherals. So the question arises, “Why is this happening now?”

For years we have known that the economics of the PC market have tended to drive the embedded market, particularly the x86 segment. Technologies like ISA, PCI, PCI Express and USB garnered such widespread use and hence cost reduction in the PC world that they were adapted in the x86 embedded space. Software and development tools, often with enhancements for things like timing analysis, were easily adapted to the needs of embedded. The raw increase in processor speed has reduced the concerns about interrupt latency to a much smaller percentage of applications than before.

The focus of attention in a great many systems today is no longer simply on raw performance but power consumption and heat dissipation for small mobile devices. It is here that ARM has a clear advantage over even the lowest-powered Atom processor. But there is something else at work too. It’s almost a parallel phenomenon to the PC world that helped drive the acceptance of x86 in embedded, and that is ARM’s conquest of the tablet universe. ARM processors almost completely dominate tablet designs, and outside of the iPad, the most widely used operating system is Android. However, tablets, of course, are not built using ARM-based COM modules and so this analogy is far from perfect.

It would appear that the advantage that COM brings to the x86 world will be difficult to transfer to the ARM arena—and may not even be desirable. x86 implementations come from a very limited number of sources and to date have not had a wide variety of on-chip peripherals. This is not the case with ARM, whose licensees have implemented a vast variety of designs with different mixes of peripherals and even widely different graphics coprocessors, power management schemes and more. The application software that you spent so many resources to develop for one ARM implementation is very unlikely to work unchanged with another ARM-based COM module that you plug in.

Then there is the small matter of economics. One of the proposed COM modules is specified at 82 mm x 50 mm, which will be just a little over 6 square inches in area and have a 314-pin MXM 3.0 connector (Figure 1). This is starting to look like the basis for a very nice development kit, but for an end design? Given the difficulty of getting the same code to run on a different CPU, there will be less expectation of updating systems by substituting new CPU modules. What then is keeping the OEM from buying several such modules for the development team but also leaving enough space on the final board design to accommodate the processor and memory? Rather than purchasing high volumes of COM modules with their relatively costly connectors, he can simply bulk order processors directly from the semiconductor vendor and build them right onto the target board.

Figure 1
One of the proposed form factors for an ARM-based COM module is a little over 6 inches in area and uses a 314-pin edge connector.

With the advent of this ARM-based world for small form factor modules there are still many questions—and be it noted—they are questions and not pronouncements. There may be answers forthcoming. However, answers often come only after the questions are asked. Another question concerns support. Most x86 vendors offer various levels of software support including a selection of operating systems, drivers and board support packages to help the OEM get rapidly up and running to add their unique application value.

They can do this because there is an ecosystem of mature x86 software tools and operating systems out there—as there most definitely is for ARM as well. This might be an even playing field if it were simply generic x86 vs. “generic” ARM. However, one of ARM’s major attractions is that it is not “generic.” Where in the x86 world there is a trend toward putting certain functions such as graphics on-chip, there is also a definite interface between the CPU and peripherals; in the latest versions this is the hub chip.

One of the major selling points of ARM is the fact that it approaches characteristics of an SoC with on-chip peripherals targeted at a specific application area. Support for a given COM module necessarily would involve support for that module’s on-chip peripherals. Support for an x86-based COM module need not deal with the specific peripherals, which are on the custom base board. Thus any vendor offering ARM-based COM modules will need to offer not only the operating system, the relatively easy part, but also the specific peripheral drivers.

Now that won’t be that difficult either as long as the variety of COM modules being offered is relatively small. What is not yet clear is how these offerings are going to expand and develop. Will there be a greater selection of specific ARM implementations, or will there be relatively generic offerings? There seem to be at least some plans for the former given the high pin count on the proposed connector. Since different vendors produce different implementations built around a solid ARM core such as the Cortex A-9, each vendor’s chip is going to have a different pin-out.

Thus for each chip chosen for one of these modules there will have to be a specific board layout, but one that also leads specific signals to agreed-upon pins on the 314-pin MXM 3.0 connector—or in the case of Qseven, a 230-pin connector. For each unique set of signals, additional previously undefined pins will have to be assigned in addition to unique sets of traces for different vendors’ offerings. This could rapidly get very complicated and conceivably use up the available pin count on the connector. Conversely, offering only a limited selection of processor implementations on COM modules will work against one of the main advantages of using an implementation of ARM. Of course, the power consumption advantage will remain in any event.

Then there are the designs of ARM-based SBCs, such as perhaps a Mini-ITX or Pico-ITX module (Figure 2). Here the question again arises as to what advantage that offers besides the doubtless attractive power consumption feature. SBCs such as Mini-ITX come with various mixtures of PC interfaces such as USB, DisplayPort, Ethernet, etc. Now the question arises as to whether unique signals will be added to what had been a fairly standard PC-type form factor.

Figure 2
ARM-based SBCs, such as this Pico-ITX module, can be designed to support ARM processors and offer standard PC (plus other?) interfaces.

Will such designs be appropriate for the recent Microsoft port of Windows to ARM? Will they be offered with Android as well as with several well-known RTOSs? All of these possibilities are much more straightforward than would be the case with COM modules because all the on-chip peripherals are at the same time onboard peripherals, so a complete platform could be offered ready for the application developer. Here again, however, the gain is in power and heat savings, but one does sacrifice the size advantage with even the smallest SBC form factor.

So it is beginning to look like the small form factor module, which was a natural for the x86, is less of an easy fit that can accommodate ARM while preserving all the advantages it offers. In addition to power and heat savings, the big attraction is a processor that can be selected that is itself very close to the needs of the application and that can fit into a very small space on a compact board for low-power mobile applications.

Still, we are already witnessing strong efforts to bring Android into a more generally applicable form for embedded devices. Android is closely associated with ARM, although ports to other architectures are starting to appear. It is extremely likely that ARM and Android will occupy an important space in this arena. Whether that will include ARM implementations on standard form factor modules is at this point less certain.