RTC Magazine

VPX has great promise. VPX leverages the Eurocard 3U and 6U form factors. MIL/Aero system integrators have used these types of modules, like VME and CompactPCI boards, in rugged embedded applications for many years. Similarly, the VPX module has provisions for PMC and/or XMC I/O mezzanines, but adds a P0 connector for power, reference clocks, geographical pin assignments, JTAG, non-volatile write protection, system reset and out-of-band management. VPX also specifies a new connector to support the latest serial fabric technology, special alignment posts, card keying, safety grounds and 160 (3U) or 480 (6U) signal connections. Adding VPX-REDI (VITA 48) defines module ESD covers, larger horizontal pitch widths to accommodate the latest high-performance silicon, and every type of cooling imaginable.

The key differentiator of the VPX form factor is the new connector, the Multi-Gig RT2 (Figure 1). This wafer-based connector provides special ESD ground planes, single-ended connections for bused-type signals, and differential paired (diff-pair) traces specifically designed to route high-speed SerDes type communications between modules on a backplane. Tyco has designed the Multi-Gig RT2 connector to support greater than 5 GHz signal speeds, which accommodates USB 2.0, PCIe 2.0, sRIO 2.1, 10GigE, FPGA SERDES and other high-speed serial fabrics.

Other VITA standards like VITA 60 and 63 have specified compatible connectors that could replace the Multi-Gig connector for even more vibration and shock intense applications, as well as connectors for special signal capability like optical (VITA 66) and radio frequency (VITA 67). VPX, VPX-REDI and all of the other related VITA specifications should support current and future processing and data-communication technologies for the MIL/Aero market.

VPX - The Issue

Regardless of the connector strategy, the problem with serial fabrics is that they are point-to-point. Therefore, when defining the backplane for two or more VPX modules with serial fabrics, the designer must connect each differential pair, or diff-pair, to exactly one other module’s diff-pair. Most serial fabrics are duplex communications such that one lane requires four connection pins (one module’s diff-pair transmits to another modules diff-pair receive port and vice versa). 

If there are more VPX modules in the system, then more connection pins are necessary for data communications.  Designers can aggregate the diff-pairs together for larger data bandwidth, but this takes even more connections. Even with 480 (for 6U) or 160 (for 3U) pins available to the VPX module designer, high-bandwidth serial communications with many modules to connect can quickly utilize most of the available pins, leaving very few for specialized module I/O (Figure 2). 

Open VPX

VPX and VPX-REDI define a module’s dimensions, connectors, power, utility connections and fabric protocols; they do not define how to use these specifications at the system level. Depending on fabric choice, bandwidth need, module capability and I/O selections, there are many ways to create a system. To address this issue, a group of companies created OpenVPX.

OpenVPX is a working group designed to accelerate the ability for customers to buy interoperable VPX development systems and modules from independent vendors. Most VITA members are part of this working group, which will release the OpenVPX specification for VSO ratification into VITA 65 by the end of 2009. It is the hope that VPX vendors will refer to new VPX modules and systems as OpenVPX to communicate the new interoperable, easy-to-develop and ready for the future Eurocard standard.

Everything Is in the Taxonomy

OpenVPX defines a pipe as connections made up of diff-pairs. For example, an Ultra-Thin Pipe (UTP) is two diff-pairs or four connections on a Multi-Gig connector. A Thin-Pipe (TP) is four diff-pairs, and a Fat-Pipe (FP) is eight diff-pairs.  Fat-Pipe grouping expands to Double Fat Pipe (DFP), Quad Fat Pipe (QFP) and Octal Fat Pipe (OFP) to describe the largest bandwidth plane needed (Table 1). The plane is the type of communication that uses pipes. OpenVPX defines planes as interoperable data connections between modules. For example, if a plane has 1.0 Generation PCIe fabric on an UTP, this would equal one lane (x1) of PCIe at 2.5 Gigabits per second duplex.  Finally, profiles are classes of modules, slots, backplanes and chassis, which define a system.

Planes and User I/O

OpenVPX makes a distinction between planes and user-defined pins. Planes are wafer pins routed through the backplane to other wafer pins. For example, if a backplane topology calls for one fat pipe routed to another slot, that connection pipe is a plane. User-defined wafer pins connect through the backplane to the rear transition module (RTM) and there is no slot-to-slot connection of these pins. The VPX module developer could use these user-defined pins for any purpose without worrying about interoperability with other modules. Fabric connections that are not part of a plane have no connection to another slot or to the RTM. With this type of system-level specification, OpenVPX defines interoperability at the mechanical, module and backplane level. 

For example, a simple two-slot backplane can connect two boards with one DFP interconnect (Figure 3). Figure 3 also shows how a three-slot backplane can connect three VPX modules with slot 1’s FP A connected to slot 2’s FP A and slot 1’s FP B connected to slot 3’s FP A. 

Alternatively, by lowering the slot-to-slot bandwidth and adding more slots, a six-slot backplane could connect six VPX modules together by slots 1’s FP A connected to slot 2’s FP A. The backplane can further separate Slot 1’s FP B into four UTPs and each one of these pipes routed to different slots (Figure 4). OpenVPX defines many different data-plane strategies to optimize fabric connections for optimal bandwidth and slot count.  

OpenVPX Profiles

OpenVPX defines four types of profiles: slot, module, backplane and chassis. Interoperability starts at the module level, so the fundamental profile is the slot profile, which has basic definitions of planes (type, number and size) and user-defined pins. A backplane profile defines how slot profiles are connected. Chassis profiles add mechanical specifications, input power and slot number to specify a chassis. Finally, the module profile defines how module vendors apply specific fabrics to the slot profiles as well as definitions of fundamental module characteristics. With these four profiles, system integrators can integrate different VPX vendor modules, backplanes and chassis into a system. 

The slot profile is the physical connection basis of module-to-module interoperability. OpenVPX defines slot profiles as groupings of wafer pins into planes and user I/O. Slot profiles also define which types of planes are utility, maintenance, expansion, control and data. The rest of the pins are user-defined, and not routed to another slot. OpenVPX states that these user pins could be customized to any application-specific backplane, but are normally routed to the RTM. The utility plane is common to all VPX modules except for power. The maintenance plane is a serial bus between the modules for low-level module identification, module health monitoring and chassis control. The control plane is a separate pipe from the main data plane; typical module profiles specify this as some sort of Ethernet. Finally, the data plane is the main data communications pipe through the backplane.

The example 3U slot profile in Figure 5 shows where the data, control, utility and maintenance planes are located on a 3U VPX module. The rest of the pins are user-defined. There are different module types for payload (PAY), switches (SWH), bridges (BRD), peripherals (PER) and storage modules (STO).  However, module types do not dictate board function, so peripheral boards may use payload profiles and vice versa. The 2F2U describes the data plane as two FPs and the control plane as two UTPs in size. The slot profile allows smaller data plane sizes on the FP like two TPs or four UTPs. Simply put, the slot profile defines the maximum plane size and location relevant to interoperability.

Module profiles define how these planes are instantiated, along with other module information like module voltage requirements and cooling specifications. The module profiles provide module-specific information to define everything but the physical pins used and improve system interoperability by specifying necessary fabric information. Module profiles define the different fabrics options for the data and control planes. In Table 2, all the control planes are 1GigE physical interfaces, and the fat pipes are sRIO, PCIe, or 10GigE. 

Backplane profiles connect slot profiles together to make the different backplane topologies intended for development systems as well as specific implementations that conform to the slot profiles. While some of these profiles are ideal development systems, the OpenVPX members tried to address specific market needs that may be very useful for the Mil/Aero customer. The following are two examples of OpenVPX backplane profiles. 

The first example, Figure 6, is a nine-slot system with minimal bandwidth. The backplane profile calls out one slot profile (SLT3-PER-2F) and one module profile (MOD3-PER-2F) for each slot. The slot profile makes it possible to create a central controller with eight UTP connections and a peripheral slot with one UTP connection. The backplane topology connects the central controller to the peripherals in a star fashion. 

The nine-slot OpenVPX example with module profile for Gen 1 PCIe creates a system with a peak data-plane bandwidth of 250 Mbytes/s in each direction per duplex pipe. This equates to a total system peak bandwidth of up to 2 Gbyte/s simultaneous data communications. If the modules in the system use Gen 2 PCIe module profile, the data-plane bandwidth would increase from 250 Mbyte/s to 500 Mbyte/s (duplex), making peak data-plane bandwidth 4 Gbyte/s. The type of module integrated into the system defines the system; if the system integrator wanted to use sRIO then the backplane would not need to change, just the modules. 

The second system is an example of a rugged ultra-high-bandwidth system with a data plane communication of four lanes (10 Gigabit/s per slot or greater) or one FP. The example shows a topology for a seven-slot system with optimized bandwidth by using a central switched slot. 

Figure 7 shows one FP connected to a central switch slot. In addition, this backplane profile has the similar definition for a one-UTP control plane by using the XXX-PAY-2F2T slot and module profiles and the appropriate switch profile. Again, the type of module integrated into the system defines the system; if the system integrator wanted to use 10GigE then the backplane would not need to change, just the modules.

Chassis profiles collect backplane, cooling and physical characteristics into a set of definitions for OpenVPX development systems and could provide the basis for production-ready systems. This part of the specification instantiates chassis type, slot count, power input, module cooling, backplane profile, pitch, power capability and chassis manager. The idea to standardize development chassis is OpenVPX’s path to interoperability. Module providers can build to readily available chassis and start the process of system integration, which will grow the VPX ecosystem.

Defining a new Eurocard standard is not easy; the flexibility and capability of VPX leads to countless choices. Now with OpenVPX, the VPX standard can thrive. It is now a true open standard with easy to understand rules and guidelines to define interface points and minimize incompatibility. Innovation can still happen, but now with a well-defined process in VPX to describe interoperability. With the current processor and data-communications technologies that are available now and in the near future, OpenVPX will have a specification that fits that technology enough for the customers to evaluate, develop and deploy with the VPX Eurocard form factor. 

Concurrent Technologies

Woburn, MA.

(781) 933-5900.

[www.gocct.com].