Vita 65 Openvpx 31 60

1.1.
4 Module Profiles
The Module Profile defines what communication protocol can be used on each pipe as defined in
a corresponding Slot Profile, connector type, module height (6U/3U), and cooling method
(forced air/conduction).
Table 1.1-1 summarizes the content of each profile and their relationship to each other.
Table 1.1-1 OpenVPX Profile Relationships

Chassis
Module Profile Slot Profile Backplane Profile Profile
Communication Protocols Communication Plane

Topology Backplane
Slot Profile Compatibility Profile
Pin-Allocation
Definition Slot Profiles
Utility Signals
Connector Type Connector Type
Height Height Height Height
Cooling Cooling
Pitch Compatibility Pitch Pitch
1.2 OpenVPX Document Structure Description

The purpose of this section is to explain the document structure, in order to assist the reader in
navigating the document.
The OpenVPX document structure is best described as a hierarchical descending tree, illustrated
in Figure 1.2-1 through Figure 1.2-6. Generally, OpenVPX sections 5 and on are designed to
accept new content, in the form of new sub-sections, as new serial technologies, new slot,
backplane and module definitions emerge from the VPX market.
ANSI/VITA 65-2010 (R2012) Page 31 of 555 February 2012

Chassis Profile
Backplane Profile
Slot Profiles Slot Profiles
Module Profiles Module Profiles
Figure 1.2-1 Profile Tree Structure
Section 5: Protocol
Specific
Section 5.1: Ethernet Section 5.2: Section 5.3: Section 5.4:

Serial Rapid I/O PCI-Express InfiniBand® (IB)
Section 5.1.1:
1000BASE-BX
Section 5.1.2:
1000BASE-KX
Section 5.1.n:
Other Ethernet
standards
Figure 1.2-2 Protocol Specific Structure

Section 6: Common Requirements 6U/3U Slot Profiles
Section 6.3: Common Requirements for Slot Profiles using

VITA 46.0 Connectors
Section 6.4: Common Requirements for Slot Profiles using

VITA 46.0 and VITA 67 Connectors
Section 10.1: Common Section 14.1: Common

Requirements Requirements
6U Slot Profiles 3U Slot Profiles
Sections 10.2 – 10.5:

VITA 46.0 Connector
Sections 14.2 – 14.5: Section 14.6: VITA 46.0
Based 6U Slot Profiles
VITA 46.0 Connector and VITA 67 Connector
Based 3U Slot Profiles Based 3U Slot Profiles
Slot
Profile 1
Slot Slot
Profile 1 Profile 1
Slot
Profile 2
Slot Slot
Profile 2 Profile 2
Slot
Profile n
Slot Slot
Profile n Profile n
Figure 1.2-3 Slot Profile Structure

Section 7: Common
Requirements 6U/3U
Backplane Profiles

Requirements 6U Requirements 3U
Backplane Profiles Backplane Profiles
Section 11.2: VITA 46.0 Section 15.2: VITA 46.0 Section 15.3: VITA 46.0
Connector Based 6U Connector Based 3U and VITA 67 Connector
Backplane Profiles Backplane Profiles Based 3U Backplane
Backplane Backplane Backplane

Profile 1 Profile 1 Profile 1


Profile n Profile n Profile n
Figure 1.2-4 Backplane Profile Structure

Section 8: Common
Requirements 6U/3U
Module Profiles

Requirements 6U Requirements 3U
Module Profiles Module Profiles
Sections 12.2 – 12.5: Sections 16.2 - 16.5: Sections 16.6: VITA 46.0
VITA 46.0 Connector VITA 46.0 Connector and VITA 67 Connector
Based 6U Module Based 3U Module Based 3U Module
Profiles Profiles Profiles
Modules Modules Modules



Profile n Profile n Profile n
Figure 1.2-5 Module Profile Structure

Section 9: Common
Requirements 6U/3U
Dev. Chassis Profiles
Section 9.2: 6U/3U VITA 48.1 Air-Cooled Dev. Chassis
Section 9.3: 6U/3U VITA 48.2 Conduction-Cooled Dev. Chassis

Requirements 6U Dev Requirements 3U Dev
Chassis Profiles Chassis Profiles
Section 13.1.1: VITA 48.1 Section 17.1.1: VITA 48.1

Air-Cooled Dev. Chassis Air-Cooled Dev. Chassis
Section 13.1.2: VITA 48.2 Section 17.1.2: VITA 48.2

Conduction-Cooled Dev. Conduction-Cooled Dev.
Chassis Chassis
Sections 13.2: Based 6U Sections 17.2: Based 3U

Dev. Chassis Profiles Dev. Chassis Profiles
Figure 1.2-6 Standard Development Chassis Profile Structure
1.3 Terminology
1.3.1 Specification Key Words

To avoid confusion and to make very clear what the requirements for compliance are, many of
the paragraphs in this standard are labeled with keywords that indicate the type of information
they contain. These keywords are listed below:
• Rule
• Recommendation
• Suggestion
• Permission
• Observation
Any text not labeled with one of these keywords is to be interpreted as descriptive in nature.
These will be written in either a descriptive or a narrative style.

Key words are reserved for specific use as defined in subsequent sections.
1.3.1.1 Rule <section>-<number>:

Compliance with Rules is mandatory. Rules always include the term “shall”. Rules are expressed
in some combination of text, figures, tables, or drawings. All Rules will be followed to ensure
compatibility between board and backplane designs. All Rules use the “shall” or “shall not”
words to emphasize the importance of the Rule. The “shall” or “shall not” words are reserved
exclusively for stating Rules in this draft standard and are not used for any other purpose.
1.3.1.2 Recommendation <section>-<number>:

Compliance with Recommendations is optional. Recommendations always include the term
“should”. Recommendations are used to convey implementation advice based on the
community’s collective knowledge base. Wherever a Recommendation appears, designers would
be wise to take the advice given. Doing otherwise might result in poor performance or awkward
problems. Recommendations found in this standard are based on experience and are provided to
designers to speed their traversal of the learning curve. All Recommendations use the “should”
or “should not” words to emphasize the importance of the Recommendation. The “should” or
“should not” words are reserved exclusively for stating Recommendations in this draft standard
and are not used for any other purpose.
1.3.1.3 Suggestion <section>-<number>:

A Suggestion contains advice, which is helpful but not vital. The reader is encouraged to
consider the advice before discarding it. Some design decisions that need to be made are difficult
until experience has been gained. Suggestions are included to help a designer who has not yet
gained this experience.
1.3.1.4 Permission <section>-<number>:

Compliance with Permissions is optional. Permissions always include the term “may”. In some
cases, a Rule does not specifically prohibit a certain design approach, but the reader might be left
wondering whether that approach might violate the spirit of the Rule or whether it might lead to
some subtle problem. Permissions reassure the reader that a certain approach is acceptable and
will cause no problems. All Permissions use the “may” words to emphasize the importance of the
Permission. The lower-case “may” words are reserved exclusively for stating Permissions in this
draft standard and are not used for any other purpose.
1.3.1.5 Observation <section>-<number>:

Observations do not offer any specific advice. They usually follow naturally from what has just
been discussed. They spell out the implications of certain Rules and bring attention to things that
might otherwise be overlooked. They also give the rationale behind certain Rules so that the
reader understands why the Rule must be followed.
1.3.2 Glossary
Table 1.3.2-1 gives terms that are used within the body of the specification. In this context, they
have the meanings given in the Table.
Table 1.3.2-1 Glossary

Term Definition
Backplane Profile See Profile.
Bridge Module See Module.
Bridge Slot See Slot
Bus A multi-drop physical interconnection between three or more entities.
Example: The physical interconnection of [VITA 46.0] defines SM[3:0]
as going to all slots, hence SM[3:0] is a bus.
Channel A point-to-point physical interconnection between exactly two entities.
The width of a Channel can vary across Channel instances. Example: A
single 4x Serial RapidIO connection between a given Payload Module slot
and a Switch Module slot.
Chassis A physical enclosure that provides module and backplane resources
defined by one or more Profiles necessary to implement the logical
functionality specified by one or more system implementations.
ChMC Chassis Management Controller. ChMCs are optional System
Management components, defined by [VITA 46.11].
Compatibility The ability of an item not meeting all requirements of compliance to
interoperate with compliant items, albeit with less capability and without
impairing the compliant item’s functionality.
Compliance Conformity in fulfilling Official Requirements.
Conformity The act of verifying the item’s performance against each declared
requirement.
Connector A mechanical device used to hold two parts of an electrical or optical
circuit together. In OpenVPX, Connectors are used to attach and detach
Modules and/or cables to other Modules and/or cables.
Control Plane See Plane.
Data Plane See Plane.

Term Definition
DFP Double Fat Pipe. See Pipe.
Double Fat Pipe See Pipe.
Downstream Port See PCIe
Endpoint See PCIe
Expansion Plane See Plane.
Fabric A set of paths used for communication between elements of a system
Fat Pipe See Pipe.
FP Fat Pipe. See Pipe.
IB InfiniBand, See www.infiniband.org for more information.
Interoperability The ability of two or more items that are compliant or compatible to the
same set of requirements to function together.
IPMB Intelligent Platform Management Bus, defined by [VITA 46.11].
IPMC Intelligent Platform Management Controller. IPMCs are optional System
Management components, defined by [VITA 46.11].
Lane An electrical lane consists of one transmit differential pair and one receive
differential pair, point-to-point, crossed connection (transmit connects to
receive and receive to transmit).
An optical lane consists of a transmit and receive fiber, point-to-point,
crossed connection.
Management Plane See Plane.

Term Definition
Module A printed wire assembly which conforms to defined mechanical and
electrical specifications. Preexisting examples of Modules that are
applicable to OpenVPX include 3U Plug-In Modules; 6U Plug-In
Modules; backplanes, mezzanine Modules such as XMC, PMC, or FMC
Modules; and Rear Transition Modules. Additionally, the following
Module types are defined by OpenVPX:
Bridge Module: A Plug-In Module in an OpenVPX system that might be
required to provide communication paths between multiple Plug-In
Modules that support different Plane protocols and/or implementations.
When the transfer of information is necessary between Plug-In Modules
utilizing dissimilar interfaces for communication, the Bridge Module
terminates the Channel and/or Bus from the Plug-In Module(s)
communicating via the initial protocol and transmits the information
along to the Plug-In Module(s) communicating via the second protocol on
a separate Channel or Bus.
Payload Module: A Plug-In Module that provides hardware processing
and/or I/O resources required to satisfy the needs of the top-level
application. Example: A Payload Module might be an embedded
processor or an I/O controller Module.
Peripheral Module: A Plug-In Module such as an I/O device interface
that is usually subservient to a Payload Module.
Plug-In Module: A Module that is capable of being plugged into a
backplane.
Storage Module: A Module providing the functionality of a disk drive.
An example is a SATA HDD/SSD (Hard Disk Drive / Solid-State Drive)
carrier.
Switch Module: A Plug-In Module in an OpenVPX system that
minimally serves the function of aggregating Channels from other Plug-In
Modules. These Channels might be physical partitions of logical Planes as
defined by a Backplane Profile. This Module terminates the aggregated
Channels and provides the necessary switch fabric(s) to transfer data
frames from a source Plug-In Module to a terminating Plug-In Module as
defined by the assigned Channel protocol. This Module is typically used
in systems that implement centralized switch architectures to achieve
interconnection of their logical Planes. Distributed switch architectures
typically do not include a Switch Module.
Module Profile See Profile.
Non-Transparent Port See PCIe.

Term Definition
Official Requirements Those declared by this specification, as applicable to profiles and any
referenced specifications and standards.
Octal Fat Pipe See Pipe.
OFP Octal Fat Pipe. See Pipe.
Payload Module See Module.
Payload Slot See Slot
PCIe® PCI EXPRESS®. See http://www.pcisig.com The following terms are

commonly associated with PCIe
Downstream Port: A port facing away from the Root Complex.
Endpoint: A device at an end-node of a PCIe hierarchy. It is analogous to
an I/O device in a conventional PCI system. A PCIe device function that
has a Type 00h Configuration Space header is an end-node.
Non-Transparent Port: A PCIe port that contains the functionality of a
non-transparent PCI bridge. The system behind the port and the PCIe link
have separate address spaces. It is used to connect PCIe hierarchies
together.
PCIe Common Reference Clock: A clock that is distributed to multiple
PCIe end points. In particular the receiver of PCIe lanes uses a Common
Clock as opposed to having its own local clock. See Figure 4-49
(Common Refclk Rx Architecture) in [PCIe 2 Base].
Root Complex: The device at the top of a PCIe hierarchy. It is analogous
to the host bridge of bus 0 in a conventional PCI system.
Transparent Port: A PCIe port in which the system behind the port and
the PCIe link share the same address space.
Upstream Port: A port facing towards the Root Complex.
Peripheral Module See Module.
Peripheral Slot See Slot

Term Definition
Pipe A physical aggregation of differential pairs used for a common function
that is characterized in terms of the total number of differential pairs. A
Pipe is not characterized by the protocol used on it. The following Pipes
are predefined by OpenVPX:
Ultra-Thin Pipe (UTP): A Pipe comprised of two differential pairs.
Example: 1000BASE-KX Ethernet, 1x Serial RapidIO, and x1 PCIe
interfaces.
Thin Pipe (TP): A Pipe composed of four differential pairs. Example:
1000BASE-T interfaces.
Fat Pipe (FP): A Pipe composed of eight differential pairs. Example: 4x
Serial RapidIO, x4 PCIe, and 10GBASE-KX4 interfaces.
Double Fat Pipe (DFP): A Pipe composed of sixteen differential pairs.
Example: x8 PCIe interface.
Triple Fat Pipe (TFP): A Pipe composed of twenty-four differential
pairs. Example: 12x InfiniBand interface.
Quad Fat Pipe (QFP): A Pipe composed of thirty-two differential pairs.
Octal Fat Pipe (OFP): A Pipe composed of sixty-four differential pairs.
Plane A physical and logical interconnection path between elements of a system
used for the transfer of information between elements. The following
Planes are predefined by OpenVPX:
Control Plane: A Plane that is dedicated to application software control
traffic.
Data Plane: A Plane that is used for application and external data traffic.
Expansion Plane: A Plane that is dedicated to communication between a
logical controlling system element and a separate, but logically adjunct,
system resource.
Management Plane: A Plane that is dedicated to the supervision and
management of hardware resources. Functional definitions for this Plane
are provided in the [VITA 46.11] specification.
Utility Plane: A Plane that is dedicated to common system services
and/or utilities.
Plug-In Module See Module.
Port A physical aggregation of pins for a common I/O function on either a
Plug-In Module’s backplane Connectors or a backplane slot’s Connectors.

Term Definition
Profile Backplane Profile: A physical definition of a backplane implementation
that includes details such as the number and type of slots that are
implemented and the topologies used to interconnect them. Ultimately a
Backplane Profile is a description of Channels and Buses that interconnect
slots and other physical entities in a backplane.
Standard Development Chassis Profile: A physical definition of a
Standard Development Chassis implementation that includes details such
as the chassis type, slot count, primary power input, module cooling type,
Backplane Profile, and supplied backplane power, that are implemented in
the Standard Development Chassis Profile.
Module Profile: A physical mapping of Ports onto a given Module’s
backplane Connectors and protocol mapping(s), as appropriate, to the
assigned Port(s). This definition provides a first-order check of operating
compatibility between Modules and slots as well as between multiple
Modules in a Chassis. Module Profiles achieve the physical mapping of
ports to backplane connectors by specifying a Slot Profile. Multiple
Module Profiles can specify the same Slot Profile.
Slot Profile: A physical mapping of Ports onto a given slot’s backplane
connectors. These definitions are often made in terms of Pipes. Slot
Profiles also give the mapping of Ports onto Plug-In Module’s backplane
connectors. Unlike Module Profiles, a Slot Profile never specifies
protocols for any of the defined Ports.
QFP Quad Fat Pipe. See Pipe.
Quad Fat Pipe See Pipe.
PCIe Common See PCIe
Reference Clock
Root Complex See PCIe
RTM Rear Transition Module. A Plug-In Module intended to provide additional
I/O breakout options. RTMs are mated to the rear side of a backplane,
hence the name.
SAS Serial Attached SCSI (Small Computer System Interface). See
http://www.t10.org/
SATA Serial ATA (Advanced Technology Attachment). A serial interface
typically used to connect to storage devices. See http://www.sata-io.org

Term Definition
Slot A physical space on a OpenVPX backplane with a defined mechanical
and electrical specification intended to accept a Plug-In module.
Preexisting examples of slots that are applicable to OpenVPX include 6U
and 3U. Additionally, the following slot types are defined by OpenVPX:
Bridge Slot: A space in an OpenVPX system that will accept a Bridge
Module that provides communication paths between multiple Plug-In
Modules that support different Plane protocols and/or implementations.
Payload Slot: A space in an OpenVPX system that will accept a Payload
Plug-In Module such as, but not limited to, a hardware processing and/or
I/O Plug-In Module.
Peripheral Slot: A space in an OpenVPX system that will accept a
Peripheral Plug-In Module that is usually subservient to a Payload
Module.
Storage Slot: A space in an OpenVPX system that will accept a Storage
Plug-In Module, such as a module providing the functionality of a disk
drive.
Switch Slot: A space in an OpenVPX system that will accept a Switch
plug-in Module.
Slot Profile See Profile.
SRIO Serial RapidIO®. See http://www.rapidio.org
Standard Development A chassis for use in an controlled environment such as a laboratory or
Chassis office. The OpenVPX specification defines Standard Development
Chassis Profiles to address common engineering development,
integration, and test activities. However, there are no restrictions on how
any OpenVPX Standard Development Chassis Profile can be used. Note:
There may also be development chassis that are beyond the scope of this
specification that are for targeted for particular applications.
Storage Module See Module.
Storage Slot See Slot
Switch Module See Module.
Switch Slot See Slot
TFP Triple Fat Pipe. See Pipe
Thin Pipe See Pipe.

Term Definition
TP Thin Pipe. See Pipe.
Triple Fat Pipe (TFP) See Pipe
Ultra-Thin Pipe See Pipe.
Upstream Port See PCIe.
User I/O Plug-In Module Ports that are defined by application requirements beyond
the Control Plane, Data Plane, Expansion Plane, Management Plane, and
Utility Plane physical implementations. User I/O Ports are typically
implemented as rear transition area access Ports but might also be
implemented as application-specific backplane interconnections between
slots and/or other backplane entities.
Utility Plane See Plane.
UTP Ultra-Thin Pipe. See Pipe.
Verification Verification is accomplished by one or more of several accepted methods:
Inspection, Demonstration, Analysis, Test.
1.3.3 Profile Names – Use and Construction

This informative section provides a description of Profile Names that are used throughout this
document. OpenVPX profiles can be classified into one of three main categories:
• Slot (SLT)
• Backplane (BKP)
• Module (MOD)
Each profile is assigned a unique name as described in the sections below.

1.3.3.1 Slot Profiles
Slot Profiles use the naming format as per Figure 1.3.3.1-1. Note the ‘Fabric Information’
parameter in the SLT profile name is read from J0 to J2 (3U) or J6 (6U) (or equivalent for
alternate connectors) as pipes are encountered.
Categorization Module OpenVPX Doc

Type Type Section
Form Fabric
Factor Information
SLTu-WWW-xYxY-z.z.z
Port Port
Quantity Size
Figure 1.3.3.1-1 Slot Profile Name Construct
The parameters in Figure 1.3.3.1-1 are described below:
SLT Slot Category

u Form-factor {3 | 6}
Where 3 = 3U VPX
6= 6U VPX
WWW Slot Type {BRG | PAY | PER | STO| SWH}
Where BRG = Bridge card
PAY = Payload card
PER = Peripheral card
STO = Storage card
SWH = Switch card
Note: The following pattern “xY” is repeated for each set of pipes defined by the slot profile.
Only two example pipes are shown in Figure 1.3.3.1-1, however there can be more or less,
depending on the slot definition.
x Port Quantity {1 to n}

Y Port Size {U | T | F | D | Q | O | V }
Where U = UTP
T= TP
F= FP
D= DFP
Q= QFP
O= OFP
V= VME
R= RF/analog coaxial
z.z.z OpenVPX section number
1.3.3.2 Backplane Profiles

The Backplane Profiles use the naming format as per Figure 1.3.3.2-1.
OpenVPX Doc
Categorization Topology sub-section
Type Total Configuration
Form Slot Sequence
Factor Count Number
BKPu-XXXyy-z.z.z-m
Figure 1.3.3.2-1 Backplane Profile Name Construct
The parameters Figure 1.3.3.2-1 in are described below.
BKP Backplane
u Form-factor {3 | 6 }
Where 3 = 3U VPX
6= 6U VPX
XXX Topology of Data Plane {CEN | DIS | HYB } (See Section 1.3.4)
Where CEN = Centralized topology
DIS = Distributed topology
HYB = Hybrid topology

yy Total Slot Count {01 to 20}
m A sequence number assigned each variant of backplane configuration to
uniquely identify it within the backplane profile section {1 to n}
1.3.3.3 Module Profiles

Module Profiles use the naming format as per Figure 1.3.3.3-1. Note the ‘Fabric Information’
parameter in the MOD profile name is read from P0 to P2 (3U) or P6 (6U) (or equivalent for
alternate connectors) as pipes are encountered.
OpenVPX Doc
Categorization Module Section
Type Type Configuration
Form Fabric Sequence
Factor Information Number
MODu-WWW-xYxY-z.z.z-m
Port Port
Quantity Size
Figure 1.3.3.3-1 Module Profile Name Construct
The parameters Figure 1.3.3.3-1 in are described below:

MOD Module
u Form-factor {3 | 6}
Where 3 = 3U VPX
6= 6U VPX
WWW Module Type {BRG | PAY | PER | STO| SWH}
Where BRG = Bridge card
PAY = Payload card
PER = Peripheral card
STO = Storage card
SWH = Switch card

Note: The following pattern “xY” is repeated for each set of pipes defined by the module profile.
Only two example pipes are shown in Figure 1.3.3.3-1, however there can be more or less,
depending on the module definition
x Port Quantity {1 to n}
Y Port Size {U | T | F | D | Q | O | V }
Where U = UTP
T= TP
F= FP
D= DFP
Q= QFP
O= OFP
V= VME
R= RF/analog coaxial
m A sequence number assigned each variant of module profile configuration
to uniquely identify it within the module profile section {1 to n}

1.3.4 Backplane Profile Topologies
The first part of this section goes through topologies in general (Figure 1.3.4-1 thru Figure 1.3.4-
8). Starting with Section 1.3.4.1, the part of the Backplane Profile naming, that reflects topology
is explained.
Figure 1.3.4-1 thru Figure 1.3.4-4 give examples of Star Topologies. A Star is where Payload
Slots are connected through centralized Switch Slots. Note: For the purpose of the discussion in
this Section, a Peripheral Slot is considered a type of Payload Slot.
• A Single Star is where there is a single Switch Slot and every Payload Slot is connected to
this Switch Slot. See Figure 1.3.4-1.
• A Dual Star, using two Switch Slots (or Redundant Star), is where there are two Switch
Slots and every Payload Slot is connected to both Switch Slots. There are generally links
between the Switch Slots as well, but this is not needed to be a Dual Star. See Figure 1.3.4-
2.
• A Dual Star, using a single Switch Slot, is where there is a single Switch Slot and every
Payload Slot is connected to the Switch Slot with two links (pipes). See Figure 1.3.4-3.
• An Extended Star is a star topology where some or all of the Payload Slots are connected
to the Switch Slot through intermediate hops. See Figure 1.3.4-4.
Figure 1.3.4-1 Example of Single-Star Topology

Figure 1.3.4-2 Example of Dual-Star Topology using two Switch Slots
Figure 1.3.4-3 Example of Dual-Star Topology using a Single Switch Slot

Figure 1.3.4-4 Example of Extended-Star Topology

Figure 1.3.4-5 and Figure 1.3.4-6 give examples of Mesh topologies. A Mesh Topology is where
Payload Slots are directly connected to other Payload Slots, without the use of a centralized
Switch Slot.
• A Full Mesh is a mesh topology in which every Payload Slot is directly connected to
every other Payload Slot. See Figure 1.3.4-5.
• A Partially Mesh is a Mesh Topology in which not all Payload Slots are directly
connected to each other. In this case they are connected through one or more intermediate
Payload Slots. See Figure 1.3.4-6.
Figure 1.3.4-5 Example of Full Mesh Topology
Figure 1.3.4-6 Example of Partial Mesh Topology

Figure 1.3.4-7 gives examples of Daisy-Chain topologies. A Daisy-Chain topology is where
slots are connected linearly, so that there is a single path between one end of the chain and the
other.
Figure 1.3.4-7 Examples of Daisy-Chain Topologies
Figure 1.3.4-8 gives examples of Ring topologies. A Ring topology is similar to a Daisy-Chain,
except that the ends of the chain are connected to each other to form a ring.
Figure 1.3.4-8 Examples of Ring Topologies

Section 1.3.3.2 gives the construction of Backplane Profile names. The Sections that follow
define the topology field of the Backplane Profile names in more detail. The topology of the
Data Plane is used as the primary differentiator among the topologies of the Backplane Profiles.
The topologies are as follows:
1.3.4.1 CEN — Centralized

The topology is a star, with one or more centralized switches. Generally one or more Switch
Slots is the center of the star with Payload Slots as the points. For generic topologies, of this
type, see Figure 1.3.4-1, Figure 1.3.4-2, Figure 1.3.4-3, and Figure 1.3.4-4. For examples of
Backplane Profiles, see:
• 11.2.2 16-Slot — BKP6-CEN16-11.2.2-n (14 Payload + 2 Switch)
• 15.2.12 6-Slot — BKP3-CEN06-15.2.12-n (1 Payload + 4 Peripheral + 1 Switch)
Instead of the center of the star being a Switch Slot, it can also be a Payload Slot. Typically in
these cases the Payload Slot is intended for a Plug-In Module, something like an SBC (Single
Board Computer) that connects to multiple Peripheral Slots. Such a Plug-In Module at the center
of the star might just connect to the points of the star or it might have a Switch that enables peer-
to-peer traffic among the points of the star. PCIe is a common protocol for systems based on
these types of topologies. Some examples of these are:
• 11.2.13 9-Slot — BKP6-CEN09-11.2.13-n (1 Payload + 8 Peripheral)

1.3.4.2 DIS — Distributed Topology
These are topologies that are intended to be used by Plug-In modules that each contribute to the
Switching as opposed to having centralized resources for Switching. These can be mesh, daisy-
chain, ring topologies, or some combination. For generic topologies, of this type, see Figure
1.3.4-5, Figure 1.3.4-6, Figure 1.3.4-7, and Figure 1.3.4-8. For examples of Backplane Profiles,
see:
• 11.2.10 6-Slot — BKP6-DIS06-11.2.10-n (5 Payload + 1 Switch)
• 11.2.16 5-Slot — BKP6-DIS05-11.2.16-n (5 Payload)
• 15.2.8 2-Slot — BKP3-DIS02-15.2.8-n (1 Payload + 1 Peripheral)
• 15.2.13 5-Slot — BKP3-DIS05-15.2.13-n (3 Payload + 2 Peripheral)
• 15.2.14 6-Slot — BKP3-DIS06-15.2.14-n (5 Payload + 1 Switch)
1.3.4.3 HYB — Hybrid Topology

These are topologies that are a hybrid between a point-to-point switched topology and a bussed
topology. The point-to-point switched topology might be either Centralized or Distributed. The
bussed might be something like VME bus. Some examples of these are:
• 11.2.11 17-Slot — BKP6-HYB17-11.2.11-n (12 Payload + 3 VME + 2 Switch)
• 11.2.12 8-Slot — BKP6-HYB08-11.2.12-n (1 Payload + 3 Peripheral + 1 VME Bridge +
3 VME)
1.4 Adding New Profiles to this Standard

To add new profiles to this standard, contact the VITA Technical Director, who can put you in
touch with the appropriate members of the VITA 65 Working Group. The address for the VITA
Technical Director is given in the “Comments, Corrections, and/or Additions” Section in the
front matter of this document.
1.5 References
The publications listed in this Section are referenced by this standard. Unless otherwise
specified, use the latest revision. In the event that section numbers change, with a revision of a
referenced specification, the referenced version can be used to see the intended content to be
referenced, then that content can be found in the latest revision.

1.5.1 VITA Standards
The standards, in the following list, that are VITA xx are available from the VMEbus
International Trade Association (http://www.vita.com):
[VITA 1.1] ANSI/VITA 1.1-1997 American National Standard for VME64 Extensions
[VITA 46.0] ANSI/VITA 46.0-2007 VPX Baseline Standard
[VITA 46.1] ANSI/VITA 46.1-2007 for VMEbus Signal Mapping on VPX
[VITA 46.3] Currently in draft form, Serial RapidIO® on VPX Fabric Connector; Draft
Revision 0.13, Feb. 27, 2012
[VITA 46.4] Currently in draft form, PCI EXPRESS® on VPX Fabric Connector; Draft
Revision 0.15, July 21, 2010
[VITA 46.6] VITA Draft Standard for Trial Use, Gigabit Ethernet Control Plane on VPX;
Draft Revision 0.7, Sept. 22, 2010, Trial Use expires March 22, 2012
[VITA 46.7] Currently in draft form, Ethernet on VPX Fabric Connector; Draft Revision
0.11, Jan. 31, 2012
[VITA 46.8] VITA Draft Standard for Trial Use, InfiniBand® on the VPX Fabric Connector;
Revision 0.11, May 24, 2011, Trial Use expires May 24, 2014
[VITA 46.9] ANSI/VITA 46.9-2010 PMC/XMC Rear I/O Signal Mapping on 3U and 6U
VPX Module
[VITA 46.10] ANSI/VITA 46.10-2009, Rear Transition Module on VPX
[VITA 46.11] Currently in draft form, System Management for VPX; Draft Revision 0.6,
Jan. 20, 2012
[VITA 48.0] ANSI/VITA 48.0-2010 Mechanical Specifications for Microcomputers Using
Ruggedized Enhanced Design Implementation (REDI)
[VITA 48.1] ANSI/VITA 48.1-2010 Mechanical Specifications for Microcomputers Using
REDI Air Cooling
[VITA 48.2] ANSI/VITA 48.2-2010 Mechanical Specification for Microcomputers Using
REDI Conduction Cooling Applied to VITA VPX
[VITA 65-2010] ANSI/VITA 65-2010, OpenVPX™ System Specification
[VITA 67.0] ANSI/VITA 67.0-2012, Coaxial Interconnect on VPX - Base Standard
[VITA 67.1] Currently in draft form, Coaxial Interconnect on VPX, 3U, 4 Position SMPM
Configuration; Draft Revision 1.11, Jan. 10, 2012
[VITA 68] Currently in draft form, VITA 68.0 VPX Compliance Channel; Draft Revision
0.27, Sept 1, 2011

1.5.2 Other Standards
Other standards referenced by this document:
[ANSI B46.1] ANSI B46.1-2009 Surface Texture, Surface Roughness, Waviness and Lay;
http://www.ansi.org/
[IEEE 802.3] IEEE Std 802.3TM-2008 IEEE Standard for Information technology—
Telecommunications and information exchange between systems—Local and metropolitan
area networks—Specific requirements Part 3: Carrier Sense Multiple Access with Collision
Detection (CSMA/CD) access method and Physical Layer specifications;
http://standards.ieee.org/
[PCIe 2 Base] PCI Express® Base Specification; Rev 2.1, March 4, 2009
http://www.pcisig.com/
[PCIe 2 CEM] PCI Express® Card Electromechanical Specification; Rev 2.0, April 11, 2007
http://www.pcisig.com/
[TIA/EIA 899] TIA/EIA (March 2002) Electrical Characteristics of Multipoint-Low-
Voltage Differential Signaling (M-LVDS) Interface Circuits for Multipoint Data
Interchange; http://www.tiaonline.org/
1.6 Order of Precedence

Rule 1.6-1: In the event of a conflict between requirements of this standard and any
referenced standards or documentation, this standard shall take precedence. [VM = VNR]

2 OpenVPX Compliance
2.1 Compliance
Product compliance is a cornerstone of the OpenVPX system philosophy. A product’s
performance must be verified to all requirements listed in applicable profile(s) in order to claim
compliance to this specification.
Rule 2.1-1: All requirements listed or referenced in an applicable slot, backplane, module
and/or Chassis Profile shall be verified that it meets all requirements listed for a product to
claim compliance to the OpenVPX specification. [VM = VNR]
Rule 2.1-2: All procedures used, and results of verification shall be documented and
controlled. [VM = VNR]
Permission 2.1-1: A supplier may use a similarity argument to establish conformity for a
specific Rule, Recommendation, and Permission if the implementation of the interface or
function has previously established conformity with the same Rule, Recommendation, and
Permission on a similar item.
2.1.1 Statement of Compliance

Any supplier of a product claiming compliance to this specification must provide, on request, a
statement of compliance which clearly indicates the following from applicable profiles:
a) Rules plus verification outcome (Pass/Fail),
b) The state of Recommendations and Permissions (implemented/did not implement), and
verification outcome (Pass/Fail).
In the event of a dispute arising between a product’s performance to the specification and the
claim of compliance, a user might request evidence of conformity for only those requirements in
dispute. The evidence of conformity might contain intellectual property or industrial secrets of a
highly proprietary nature, and therefore any user, before executing a request of this nature, needs
to verify both Non-Disclosure Agreements, and any contractual restrictions that might exist.
Rule 2.1.1-1: For any product claiming compliance to this specification, the supplier shall
provide, on request, a Statement of Compliance. [VM = VNR]

2.1.2 Verification Method Notation
At the end of each Rule and Recommendation in section 3 and on, the verification method is
specified and denoted as follows:
[VM = vmlist]
Where:
VM = Verification Method,
vmlist = Verification Method List
The Verification Method List consists of one or more of the following: I (Inspection), D
(Demonstration), A (Analysis), T (Test), VNR (Verification Not Required), and are listed in the
recommended order. For example:
[VM = I] means Inspection only
[VM = D,A,T] means Demonstration is recommended, Analysis and Test are permitted
[VM = T,D] means Test is recommended, Demonstration is permitted
[VM = VNR] means Verification Not Required.
Each of the four methods of verification are described in section 2.2
2.1.3 Compatibility
Items claiming compatibility will have the characteristic of Interoperability, albeit with less
functionality. That is, they might have less or smaller pipes, or operate at slower speeds but will
still meet the basic requirements across an interface. A product might also claim compatibility
even though an interface is not implemented, for example Module Maskable Reset or Expansion
Bus, as long as that item does not impair other items from implementing that functionality.
2.2 Methods
This specification uses up to four methods to establish conformity to each requirement:
Inspection, Demonstration, Analysis, and Test. Each are described below. If one or more
method is permitted, the supplier’s choice of method will be governed by the applicable section
text, under the conditions stated in each Rule, Recommendation, or Permission.
Rule 2.2-1: Conformity shall be conducted using the method and the condition(s) indicated
within each Rule, Recommendation, or Permission. [VM = VNR]
Rule 2.2-2: If VM = VNR, no verification shall be required. [VM = VNR]
Permission 2.2-1: When more than one method is indicated the supplier may choose which
method best fits their internal processes.

Vita 65 Openvpx 31 60

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Vita 65 Openvpx 31 60

Hochgeladen von

Copyright:

Verfügbare Formate

1.1.

Table 1.1-1 OpenVPX Profile Relationships

Communication Protocols Communication Plane

1.2 OpenVPX Document Structure Description

ANSI/VITA 65-2010 (R2012) Page 31 of 555 February 2012

Slot Profiles Slot Profiles

Module Profiles Module Profiles

Figure 1.2-1 Profile Tree Structure

Section 5.1: Ethernet Section 5.2: Section 5.3: Section 5.4:

Figure 1.2-2 Protocol Specific Structure

ANSI/VITA 65-2010 (R2012) Page 32 of 555 February 2012

Section 6.3: Common Requirements for Slot Profiles using

Section 6.4: Common Requirements for Slot Profiles using

Section 10.1: Common Section 14.1: Common

Sections 10.2 – 10.5:

Figure 1.2-3 Slot Profile Structure

ANSI/VITA 65-2010 (R2012) Page 33 of 555 February 2012

Section 11.1: Common Section 15.1: Common

Backplane Backplane Backplane

Backplane Backplane Backplane

Backplane Backplane Backplane

Figure 1.2-4 Backplane Profile Structure

ANSI/VITA 65-2010 (R2012) Page 34 of 555 February 2012

Section 12.1: Common Section 16.1: Common

Modules Modules Modules

Modules Modules Modules

Modules Modules Modules

Figure 1.2-5 Module Profile Structure

ANSI/VITA 65-2010 (R2012) Page 35 of 555 February 2012

Section 9.2: 6U/3U VITA 48.1 Air-Cooled Dev. Chassis

Section 9.3: 6U/3U VITA 48.2 Conduction-Cooled Dev. Chassis

Section 13.1: Common Section 17.1: Common

Section 13.1.1: VITA 48.1 Section 17.1.1: VITA 48.1

Section 13.1.2: VITA 48.2 Section 17.1.2: VITA 48.2

Sections 13.2: Based 6U Sections 17.2: Based 3U

Figure 1.2-6 Standard Development Chassis Profile Structure

1.3.1 Specification Key Words

ANSI/VITA 65-2010 (R2012) Page 36 of 555 February 2012

1.3.1.1 Rule <section>-<number>:

1.3.1.2 Recommendation <section>-<number>:

1.3.1.3 Suggestion <section>-<number>:

1.3.1.4 Permission <section>-<number>:

1.3.1.5 Observation <section>-<number>:

Table 1.3.2-1 Glossary

ANSI/VITA 65-2010 (R2012) Page 38 of 555 February 2012

ANSI/VITA 65-2010 (R2012) Page 39 of 555 February 2012

ANSI/VITA 65-2010 (R2012) Page 40 of 555 February 2012

PCIe® PCI EXPRESS®. See http://www.pcisig.com The following terms are

ANSI/VITA 65-2010 (R2012) Page 41 of 555 February 2012

ANSI/VITA 65-2010 (R2012) Page 42 of 555 February 2012

ANSI/VITA 65-2010 (R2012) Page 43 of 555 February 2012

ANSI/VITA 65-2010 (R2012) Page 44 of 555 February 2012

1.3.3 Profile Names – Use and Construction

Each profile is assigned a unique name as described in the sections below.

ANSI/VITA 65-2010 (R2012) Page 45 of 555 February 2012

Categorization Module OpenVPX Doc

Figure 1.3.3.1-1 Slot Profile Name Construct

The parameters in Figure 1.3.3.1-1 are described below:

SLT Slot Category

ANSI/VITA 65-2010 (R2012) Page 46 of 555 February 2012

1.3.3.2 Backplane Profiles

Figure 1.3.3.2-1 Backplane Profile Name Construct

The parameters Figure 1.3.3.2-1 in are described below.

ANSI/VITA 65-2010 (R2012) Page 47 of 555 February 2012