When I became technical director of VITA back in 1990, one of the first things on my plate, besides Futurebus, was a unified mezzanine board specification. At the time there were 56 different mezzanine cards being used on VMEbus SBCs, and I acquired and read each and every spec for those implementations. They were all targeted at adding small chunks of I/O to a processor card, and as it turns out, that was the wrong concept for mezzanines.
As for the PC architecture developed, we started seeing Single Inline Memory Module (SIMM) and Dual Inline Memory Module (DIMM) mezzanine modules used to add memory. Back in 1990, memory density was measured in kilobytes per square foot of board area, so trying to add more memory using mezzanines had diminishing returns. Today, we measure memory density in megabytes per square inch, so memory technologists solved the problem for us over time. The VMEbus committee understood this problem in the early days of VME, and the VSB definition of the P-2 user-defined pins allowed access to other memory boards without using up the bandwidth of the main VME bus. Therefore, we had a solution for low memory density in the early days and didn’t need to use mezzanines, especially when dense memory chips came on the market.
The leading horse in the race to create an industry standard mezzanine specification back in the ’90s was S-bus, a subsystem bus created by Sun Microsystems for SPARC processors. The workstation market was heating up, and S-bus was used to add Ethernet connections (a new networking technology at the time) and graphics controllers for advanced display applications. But each new generation of Sun Microsystems’ workstations continually integrated the S-bus functions onto the motherboard, severely diminishing the market opportunities for S-bus board makers. That made it clear that S-bus was not a long-term solution, both from a technical and a business standpoint, for the embedded board makers who needed a mezzanine card for adding more common I/O functions.
While PCI was slowly developing in the market, there was a need for a small mezzanine card for adding I/O interfaces to Motorola 68000 processors on SBCs, and the VME committee adopted Industry Packs (IPs) as the default mezzanine for VMEbus. The IP specification was simply an abbreviated version of the 68000 local bus. That interface was well-known by VME designers, it made software and drivers easier to write, and it won out against the other 56 or so mezzanine specs out of pure ease of use.
Now the whole concept of mezzanines was to add I/O interfaces to the local bus of SBCs in a custom fashion. This eliminated the need for VME designers to decide which I/O to mount down on the processor card and allowed users to buy whichever I/O interfaces they needed (such as serial, parallel, A/D, D/A, counter timers, and so on) and simply plug them in. The overall benefit to users was that an original VME system that required 8 to 10 cards could now be done with 3 to 4 cards by using mezzanines.
What was wrong with that concept was that the I/O interface chips were extremely stable with very long life cycles. Instead, the short life-cycle chips were the processors. We went through the 68000, 68010, 68020, 68030, 68040, 68060, and a host of Pentium releases during the same period in the ‘90s. So VME engineers were burning a lot of midnight oil designing new CPU cards at a record rate but left the I/O interfaces to the mezzanine cards.
As PMC was adopted as the primary mezzanine card, and has advanced to PCI-X and now PCI Express, the shortest life- cycle chips in many embedded systems today are the I/O chips such as UARTs, Ethernet controllers, disk interfaces, parallel interfaces, A/D and D/A chips, and so on. PC processors’ life cycles are lengthening. Life cycles of the PC’s I/O are shortening. Life cycles in telecom processors are shortening; however, the I/O interfaces are extremely stable (T-1/E-1, DSL, and so on) and getting longer. The military has gone crazy with the shortening life cycles of the I/O chips in the past 5 to 7 years, considering that the life cycles on their systems run 7 to 15 years or longer. Additionally, when I/O chips go obsolete, any new chips that come to market require software changes and modifications to the base code to use them.
Today, we see the schizophrenic nature of mezzanines. While PMC and PMC Express will handle the I/O changes we face, we have created Processor PMC (PrPMC) specifications to handle the shortening life cycles of certain processor chips. This is the inflection point where mezzanines leave their original goals of easily adding I/O functions behind, which leads us in a totally new direction: plug-in processors.
Consequently, the original concept of mezzanine I/O cards was misguided and is now being turned on its head. The use of mezzanines is now splitting in several distinct directions. For processor mezzanines, small PrPMC cards are used in most traditional embedded applications and larger mezzanine cards with complete PCs onboard are used for telecom applications. Mezzanines used for PMC/PMC-X I/O interfaces are still small form factor cards used to add small chunks of I/O to traditional embedded systems, but the larger mezzanine cards are again used in telecom systems. These large mezzanines add processors and high-density I/O interfaces (such as T-1/E-1/DSL, and so on) onto line cards.
Other groups have created processor mezzanine cards as large as a VME board. This is primarily aimed at solving the Intel architecture problems. Intel processors require large caches in many applications. They need many capacitors to handle the power demands of clock surges, and they don’t like their main memory banks to be remotely located. In essence, the need for larger mezzanine cards is required to put a complete PC on a card and snap that down on an even larger card. The smaller PrPMC cards are used for putting microcontrollers and deeply embedded processors on normal-sized cards such as VME. Also, they don’t require all the supporting caches or capacitors or other logic needed for a PC.
So, mezzanine technology is splitting in several distinct directions. For processor mezzanines, small PrPMC cards are used in most traditional embedded applications, and larger mezzanine cards with complete PCs onboard are for telecom applications. Mezzanines used for PMC/PMC-X I/O interfaces are still small cards to add small chunks of I/O to traditional embedded systems. However, the larger mezzanine cards are again used in telecom systems for high-density I/O where they can pack many T-1/E-1/DSL interfaces on line cards.
Add all this to the fabric technologies coming to market. Fabric architectures assume that each I/O device in the system is intelligent. Those devices must contain a processor or a packet-thrashing state machine of some kind. Fabrics are just a mini version of a network, so each node is assumed to have intelligence. Perhaps that means that mezzanines will move toward the larger form factors, even in traditional embedded systems.
But as you increase the mezzanine card size to get processors and memory and I/O on that one card, you also increase power distribution, heat dissipation, and cooling problems. Taxonomizing the problem would lead to multiple mezzanine specifications, which include I/O, processors, memory, and so on. But that’s what we already have now.
Rest assured, there are applications for both small and large mezzanine cards. There are applications for processor and I/O mezzanine cards of both small and large dimensions. The advances in technology and the developed specifications for mezzanines have fragmented the market into numerous small segments. It’s clear that the larger companies in the board business will dominate the processor mezzanine markets, particularly those in telecom. And it’s clear that the smaller companies will dominate the I/O mezzanine markets, except in telecom again. It’s also clear that the homogenous markets for mezzanine cards, created by PMC, is unclear. We may wind up with another 56 specifications, just like I inherited back in 1990.
Ray Alderman is Executive Director of VITA. Previously, he was CEO of PEP Modular Computers, Technical Director of VITA, and founder and partner at Matrix Corporation.