Overview of Space VPX

Ten facts you need to know about SpaceVPX

1. Every connection between SpaceVPX boards through the backplane is point-to-point; there are no buses in the system, limiting the propagation of failures through many components. Even power rails are point-to-point.
2. SpaceVPX systems have no single points of failure because modules and connections between modules are redundant.
3. The standard defines many serial links per node (SpaceVPX board), supporting simultaneous communications between different nodes in the system, and between one node and many other nodes through the use of multiple serial links. These multiple links also add redundant paths between two ​nodes, either via direct connection of more than one link between two nodes or via indirect connection through a third node.
4. The SpaceVPX standard inherits the OpenVPX definition of Pipes, a physical aggregation of differential pairs used for a common function. The SpaceVPX defines Ultra-Thin Pipe (UTP), Thin Pipe (TP), Fat Pipe (FP), Double Fat Pipe (DFP), Triple Fat Pipe (TFP), Quad Fat Pipe (QFP), and Octal Fat Pipe (OFP), comprising 2, 4, 8, 16, 24, 32, 64 differential pairs respectively. These are full duplex interfaces (one pair Tx, another Rx); each pair of differential signals will be referred as a lane. A Pipe or lane are not characterized by the protocol used on it.
5. The standard also defines the concept of Plane, a physical and logical interconnection path between elements of a system used for the transfer of information between elements. The standard defines a Control Plane dedicated to application software control traffic, a Data Plane used for application and external data traffic, an Expansion Plane dedicated to communication between a logical controlling system element and a separate, but logically adjunct, system resource, and a Utility Plane dedicated to common system services and/or utilities. Each Plane is composed of one or more Pipes, except for the Utility Plane which is low speed.
6. Thanks to the serial links, the Data Plane supports multiple topologies, including mesh, star, and double star. This brings a lot of flexibility to the system and allows for optimizing the system for performance, reliability, or both.
7. There are several modules defined in the standard, including: Controller, Payload, Peripheral, and Switch. At bare minimum, a SpaceVPX system consists of one controller and one payload or peripheral. The figure at the end of this page shows the pins definition for two widely used profiles.
8. The two slot profiles shown above specify the way the pins in the SpaceVPX connector are assigned to the different Planes defined in the standard. For example, the SLT3-CON-2F8T-14.6.1 profile has 8 TPs (4 differential pairs each) to control the activity in the subsystem through the Control Plane and the SLT3-PAY-2F1Q2T-14.2.1 has only 2 Pipes for redundancy. Both profiles have only 2 Data Plane FPs (8 differential pairs each). In addition, the SLT3-CON-2F8T-14.6.1 profile drives the signals that are connected to the Space Utility Management module (SpaceUM), such as clocks and resets of the Utility Plane.
9. As shown, there are not many UD pins in the 3U form factor. In the Payload profile, there are enough UD pins for most applications but in the Controller profile, there are only a few. This can be an issue when a system needs a dumb peripheral board or an RTM module on the back of the Backplane connected through these UD pins to the SpaceVPX module. This is the case when cycle accurate synchronism signals are needed or when there is no IO expansion device in the peripheral or RTM module. This could prevent the Controller of the chassis from implementing any interface beyond the ones defined in the standard, becoming a roadblock in most systems.
10. The profiles shown in Figure 1 are optimize to reduce SWaP; however, there is a small number of User Defined pins. We published a paper in the SmallSats journal with recommendations to address this limitation. Please, take a look at the paper or contact us to further discuss this.

Note: It is worth noting that the word “Payload” in the standard refers to its role in the SpaceVPX system, independently of the role that the SpaceVPX system performs on the satellite (payload subsystem or bus subsystem). In this guide, “Payload” with the first letter in upper case refers to the SpaceVPX module and “payload” with lower case letters refers to the subsystem. Similarly, the word “Controller” refers to the System Controller module defined in the SpaceVPX standard independently of its use in different subsystems.