New concepts introduced by OpenVPX, such as Module, Slot and Backplane profiles were discussed with a guide to navigating the specification. OpenVPX is built on existing base VPX specifications including VITA 46.x, and therefore VPX systems are largely based on serial fabrics implemented using pairs of differential point-to-point interconnects. In moving from a parallel bus-based scheme of interconnect to a serial fabric-based interconnect, the notion of one general backplane topology such as VME or cPCI is gone.

The industry has been using a set of backward-compatible standards for years that have allowed plug-compatible modules to be used with common backplanes. For over 20 years, VME boards have been interoperable with little concern as to whether a board would operate when plugged into widely available standard backplanes. With the serial fabrics used in OpenVPX, board-to-board I/O is now point-to-point, and unique. A central goal of the OpenVPX standard is to promote interoperability. Thus OpenVPX has introduced a language to describe and label interconnects required to implement specific system topology, and has also given us named profiles to identify unique topologies for interconnecting modules. In part two, we will look at how systems can be implemented using the standard Profiles defined by OpenVPX.

Before we get started, let’s look at some general items to consider when weighing OpenVPX versus other existing legacy system standards. For instance, when comparing VME or cPCI to VPX, the following points and features can be reviewed when comparing the technologies:

• Available form factor – 3U or 6U
• Convection- or conduction-cooled environment, supported by OpenVPX
• More available power in 3U and 6U form factors than VME and cPCI
• Higher bandwidth differential interconnects up to 6.25 Gbit/s
• Required system topology: Mesh, Star, Dual Star; the need for multiple signal planes
• Need for redundancy, for instance dual star architecture
• Legacy support for parallel VME is a hybrid system
• Single plane or multi-plane architecture: Control plane, Control and Data, need for Expansion plane
• Type of Fabric Protocol: PCI Express, Ethernet, SRIO, etc.

More Planning Required – Picking Hardware

Determining the required architecture, backplanes and modules may be an iterative process when looking for an off-the-shelf solution using OpenVPX. In approaching a system implementation in VPX, a few additional steps are required in specifying boards or modules to be considered for the system. In part one, a table was introduced called “Profiles at a Glance.” This table describes the types of profiles defined by OpenVPX. OpenVPX defines profile descriptors for modules to be used in a system, and then also defines slot profiles (Figure 1), which define the mapping of I/O onto connectors used in the backplane. The module profile is specific to the physical protocol to be used, such as PCI Express or 1000Base-T Ethernet, while the slot profile maps I/O onto a connector but is agnostic in terms of physical protocol.

Figure 1
Example Slot Profiles from left to right: Payload, Peripheral, Switch and Storage.

Further interconnect between the slots in a backplane is defined by the backplane profile (Figures 2 through 4). In that the backplane profile references slot profiles, the designer must identify the profiles associated with the standard boards that will be selected for the system. In order to do this, each board manufacturer must specify the module profile description of the OpenVPX board, to identify the physical interfaces of the module. This would be a starting point in identifying interoperable modules to be used in a specific OpenVPX system topology. In addition, one must consider the system topology that will be required of the modules or boards to be used in the system. By way of review, slots are defined as Payload (PAY), Peripheral (PER), Switch (SWH), Storage (STO) and Bridge (BRG). Backplane topologies are identified as Central, or Star (CEN), Distributed, or Mesh (DIS) and Hybrid—VME & VPX (HYB).

Typically the system designer will be breaking an application down into functional elements, and identifying functional blocks such as SBC, Switch and I/O boards. These boards or modules will be connected uniquely through a backplane defined by a backplane profile describing the interconnect.

At this point, it should be mentioned that the developer will typically require a standards-based development chassis to plug boards into to support system development. At a minimum, OpenVPX and the existing profiles initially defined were identified to do exactly this, provide a backplane topology suitable to support initial system development. What should be made clear is that the development profiles specified by OpenVPX may not provide the topology necessary to implement the user’s end architecture. The end architecture may require a “yet to be defined” interconnect at the backplane level; however, existing module and slot profiles may be suitable, but the end backplane interconnect may require tailoring.

OpenVPX provides a language to describe the modules and slots, and provides a way to draw and describe a tailored backplane. Here, the end application profile can be described as a target application profile TAP), the one that will ultimately be needed by the end application. Where the TAP may use standard slot and module profiles, the backplane profile will end up being specific. This has been anticipated by the OpenVPX standard. In certain cases, it may be desired to apply for a new backplane profile to be added to the standard. The VITA standards body has made provisions for new profiles to be considered for addition to the standard, however it is not required.

In identifying a backplane that is appropriate, review the topologies described by 6U module profiles and 6U backplane profiles in the specification that will identify the architectures that are available. 3U tables are also in the spec. Many manufacturers will tend to point the user to a reference development system, or specify module profiles that can assist in identifying a suitable development chassis with an appropriate backplane. For a sequence of steps in defining a system, see “What are the Steps to Define a VPX System?” p. 33.

Identifying a Development Backplane

After review of the topology needs, the system architect will determine if a simple star architecture is needed, or whether a more complex central switched architecture may be required. Review of the backplane profiles will identify the standards. Next, one needs to know if they are actually available. Conversations with the board manufacturer or a packaging company will reveal which standard backplanes have been brought forward. If not, typical lead times to have a backplane built to the standard are on the order of 10 to 16 weeks. Such backplanes can usually be added to a standard development chassis. The backplane in Figure 5 is a simple central switched star, using a single root SBC in slot one, with eight peripheral slots using UTP PCIe x 1 link. The peripheral modules can be simple VPX Carrier cards.

Figure 5
Central switch star example: Single Root, Data Plane - Star Architecture is Typical with one SBC and 8 carriers.

Adding Temporary Pipes to a Backplane

Adding connections to an uncommitted backplane is a method to test an evolving topology. A way to do this is via off-the-shelf differential cables, organized as OpenVPX jumpers. These cables can be made with wafer based connectors, organized as Ultra Thin, Thin and FAT Pipes, allowing a point-to-point connection to be added to the backplane. For instance, a PCIe x 4 connection can be added from an SBC Payload slot to a Peripheral slot to drive a required expansion connection.

Development in Steps

If the target application can’t be implemented via a released OpenVPX backplane, it is likely that parts of it can be implemented with an off-the-shelf backplane. If the end application requires tailoring, then a target application profile (TAP) must be developed. Figure 6a shows how two standard profiles can be used to begin development, with a notional view of a topology required when multiple FPGA payload cards are used in an application. In this case, a TAP is required to specify the interconnect required of the end-use backplane. It is useful to describe it based on standard slot and module profiles as shown.

Figure 6
A target application profile (a) modifies a standard backplane profile with an extension that specifies the interconnect needed to add the extended version of the management switch (b).

The TAP in Figure 6 extends BKP3-CEN-07-15.2.3-n, by adding expansion plane interconnect between 3U front end processor boards. Single board computers are connected via the data plane, and control plane to the 3U Switch. The switch provides PCIe Gen 2 fabric on the data plane, and Gigabit Ethernet via UTPs on the control plane. An extended version of the SLT3-SWH-6F6U-14.4.1 switch profile shown in Figure 6b is included in the target application profile.

Figure 6
A target application profile (a) modifies a standard backplane profile with an extension that specifies the interconnect needed to add the extended version of the management switch (b).

In summary, designing with OpenVPX requires the user to be sensitive to the unique I/O mapping of each backplane to be used. The specification has provided a means to identify module I/O specific to the fabric protocol used, and slot I/O as a general mapping of the I/O per slot, in order to allow unique interconnect of the slots defined by a backplane profile. Care must be exercised in selecting the backplane, since the fabric interfaces support different bandwidths, thus requiring better materials as the bit rate is increased. OpenVPX has provided a set of profiles, or recipes for implementing VPX-based systems. Variants of the existing backplane profiles are expected, and will be necessary to implement specific applications that can be described as Target Application Profiles.