Developing and building systems using OpenVPX Profiles - Embedded.com

Developing and building systems using OpenVPX Profiles

OpenVPX (VITA 65) is built on existing base VPX specifications including VITA 46.x and VITA 48.x, 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 this article, we will look at how systems can be implemented using the standard Profiles defined by OpenVPX (Table 1below )


Click on image to enlarge.

Table 1 – OpenVPX Profiles at a Glance

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.

Planning Required When Selecting the Hardware
Determining the required architecture, backplanes and modules is often a daunting task when looking for an off-the-shelf solution using OpenVPX. In approaching a system implementation in VPX, a few additional steps are required to specify boards or modules for the system.

Table 1 below 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 below ), which define the mapping of I/O onto connectors used in the backplane.


Click on image to enlarge.

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

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.

The interconnect between the slots in a backplane is defined by the backplane profile (Figure 2 below ). 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.


Click on image to enlarge.

Figure 2. OpenVPX Backplane interconnect profile

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, OpenVPX slots (Figure 3 below ) 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).


Clickon image to enlarge.

Figure 3. Module profile description of OpenVPX board

Typically, the system designer breaks an application down into functional elements, and identifies functional blocks such as SBC, Switch and I/O boards. These boards or modules will then be uniquely connected through a backplane, defined by a Backplane Profile that describes the interconnect.

At this point, it should be mentioned that the developer typically requires a standard development chassis to plug in boards for system development. At a minimum, OpenVPX and the existing defined profiles are 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; existing module and slot profiles are likely 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.

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. The steps that should be follow in defining a system include the following:

1) Define the architecture
         a) Determine the backplane topology for the data flow and application (Central Switched,     Star, Distributed or Full Mesh, etc.).
         b) Determine if a standard backplane profile exists for the application—Don’t worry if it does not; this will be common.

2) Choose the slot profiles required for the I/O and your boards

     a) Pick the slot profile that defines and maps the I/O that you need—choices include Payload, Switch, Peripheral, Bridge and Storage.
    b) This process may be repetitive; there are over 30 slot profiles.

3) Obtain the module profiles for your boards
    a) The module profile specifies the ports and protocols.Examples:
          i) Two ports of PCIe x 4 (2F = 2 Fat Pipes).
         ii) Two ports of 1000-Base-T Ethernet (2T = 2 Thin Pipes).

4) Associate module profiles with the slot profiles
     a) More than one module profile can be used with a slot profile.
     b) Slot profiles are protocol agnostic.
     c) A board may comply with many module profiles.

5) This process can be repetitive – it can start with the boards or the architecture.

Identifying a Backplane
After reviewing topology needs, the system architect determines if a simple star architecture is needed, or whether a more complex central switched architecture might be required. Review of the backplane profiles will identify the standard backplanes.

Next step is to find out 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.


Clickon image to enlarge.

Figure 4. Central switch star: single root, data plan –star architecture is typical with one SBC and eight carriers

The backplane in Figure 4 above 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.

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 5a below 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.


Clickon image to enlarge.

Figure 5. 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 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.

The TAP in Figure 5a 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 5b is included in the target application profile.

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.

Ken Grob is Director of Integrated Products and Systems for Elma Electronic Inc . He holds a BSEE from Drexel University in has been in the embedded computing open architectures industry since 1985.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.