VXS versus VPX: Either -- or both?

3VME-based embedded subsystems users have, over the past couple of years, come to face decisions they did not have to previously. For example, the advent of serial switched fabrics and their promise of significantly enhanced performance is causing those users to look at alternative paths into the future. In the VME world, those paths are represented by VXS and VPX. However, VXS and VPX each provide their own unique benefits and trade-offs.

When it comes to computing, the military is notoriously - and wisely - conservative. With program deployments often measurable in decades, it's not surprising that designers of military embedded computing systems eschew "bright shiny object syndrome" in favor of architectures and technologies that can be reasonably expected to be around for the long haul.

It's little wonder, then, that military technology strategists have been quietly patting themselves on the back for the past 25 years or so: The VMEbus architecture has done everything they wanted, and more. Not that VMEbus has remained static during that time - far from it (see Figure 1, courtesy of VITA). VME has substantially increased the processing power it delivers in line with increasing user demands and successive generations of more powerful processing devices; commendably, it does so in a way that leverages investment in it by maintaining absolute compatibility with what had gone before. Originally capable of transfer speeds of 40 Mbps in its 16-bit guise, 32-bit and 64-bit technology delivered bandwidths of 80 Mbps, with five-row VME64x bringing four times the original capacity of VMEbus. VITA 1.5 2eSST, a high-performance synchronous protocol approved in 2003, brought backplane transfers up to 320 Mbps.

21
Figure 1
(Click graphic to zoom by 1.2x)

Throughout this 25-year period, military computing users were able to build on what they already had - whether in hardware or software. Total backwards compatibility was the overriding mantra when it came to developing the VMEbus architecture. For program managers, there were no difficult decisions to be made, at least in the area of computing architecture.

It was, however, becoming increasingly difficult not to heed the siren call of serial switched fabrics and the growing demands of military applications. Particularly relevant to this dilemma were those applications that had become increasingly graphics-intensive, more connected to the "real world" such as sensor input, required more and faster storage, or needed multiple processors working in parallel to perform sophisticated applications.

Thus, a hitherto-unimaginable fork in the VMEbus road was beginning to appear on the horizon - and with it, decisions about "where next?" for military embedded computing designers. Both VXS and represent real opportunities for greater performance within the overall VMEbus architecture - and there are advantages and trade-offs to each.

VXS: VME takes its first step into the serial switched fabrics world

When the VXS architecture was first mooted, it became apparent that the first significant discontinuity in the long development of VMEbus was inevitable. VXS was, of course, designed to provide a marriage between the parallel backplane world of yesterday and the serial interconnect of tomorrow; it was also an implicit admission that parallel backplanes could no longer keep pace with new generations of I/O intensive applications. Cynics said that VXS was a "kludge," with fabric connections shoehorned into an architecture that was never designed to support them.

Users, on the other hand, were very happy. Backwards compatibility with VMEbus was provided at the P1 and P2 connector level. However, VXS saw the advent of a new seven-row P0 connector, providing 69 signal pins that would take high-speed differential signalling off the backplane. Even better, VXS was designed to use the standard VME64x backplane. Thus, user investment in hardware was preserved; so, too, was user investment in software. VME cards could coexist with VXS cards, but the system could leverage the additional bandwidth offered by serial switched fabrics.

So, what did VXS provide specifically? What was different? VXS enabled systems to deliver bandwidths of 2.5 GBps per slot - orders of magnitude more than VME could provide. Not only was the 6U card format preserved but also the 0.8" card spacing. Most importantly, the electrical, mechanical, and positional properties of the P1 and P2 connectors were maintained. VXS also brought with it a new concept in the form of two new card types: the payload card and the switch card. The payload card can be broadly thought of as comparable to a "standard" VME card; the switch card, on the other hand, provides everything to everything-else connections for up to 18 payload cards, typically in a star or dual star arrangement.

VPX: VME wholeheartedly embraces serial switched fabrics

But while system designers were still mulling over whether VXS was the right direction for future developments, VPX began to make waves. That fork in the road that was out on the horizon was now a whole lot closer: While VPX offered software compatibility with VME, its hardware compatibility was more difficult to discern than had been the case with VXS. It could be said that VME/VXS represent one fork - and VPX the other.

As with the difference between VME and VXS, the single biggest difference between VME and VPX lies in the connector. The seven-row MultigigRT2 connectors used in VPX offer a total of 432 signal pins, including, in a typical 6U configuration, 128 differential pairs of user I/O rated at up to 6.25 GHz (Figure 2). Compare this with VME64x, which is typically limited to no more than 128 pins of user I/O on P2, with an additional 95 pins on P0, and signal speeds normally less than 500 MHz. Now, however, there is neither the P1 nor P2 connector beloved of the VME community for so long.

22
Figure 2
(Click graphic to zoom by 1.5x)

VPX also offers a choice of higher power and input voltages, with a dedicated power connector providing up to 115 W at 5 V, and with options for up to 384 W at 12 V or 768 W at 48 V. Of course, this assumes that designers have some way of providing sufficient cooling for such powerful modules. An associated standard, , addresses this area of advanced cooling, including more powerful forced air and conduction-cooled and Liquid Flow Through (LFT) modules.

VXS and VPX: Both have a role to play

For all intents and purposes, VPX created a substantial hardware discontinuity, largely as a result of its new connector paradigm. In contrast, a key element of the VXS specification is that it maintains backward compatibility with VME, such that VXS boards could be simply deployed on a standard VME64 backplane. Thus, it can be said that VXS represents an evolutionary step forward for VME; meanwhile, VPX is perhaps more of a revolution (see Table 1).

Lockheed Martin, when it came time to refresh the underlying technology in its Medium Extended Air Defense System (MEADS) radar system, is one example of utilizing the VXS approach. Because MEADS is not a new program - in fact, it goes back almost 10 years - it has "roots" in VME that are more difficult to pull up. Thus, the more "evolutionary" approach of VXS is seemingly more appropriate for this program versus VPX's "revolutionary" approach - which is often more conducive to new VME programs unconstrained by history but aimed at remaining in the "VME world." Accordingly, MEADS - which unites the United States, Germany, and Italy in developing next-generation point defense capabilities - utilizes the capabilities of two products from GE Fanuc Intelligent Platforms: the DSP220 VXS multiprocessing board (Figure 3) and the CRX800 22-port Serial switch.

23
Figure 3
(Click graphic to zoom by 1.2x)

VPX, on the other hand, is finding substantial favor within an increasing number of new high-profile ground and airborne applications, because it offers high performance and extensive configuration flexibility.

So what are the pros and cons of making the VXS or VPX choice? Inevitably, some degree of compromise is necessary. Migrating or refreshing a program following the VXS route will, for many programs, represent a more cost-effective decision. It is also true that, while the range of VPX products from a number of manufacturers continues to grow rapidly, availability of hardware that a VME backplane will accommodate is still much greater. Thus, VXS might afford more flexibility in system design, especially where it is imperative that legacy capabilities are retained.

So why choose VPX? One reason might be that, unlike VXS, it offers a 3U option - invaluable in today's space-constrained applications. VPX also added ESD protection to the connector, making two-tier maintenance possible - a boon for military users. The three-tier system that is otherwise used is logistically complex and very expensive. The VPX architecture also allows the creation of larger mesh configurations or mesh clusters - eliminating the requirement for a central switch on a dedicated fabric card, thus saving valuable slots. Given the increasing importance of serial switched fabrics, VPX could also be seen as a strategic decision - where VXS might be a tactical (if highly pragmatic) solution.

The good news for military embedded computing users is that either choice - whether VXS or VPX - is a valid one, and will deliver considerable throughput benefits for sophisticated applications. It's a decision that is likely to be highly application-, environment-, and timing-specific. And some commentators have pointed out that a combination of creativity and hybrid designs can virtually eliminate most differences between the two anyway.

Additionally, of course, it's important to note: Support for VME isn't going away anytime soon. Major vendors continue to offer extensive support - in the form of new products - for VME while bringing to market complementary VXS and VPX products. Meanwhile, the most sophisticated development tools are completely platform-agnostic, meaning that challenging multiprocessor applications can be developed, debugged, and optimized rapidly - and one time only. The resulting code can be deployed on a VME platform, a VXS platform, or a VPX platform. These tools relieve the developer from having to understand the detail of the underlying hardware architecture.

VXS and VPX: The future of VME

With VXS and VPX, there can be little question that VMEbus has once again demonstrated its ability to adapt both to changing requirements and evolving technologies. Each provides users with its own unique set of benefit and trade-off decisions in terms of performance and degree of compatibility.

As for the underlying VMEbus architecture, few in the industry are prepared to predict where it might go next. Over the course of more than a quarter of a century, it has demonstrated remarkable resilience during a period of rapid technology change. However, there is an extent to which, with VPX - and to a lesser extent, VXS - the mold has been broken. CS

David Compston is director of product marketing for military and aerospace products at GE Fanuc Intelligent Platforms. He began his career as a software engineer working in the UNIX arena with Plessey Microsystems. Following the management buyout of Plessey Microsystems to form Radstone Technology, David moved into marketing at Radstone Embedded Computing. He now has responsibility at GE Fanuc Intelligent Platforms for the development of their military and aerospace products. He earned his BSc in Computer Science from Warwick University. He can be reached at david.compston@gefanuc.com.

GE Fanuc Intelligent Platforms
+44-1327-359444
http://www.gefanuc.com

Topics covered in this article