BROWSE BY TECHNOLOGY



RTC SUPPLEMENTS


TECHNOLOGY IN CONTEXT

Stackable vs. COMs: What's the Best Choice?

An Aerial View of COMs vs. SBCs from 30,000 Feet

SBCs and COM products coexist peacefully in a growing off-the-shelf board market where OEM design expertise, design time frames, and design and product costs drive solutions either to the COM side or the SBC side. Making the right choice can be vital to the success of a project.

BOB BURKLE, WINSYSTEMS

  • Page 1 of 1
    Bookmark and Share

Article Media

System designers have several viable options for their embedded computer and I/O board architecture. While technical articles, advertisements and datasheets tend to bury designers with product specifications, few resources exist at a higher level to help select architectural approaches first, with the pros and cons of each. The primary reason is that many vendors understandably favor one type or another based upon their current product offering, or have a particular bias toward their strategic product roadmap. Typical articles begin with a block diagram of the architecture showing off-board interface signals then quickly dive-bomb into a product photo and pitch. But the real question facing designers is “what architecture and form factor should I choose as the embedded computer for my project?” The aim of this article is to give enough useful information to build a high-level project decision framework, prior to committing down a certain path that is costly to change.

The overall project or program management targets for development budget (NRE), recurring production unit cost, schedule/TTM (time-to-market), risk, legacy compatibility (hardware and software reuse), size, weight, and CPU and I/O performance combine to point toward either a backplane/card cage architecture, a full custom single board, or a stack of boards. Regardless of whether a backplane-based card cage or a board stack is used, the system OEM can choose from among the methodologies and architectures shown in Figure 1.

Figure 1
The inverse relationships among the project planning parameters for each design methodology.

The full custom option is so unique that it’s not possible to generalize in any meaningful way here. From Figure 1, even with a proficient hardware, firmware, software, and mechanical/thermal team, it still has the highest NRE, time-to-market and project risks. The third option can be viewed as a cross between the second and fourth, in other words, the SBC is designed to custom requirements rather than a carrier. This option is quite rare in the x86 market due to the vast array of boards on the market from ultra-mobile all the way to server class.

Figure 1
The inverse relationships among the project planning parameters for each design methodology.

Shift toward COTS and Value-Add

Over the years, budget constraints and consideration of core competencies have turned designers toward industry standards. In particular, more and more designs have changed from in-house proprietary RISC and x86 designs to COTS (commercial off-the-shelf) embedded x86-compatible SBCs and COMs.

This shift in design methodology brings well-designed, technologically advanced system components at reasonable prices, complete with device drivers and application software building blocks and tools. The limited resources and time available to develop an embedded system have decreased significantly, approaching 6-12 months or less in many cases. The popularity of embedded PCs lies in the ability of a user to buy off-the-shelf hardware and apply specific “know-how” or “value-add” with I/O and software. The result is a better product developed in a shorter period of time. The I/O is usually the sticking point, leading to a decision between the second (COM+carrier) and fourth (SBC+I/O stack) methodologies of Figure 1.

Figure 1
The inverse relationships among the project planning parameters for each design methodology.

Although most of this article pertains equally to systems that use desktop-compatible expansion cards such as PCI and PCI Express slot cards, the main focus is on small form factor I/O boards in the form of either carrier boards or stackable boards. The Small Form Factor Special Interest Group (SFF-SIG) has standards for both COM and Stackable architectures, and can fulfill the need for a vendor-neutral analysis herein.

When to Use Stackables

For a board stack, common approaches include two-high (processor card plus mezzanine) or greater (“stackable”) architectures. In practice, designers sometimes choose a stackable architecture even with zero or one expansion card at the time of first release to leave the door open for future I/O expansion as the system and market require. Ten years ago, stacks of 5-10 PC/104 I/O cards on top of a PC/104 CPU were common. The enormous amount of integration in the latest processors and chipsets has reduced even legacy-oriented (ISA-based) designs to one- to three-card stacks typically (Figure 2). The legacy PC/104 connector ensures that any single card from 70% of the vast stackable I/O ecosystem plugs right in to round out the needed I/O, whether 16 analog inputs or 32 digital I/O or CAN bus, etc. Multifunction SUMIT-ISM I/O cards add 802.11 Wi-Fi, multiple Gigabit Ethernet ports, GPS receiver and/or serial ports.

Figure 2
WinSystems’ EPIC form factor SBC with PC/104 and SUMIT stackable expansion card.

Stackable SBCs and I/O cards are best used for applications with very standardized types of I/O. This is because of a huge “ecosystem” of I/O modules from many manufacturers, such as serial ports, analog inputs and outputs, digital I/O, CAN bus, 802.11 wireless LAN, Ethernet and video capture (frame grabbers). When the project scope requires quick TTM, the SBC is off-the-shelf, readily available to benchmark application software to develop a demonstration or proof-of-concept. Worst case, rounding out the I/O means designing a simple SUMIT-ISM card, which is much simpler than taking on the power supply, power management and termination of standard I/O that are unintended burdens passed along to the OEM by COM manufacturers. The value of being up-and-running-on-day-one is “priceless.”

Stackable COTS SBCs have a high degree of interoperability with this ecosystem of I/O modules due to the standardized, well proven PC-based buses and interfaces. Even multibus expansion interfaces such as SUMIT pack USB, SPI, I2C, LPC and PCIe into compact 52-pin high-density connectors. I/O cards that use PCIe, USB, SPI, or I2C endpoints (such as SPI A/D parts from Analog Devices) can directly interface to the chipset through the SUMIT connector pair as if directly on the main board, reducing the complexity and risk of having to interface through overkill, costly and electrically noisy bus bridges.

As long as the production volumes are modest and design resources are limited (typically few or no board-level digital designers in-house), or in the face of evolving system requirements, the stackables approach is a great fit.

The unfortunate news with small form factor SBCs and I/O cards is the widespread use of space-efficient pin header I/O connectors rather than large molded PC-style connectors (such as LAN, USB, serial ports, etc.). This leads to cabling out the I/O to a bulkhead or transition board, which is undesirable in terms of additional drawings to create, cables to test, assembly instructions and points of failure. However, in many mil/aero, naval/marine and transportation markets, isolating the I/O connectors from the sensitive electronics provides a measure of resistance to high shock and vibration.

Another caveat exists with I/O-heavy system requirements. In that case, very tall stacks of I/O cards would be required, leading to a chimney form factor system that is awkward to assemble and disassemble for service and repair. Custom carriers would be flat and wide by comparison.

Features are often not optimized with stacks, especially in low channel count situations. For example, if four 16-bit analog inputs are required, then three-fourths of a 16-channel card is wasted. This worsens the SWaPaC (size, weight, and power and cost) of the system.

When to Use COMs

Computer-on-Modules (COMs) using high-density surface mount mated pair connectors and even gold-plated edge connectors in sockets are used in both backplane-based architectures and even stackable architectures. With a COM, I/O is brought to a carrier board that is developed by the OEM or by a third-party design house commissioned by the OEM. This custom carrier board is a size that best fits the application and its enclosure or packaging requirements.

COMs are very effective for high volume applications, typically 1000-5000 units per year. Also, COMs are preferred for applications where the I/O is so specialized that it’s not available within the stackable ecosystem. Typical examples could include high-speed signal processing such as radar or SIGINT using DSPs and FPGAs, which are too cost-prohibitive to accomplish with stackable cards. Refer to Figure 3 for a ruggedized tiny Atom COM example.

Figure 3
LiPPERT’s CoreExpress tiny rugged Atom COM features board-to-board connector pair.

The custom carrier board designed for each unique OEM application is perfectly optimized to the exact requirements frozen at that moment in time. To create each carrier, the OEM must have either experienced board designers in house, or the budget to pay the COM supplier or a neutral third-party design services firm. Either outsource option must be carefully qualified first for the type of design, as hardware and software outside the realm of reference design carriers and PC-style I/O might be beyond the available expertise.

COMs are promoted heavily with messages of future-proof upgradability. COMs are a good choice over stackables where fixed and consistent I/O and the ease of moving to the latest processor and chipset are more important than time-to-market.

For years, interoperability of modules from different vendors has been the Achilles heel of COM-based designs. From the hardware perspective, multiple incompatible pinout types, finicky power sequencing, power supply stiffness, ACPI resumes from power management states, and reserved pin “cheats” leave the unsuspecting system OEM pouring through volumes of documents from multiple suppliers searching for one or more needles in the haystacks. System integration often resembles plug-and-“pray” when it comes to the module’s BIOS firmware properly initializing carrier board ICs. Consider this as one black box talking to another. This is a significant hurdle compared to fully featured motherboards that already come with a working BIOS. The desktop PC architecture was never intended to be carved up in a COM manner.

Applying and Managing Power

SBCs are powered directly from a power supply, whether single voltage DC, wide input range DC, multiple DC supplies with power button control (ATX-style), or other. A power cable connects the power source to the SBC. On the other hand, COMs are powered through many small fine-pitch pins on the same surface-mount connector(s) as the bus and I/O signals that run between the COM and the baseboard. Therefore, a COM cannot run by itself in a system; it must be part of a minimum two-board solution. The power connector resides somewhere on the baseboard. Enough connector pins must be allocated for power and ground nodes to present low series resistance and inductance for good DC and AC characteristics, to meet bulk current load requirements, and to keep EMI emissions and susceptibility in check.

ACPI power management is trickier with COM architectures, as the original standard was developed for motherboards that contain BIOS, OS, chipset, power connector, RAM, video and disk interfaces all on the same board. Whereas embedded SBCs handle most or all of the issues depending on the intended level of support, COMs that are loosely defined shift the burden from COM supplier to OEM customer to get their custom baseboard working with the “black box” module.

Be Firm with Firmware

When working with a COM manufacturer, be sure to assess the BIOS firmware capabilities and whether they exist locally or overseas. Customizations are commonly needed, but that can really only start with a very clear requirements document, and filling out the vendor’s large questionnaire in as much detail as possible is well worth the back-and-forth time saved. Common BIOS modifications include legacy serial port or super I/O initialization, preventing resource conflicts, working with bus bridges especially with disparate devices behind them, and boot order changes. Debugging POST codes and blue screens can test the abilities of even the most seasoned BIOS engineers. Having a custom BIOS means that the module manufacturer needs to flash it specially for each customer, and sometimes an MOQ (minimum order quantity) applies. Be sure to ask up front.

Finally, careful consideration should be given about whether to take up a COM supplier’s offer to design the carrier. While the expertise is helpful, if the business relationship goes south most of the way into the project, the project comes to a grinding halt. A COM supplier is less likely to cooperate with qualifying a competitor’s module than a third-party services firm. Suddenly, what seemed like a multi-source open standard looks not much better than a single-source SBC product.

With COMs, system OEMs can expect a major architectural shift every 7-10 years and minor incompatible pinout types every 5 years. History shows that ETX launched in 2000 and was starting to be replaced for new designs by 2007 by COM Express, and PCI Express 3.0 (generation 3) is coming during the next few years. The tight coupling of COM pinouts to chipsets du jour, such as the shift from parallel buses to serial buses and USB 3.0 and DisplayPort, causes incompatible bumps in the road such as the Type 2 to Type 6 pinout crossover in 2011. This is quite similar to Socket 370 processors giving way to Socket 478, and of course now the CPUs are 900-1100 pins with the memory and graphics controllers from the Northbridge chip merged into the processor.

When considering COMs versus Stackables and the inherent risks and tradeoffs as they pertain to project decisions, it is noteworthy to evaluate the standards groups who create and maintain the various standards.

While innovation and evolution are essential in the embedded market, it’s up to the users of board-level technology to determine not only whether there is a real operating group behind a website, but also what the chances are of second-source and replacement products existing 5-7 years later when the inevitable x86 processor and chipset EOLs force upgrades to embedded systems. Even the small market for very-high-performance stackable systems is being fragmented into infinitesimal slices by new pinout types and buses that have no backward compatibility to 70-90% of the ecosystem. This is not to say that large established standards organizations are any more stable and customer-focused in providing smooth migration paths forward. In other words, the stackable bus or the COM pinout type may not exist on new boards 5-7 years from now. 

WinSystems

Arlington, TX.

(817) 274-7553.

[www.winsystems.com].

See also:

Small Form Factor SIG

[www.sff-sig.org].