Design Feature: March 2, 1995

Like the backplane-bus architectures they mimic, mezzanine buses promise substantial benefits. Backplane buses have already made good on their promise, allowing you to create a customized system by selecting from an array of off-the-shelf boards and plugging them together. The breadth and diversity of the board array provide design flexibility and allow the selective upgrading of hardware functions. Competition between board vendors promotes innovation and lower prices. To achieve these same benefits at the board level, manufacturers have widely adopted the use of a daughterboard on a standard mezzanine bus.

Picture 1

The term "mezzanine" comes from the daughterboard's position within the rack. The daughterboard, or mezzanine card, occupies a position between two main cards within the cage, just as a mezzanine in a hotel lies between two main floors. The functions that the mezzanine card can provide depend on the nature of its standard bus. Some mezzanine buses provide an opportunity to add specialized I/O functions. Others allow upgrading of the main board's CPU and memory.

The mezzanine-bus approach lets you use off-the-shelf modules to customize a base board quickly with the type and amount of I/O or processing you desire. By allowing the mix and match to occur on a single card rather than on several cards in a rack, mezzanine buses increase the space efficiency of off-the-shelf systems. Mezzanine buses further simplify the task of designing a function when off-the-shelf boards don't meet your system needs. Mezzanine-bus cards are smaller, cheaper, and easier to design than are full-size backplane-bus cards.

Mezzanine buses also provide a private data highway for time-critical information that would otherwise be shuttled across the system backplane for processing. The information's movement would suffer delays due to protocol overhead and the need to share the backplane's bandwidth with other system functions. A mezzanine bus can be free of those restrictions.

Overcoming a checkered past

For all of its advantages, however, the mezzanine bus developed an unsavory reputation. Early daughterboards for use on the buses suffered reliability problems due in part to connector failures. The daughterboards also experienced heat buildup in the space between them and the main boards.

Although the stigma of those early years remains, manufacturers have long since solved the problems themselves. The result has been that most board manufacturers have been adopting mezzanine buses since the late 1980s. Even that most demanding of customers, the US military, has accepted the mezzanine concept by qualifying Radstone Technology's MxBus. Indeed, the number of mezzanine buses almost exceeds the number of board vendors. Table 1 provides a representative sample of available mezzanine-bus structures.

However, the mezzanine-bus approach does have its drawbacks. The ease of hardware customization a mezzanine bus provides comes at the expense of software complications. While a daughterboard may function electrically in any base board with the appropriate mezzanine bus, the software to run the card is not so portable. Mezzanine boards with similar functions from different manufacturers do not typically have the same address and register assignments. Each must, therefore, come with unique drivers. The drivers, in turn, vary with the operating system you use.

That software also varies with the base-board type you use. The software disk that Pentek provides for its products, for example, has separate directories for each of its base boards. Each directory contains sample initialization and data-transfer programs in C for all of Pentek's mezzanine boards with that base board. The result is a matrix of software and drivers covering all the base-board/mezzanine-board combinations.

Exploding software needs

Factoring together the number of base boards, mezzanine boards, mezzanine buses, and operating systems available results in a combinatorial explosion of software requirements. Mezzanine-board vendors cannot provide enough support to allow their customers complete freedom in mixing and matching mezzanine and base boards from different manufacturers. To achieve that degree of flexibility, you're going to have to do some software development. The amount of software development you need to do depends on the level of software support your suppliers provide and on the operating system you use. Suppliers vary in both the amount of software they provide and the range of operating systems they handle. Choosing a popular operating system maximizes your chances of receiving useful off-the-shelf software with your mezzanine boards.

One way to reduce the software complexity of the mezzanine-bus approach would be to standardize the mezzanine bus itself, eliminating one variable. The industry has made several attempts to achieve such a standard. One of the earliest attempts was the Special Application Module (SAM) bus for VME boards in the mid-'80s. The bus was effectively an extension of the 68xxx CPU bus for VME boards, however, and was limited to boards using that CPU family. It eventually faded from the market.

Picture 2

The late '80s saw the emergence of other mezzanine buses that their creators released as open architectures to create de facto standards. Table 2 lists several of these buses, along with some of the companies that have adopted the architectures. Two of the most popular architectures, Greenspring's Industry Pack bus and MEN Mikro Elektronik's M-Modules, are approaching true industry standardization. Makers of M-Modules have banded together to form the Manufacturers and Users of M-Modules (MUMM) association, which has taken over the M-Module standard. Both MUMM and Greenspring are now working within the VMEbus International Trade Association (VITA) to develop their specifications for submission to ANSI as international standards.

The IEEE has also made an attempt to standardize a mezzanine card. The IEEE's proposal P1386 attempts to define a common mezzanine card (CMC) that works on VME, Futurebus+, Multibus, and other backplane-bus boards. The base specification describes only the mechanical dimensions and connector requirements, however, and allows two electrical specifications. P1386.2 describes the SBus mezzanine card (SMC), which marries the SBus to CMC. P1386.1 describes the Peripheral Component Interconnect (PCI) mezzanine card (PMC), which uses the PC PCI bus.

The PMC standard saw considerable industry endorsement at its introduction in September 1994. Both VITA and the Multibus Manufacturers Group (MMG) backed PMC. In addition, 13 manufacturers announced product plans that included PMC, although not all are yet available. A number of other companies have since jumped on the PMC bandwagon.

The goal in transforming the PCI bus to a mezzanine bus is to take advantage of the tremendous economies of scale that the PC industry provides. By adopting PMC, board vendors can readily apply PCs' highly integrated graphics, mass storage, and I/O chips to the embedded market. The PMC bus is electrically identical to the PCI bus, so designers can readily transfer PCI designs to PMC. Further, the diversity of software for PCI-based PC products becomes available for PMC-based embedded products. Despite widespread industry enthusiasm, however, PMC has its share of skeptics who point out a dark side to the rosy picture PMC's proponents paint. Like the benefits, the dark side stems from PMC's attempt to leverage the PC community's innovations.

The first drawback skeptics cite is that the PC industry is highly volatile. In contrast to the 10- to 15-year product life that many embedded-computing customers demand, the PC industry often changes its products several times a year. As the underlying PC components evolve or become extinct, that turnover places in question the long-term availability of PCI parts for PMC cards.

Another drawback of PMC is that PC-component manufacturers typically handle only the DOS and Windows operating systems and have only a slight recognition of Unix. They are virtually indifferent to such popular embedded operating systems as VxWorks, OS-9, and VMEexec. If your system is not PC-compatible, you may face a considerable software-design effort to employ the highly integrated, complex-to-program ICs for PCI.

Skeptics' other concerns about PMC center on the cost and complexity of custom designs. Many embedded-system integrators want to build their own mezzanine boards. PMC skeptics point out that PCI interface chips are still relatively expensive ($50 in quantity). Designing your own interface, they warn, is a complex task. Further, the PCI bus limit of 10-pF input capacitance per pin for an interface card precludes designing a PCI-compliant PLD-based custom interface, because high-speed PLDs typically have a 12-pF input capacitance.

Whether the promises or the concerns over PMC will win out remains to be seen. One thing is already clear, however. Neither PMC nor any other mezzanine bus will achieve the distinction of becoming the sole standard. None of the open standards satisfies everyone's needs. Indeed, manufacturers and standards groups are continually proposing new mezzanine buses, including Ziatech's Ruggedized PCI bus and the MMG's PCI-like MIX-2. At best, several mezzanine buses will coexist.

Further, the board industry is partially resistant to mezzanine-bus standardization, despite the customer benefits standardization entails. Some of the resistance comes from genuine differences in customer requirements. PCI is costly overkill for some customers' needs, for instance, and Industry Pack has limited bandwidth. But other resistance comes from the vendors' attempts to hold onto proprietary designs and compete on the basis of function and performance instead of cost. In either case, widespread adoption of standards is slow, and mezzanine buses have yet to fulfill their promise.

You can reach Technical Editor Richard A Quinnell at (408) 685-8028, fax (408) 685-8028.