Before the advent of OpenVPX, designers of embedded systems took advantage of the extreme connectivity offered by VPX (VITA 46), but were faced with a virtually unlimited number of possible implementations. Specific choices for the control and data channel assignments for each slot, the backplane connectivity, and serial fabrics were often made somewhat arbitrarily to suit the particular needs of the current system. Although following the general framework of VITA 46, each system tended to be so unique that the boards and backplanes designed for one system were seldom usable in other systems, even from the same vendor.
Now, OpenVPX (VITA 65) provides an effective taxonomy for describing VPX components, and also defines numerous “profiles” for boards, slots and backplanes that detail specific configurations of channels, interconnections, and fabrics. Instead of starting from scratch each time, designers can browse through these standardized profiles to find one that satisfies the objectives of each new system. By narrowing the field of configurations, these profiles boost reusability and interoperability between vendors.
A multichannel software radio beamforming receiver system is presented as an example that illustrates how the OpenVPX system design process works. Principles from this example can be easily applied to other systems.
Beamforming is extensively used in communications, radar, direction finding, countermeasures, weapons systems, oil and mineral exploration, and medical imaging and treatment. In essence, beamforming utilizes multiple sensors to achieve directionality of the sensor array, and also to improve the signal quality and reception range.
Beamforming achieves these benefits by judiciously adjusting the phase shift and gain of each sensor so that, when the adjusted sensor signals are combined, they add constructively. For receivers, the combination is performed by summing the adjusted signals from each sensor. For transmitters, each sensor delivers a signal that adds constructively at the destination.
Defining System Requirements
The sensors in a software radio receiver system for beam forming are antennas arranged in a linear or two-dimensional array. The term “software” in software radio refers to the programmability of the digital signal processing functions including the digital down conversion, phase shifting, gain adjustments, summation of the received channels, and then the ultimate demodulation, decoding, and/or decryption of the acquired signal.
The example system requires sixteen antennas, each followed by an RF stage to amplify and down convert the radio frequency signal to an intermediate frequency (IF) analog signal so it can be digitized by an A/D converter. These sixteen IF signals are supplied as inputs to the system.
Each IF signal has a bandwidth of 20 MHz and is centered at 70 MHz. After A/D conversion, all sixteen channels are down converted to baseband and beamformed using gain and phase shift parameters to comply with operational objectives. The final beamformed sum is delivered as a baseband signal to a remote system control processor PC for additional processing, forwarding, or storage.
The system must operate in a limited space avionics equipment bay and must comply with typical shock, vibration, temperature, altitude, humidity, flight safety, power consumption, power supply, and EMC/EMI standards.
Choosing the OpenVPX Payload Module for Beamforming
Since industry standard chassis are available in both 3U and 6U sizes, and both are well defined for OpenVPX, the small avionics bay requirement favors the 3U style. The next tasks are to select the appropriate 3U software radio and processor modules (boards) to perform the beamforming, define the required connections between the modules, select a 3U backplane to support those interconnections, a chassis to meet the physical and environmental requirements, and a link between the chassis and the remote system control processor PC.
For example, Pentek’s Model 5353 Software Radio Beamformer is a 3U OpenVPX module featuring four 200 MHz 16-bit A/D converters and two Virtex-5 FPGAs, one for signal processing and a second one for the PCI interface. Inside the first FPGA are interfaces to the four A/D converters, four digital downconverters (DDCs) with programmable phase shift and gain, and four power meters at each DDC output. A simplified block diagram of the 5353 is shown in Figure 2.
The Model 5353 also includes a summation block that adds the DDC outputs for a four-channel beamforming sum. This block also accepts a propagated sum in signal from another module and generates a propagated sum signal out to the next module. The sum in/sum out signals use two X4 Aurora gigabit serial links connected to the VPX P1 backplane connector, each capable of moving data at 1.25 GB/sec peak.
To support the 20 MHz IF channel bandwidth with a 25% filter margin, the DDC outputs deliver complex 16-bit I+Q samples at 25 MHz, or 100 MB/sec. The propagated sum in/sum out signals also operate at 100 MB/sec and are thus easily handled by the 1.25 GB/sec X4 Aurora links.
The 5353 system interface for control and data is an X4 PCIe port, also connected to P1. Bandwidth requirements for the control and data port are dominated by delivery of the final beamformed sum out to the control processor. This 100 MB/sec stream falls well within the 2 GB/sec peak rate of the X4 PCIe port when operating in Gen 2 mode.
A programmable, fabric-transparent crossbar switch allows free assignment of the two X4 Aurora ports and the X4 PCIe port, in any combination, to the four X4 fat pipes of P1. This flexibility allows the 5353 to accommodate various OpenVPX slot profiles and backplanes.
To accommodate 16 antennas, a total of four 4-channel 5353 modules are required. Since the summation chain requires the same data rate as each DDC, the two sum ports must simultaneously handle 100 MB/sec each. This class of signals falls under the definition of expansion plane in the OpenVPX specification.
The X4 PCIe interface for handling the data initialization, delivery of beamforming parameters is described as the control plane under OpenVPX. Final delivery of the beamformed result to the system control processor is best classified as the data plane under OpenVPX.
Choosing the OpenVPX Backplane
OpenVPX backplanes use many different topologies named after the geometry of their interconnections, including mesh, star, leaf, and ring. Most include slots for switch modules to support reconfigurable inter-board connections, while some simply rely on dedicated wiring between the slots.
After reviewing the 3U OpenVPX backplane choices in the standard, the most appropriate for our system is the 6-Slot backplane profile BKP3-CEN06-15.2.2-1, which has five payload slots and one switch slot as shown in Figure 3.
The expansion plane fat pipes join adjacent payload slots 1 through 5 to support the sum in and sum out chaining ports between 5353 modules. One data plane fat pipe from each payload slot to the switch slot 6 supports the four X4 PCIe links we need to the control processor.
This backplane defines specific slot profiles for the two types of slots. Slots 1 through 5 use the payload slot profile SLT3-PAY-1F2F2U-14.2.2 shown in the upper right section of Figure 3. To see if we can use the Model 5353 in the payload slots, we must verify that the Model 5353 has a module profile compatible with this slot profile.
It is important to note that the backplane profiles and slot profiles do not specify any fabric or protocol for the connections. However, the backplane profile does specify the maximum baud rate for each gigabit serial pipe. This scheme allows a wide variety of modules to be used in a given backplane slot, each with its own particular fabric and baud rate. Of course, the baud rate of each pipe of the module must be equal to or less than the maximum baud rate specified in the backplane profile.
Because of its programmable crossbar switch, the Model 5353 can be configured to meet the module profile MOD3-PAY-1F2F2U-16.2.2-4, which is compatible with the slot profile SLT3-PAY-1F2F2U-14.2.2. This module profile defines data, expansion and control plane fabric connections and baud rates. The backplane profile BKP3-CEN06-15.2.2-1 defines a single fat pipe (X4) on the DP01 data plane for PCIe Gen 2 that corresponds directly to the PCIe interface as shown in Figure 4.
The eight expansion plane ultra thin pipes, EP01 through EP08, are also defined as PCIe Gen 2, capable of operating at baud rates of 5 GHz. We will organize these eight pipes as two fat pipes for the two X4 Aurora ports for sum in and sum out, which need to operate at only 3.125 GHz. The two control plane ports, CPutp01 and CPutp02, are not implemented on the 5353.
Choosing the OpenVPX Switch/Interface Module
The selected backplane also has a switch slot with profile SLT3-SWH-6F6U-14.4.1, whose VPX P1 connections are shown in the bottom right section of Figure 3. The four data plane fat pipes shown (DP01 — DP04) connect to payload slot fat pipes DP01 on slots 1 through 4.
Now we need to find a compatible switch module that can plug into slot 6 and connect these four PCIe links to the remote system control processor. Pentek’s Model 5308 PCIe Cable Adapter is a 3U VPX switch module with a front panel X8 PCIe cable connector defined by the PCI-SIG PCI Express® External Cabling 1.0 Specification. Compatible PCIe host adapters are available for many different systems including PCIe cards for desktop PCs as well as avionics cockpit computers.
The 5308 features a PCIe switch that supports flexible lane bonding so that a single X4 or X8 PCIe port from the control processor PC can be split into four X4 PCIe ports to four individual PCIe endpoints. The fabric-transparent crossbar switch joins these four X4 ports to the VPX1 P1 backplane connector, fully compatible with OpenVPX module profile MOD3-SWH-4F-16.4.5-2 shown in Figure 6.
Inspection reveals that this module profile is fully compatible with the four VPX P1 fat pipes on the slot profile SLT3-SWH-6F6U-14.4.1. Further, the baud rate specified for the backplane profile BPK3-CEN06-15.2.2-1 supports the PCIe Gen 2 with baud rates up to 5 GHz.
The final beamforming system is shown in Figure 7, with simplified block diagrams of the four Model 5353 Beamformers and the 5308 PCIe Cable Adapter. All of the required gigabit serial links for Aurora expansion plane and PCIe data and control planes are connected by the backplane wiring.
The chart in the diagram shows the OpenVPX profiles for the backplane, the slots, and the modules that plug into those slots. Each profile is described in full detail in the specification and the system designer must ensure that the profiles are compatible.
This process of matching module profiles, slot profiles, and backplane profiles for a particular application is the key to successful system configuration under OpenVPX. Not all of the resources of each profile need to be fully implemented or utilized if the needs of the application are satisfied.
Finally, the chassis profile needs to be defined based on the environmental and physical constraints of the system. OpenVPX does not yet have specific chassis profiles defined, but it offers a complete system for specifying the size, type (rack mount, tower, etc), slot count, primary power, cooling, backplane power, and the profile name.
OpenVPX presents a formal, well-organized system for defining all components in VPX systems, and the efforts of the working group should be applauded. Many of the figures and all of the profiles in this article were derived from the full OpenVPX VITA 65 specification, which is available from the VITA website (www.vita.com ), and is definitely a worthwhile and important reference document.
A good metric for the significance of a new standard is how actively new extensions are proposed to embrace new options and new technology. As promising evidence, even before final ratification, new initiatives like VITA 66 and VITA 67 were proposed, adding both optical and RF I/O capabilities. As OpenVPX is applied to an increasing number of application systems, the need for future evolutionary capabilities will emerge. All signs point to growing adoption of OpenVPX for new programs by both the embedded systems industry and its customers.