PC/104: Stackable, mezzanine, card cage attributes
Choosing an embedded architecture for your system can be a daunting task. It necessitates an alignment of your short- and long-term requirements with the design tradeoffs of each available embedded architecture. Generally, you can classify these architectures as stackable, card cage, and mezzanine Computers-On-Module (COMs). Tradeoffs can include off-the-shelf or custom PCB design requirements; I/O expandability or one-time built-to-spec; end-user maintenance or Original Equipment Manufacturer (OEM) maintenance; evolutionary architecture or time-static architecture; and backward compatibility or not. Each type of architecture has its superior attributes depending on the application and situation. None serve all, but the stackable PC/104 architecture overlaps the others (Figure 1).
Card cage systems are built on the concept of sliding individual modules on two rails into a fixed enclosure with a common bus. All I/Os are typically brought out on one side of the PCB pointing toward the front. The common bus interface allows many vendors to create multitudes of modules with varying processor and I/O capabilities. OEMs can buy these off-the-shelf modules, plug them into the card cage, and get operational quickly. Because the end user has the ability to maintain systems based on this architecture, these systems can be readily found in a variety of locations.
But as one’s application becomes more embedded – and size, weight, and cost are of concern – the fixed card cage architecture becomes less optimal and efficient, especially if there are unused slots or you don’t have enough of them. Additionally, as the architecture advances, backward compatibility to an already installed fixed card cage may not be realizable without replacement or upgrade.
The PC/104 architecture evolved to address these embedded issues by keeping the common backplane while eliminating the card cage. It takes the common bus and places it directly on each module in a predetermined location. Connectivity is achieved by stacking the modules together, thereby freeing up a PCB side for additional I/O connectors. As with the card cage architecture, manufacturers and OEMs are able to create a vast array of interoperable CPU and I/O modules spanning all applications and industries. Development infrastructure is reduced since PC/104 stacks are small and can be booted up without an enclosure. Additionally, the PC/104 architecture has standalone capability and I/O connectors to allow quick out-of-the box development as Single Board Computers (SBCs). When required, enclosures can be standardized or customized to a particular need, thereby minimizing size and weight while maximizing connector location.
The stackable PC/104 architecture also has an additional feature: processor and I/O mezzanine capabilities. Since each module connects through a standard bus – such as PCI Express (PCIe) – and since each contains all of its I/O connectors, other architectures can add the stackable PC/104 connectors to create easily expandable features. As such, you will often see PC/104 expansion connectors on card cage and motherboard systems. Mezzanine COM modules evolved as a way to concentrate the complex PCB routing associated with processors on a single COM module. It is essentially removing all of the I/O connectors from a PC/104 processor module and routing the signals along with the standard bus connectivity, such as PCIe, down through a common connector to a baseboard. By doing this, the size of the complex processor PCB may be reduced, which may reduce its cost. The end user is free to create unique baseboard configurations for their applications, which may result in an optimized system. However, for complex systems that require additional functionality and I/O not found on today’s processors, and for those end users who want fully operational off-the-shelf processor and I/O building blocks without the need for additional design, mezzanine COMs become less optimal.
The embedded market is a vast and rapidly growing industry. The end user has evolving, time-tested architectures to choose from. No one architecture can serve all, but understanding how your program will progress is key to the choices you make because in the end, failure is not an option.