When is an SBC not an SBC?


  • Page 1 of 1
    Bookmark and Share

When it’s a COM. What? No, not a serial port. A Computer-on-Module (COM), which is boardspeak for a processor module with RAM and Ethernet and a power supply. But wait, that describes a Single Board Computer (SBC), doesn’t it? If you’re confused, don’t blame it on the holiday eggnog.

Have you seen the credit-card-size SBC that features the latest AMD or Intel System-on-Chip (SoC)? Sounds like a winner, since we all want higher performance and lower power in an ever-smaller form factor. Ever notice that there aren’t connectors going all around the edges of the board? That should be your first clue that it’s not an SBC after all. If you can’t plug a USB dongle or an Ethernet cable directly into a board due to lack of PC-style connectors, there is a missing piece called a carrier board that transitions to real-world I/O connectors, power supply cables, LCD cables and the like. A processor module that plugs into that carrier board is known as a “COM.”

There’s no free lunch here. Part of the reason that a CPU module can be so tiny while SBCs are larger is that SBCs contain large, bulky I/O connectors. There would be no room for the processor if a credit card-size COM was burdened with individual or stacked I/O connectors. Not to mention no room for the thermal solution either, which would certainly be a problem. In fact, the whole module concept would go out the window. The COM is the “common core” of electronics: processor, chipset, RAM, LAN, firmware for initialization, and fixed SSD in some cases. Also on the module reside the many switchers and LDOs that generate the vast x86 power rails for the processor core, RAM, Ethernet PHY, and standby for power-down modes. Without these, modern x86 processors could not be power-efficient. Be thankful that your SBC or COM supplier took care of all this so that you don’t need to deal with them.

Both board types have strengths. SBCs are a strong choice where a standard chassis and power supply can be used, and where the I/O is a good match to the application. COMs are well positioned as a modular alternative to full custom design. Thanks to a growing crop of small off-the-shelf COM carrier boards, a Venn diagram would show the two worlds overlapping with a healthy crossover region where either approach works fine.

It might seem that the smaller the board size, the lower the cost, all else being equal. True, but to a point. Removing fiberglass and copper does save money. Shedding the real-world connectors appears to reduce cost, but in some cases can add cost when the carrier board’s connector for the COM is included, since the USB and LAN and other connectors still need to be on the carrier board. It’s critical to compare apples to apples; don’t compare SBC and COM costs until the COM carrier is added. Finally, the COM solution might be more expensive in many situations, but don’t forget to assign value to the benefits of COMs in the long-term total cost of ownership, and to the value of all the firmware engineering and validation testing that makes possible the modular building block approach in the first place. AMD and Intel will not make processors or chipsets with the same ball count, pitch and pin assignment for board-level interchangeability with each other. Sometimes they do so within their own product lines for just one new generation. Modules of a given form factor are mostly interoperable, which saves precious time and money for system OEMs. The x86 system architecture was never intended to be partitioned in the COM manner, and power and the LPC bus are among just a few interoperability snags.

Don’t be fooled by acronyms or product photos or vendor pitches. Be sure to discern whether a tiny module is an SBC or actually a COM before getting too far down the design path. You wouldn’t get far without the “aha” moment anyway. Both types of boards are useful depending on application requirements and long-term technology management goals. As with leasing versus owning an automobile, it’s probably better to pick one approach and stay with it instead of jumping back and forth with each system design generation.