As next-generation systems require higher and higher bandwidth, the limitations of CompactPCI bus speed increasingly push the form factor towards obsolescence … or do they? Through continued specification updates, extensions, and revisions, PICMG has positioned CompactPCI to transcend typical lifecycle limitations. With the inclusion of the CompactPCI PlusIO (PICMG 2.30) specification, systems based on legacy CompactPCI can take advantage of the benefits of the new CompactPCI Serial (PICMG CPCI-S.0) spec. The outlook for CompactPCI and its governing trade group indicates a fluid evolution rather than a halting revolution.

The true value of an industry specification is measured in its ability to withstand the test of time. System configuration, hardware components, and integration strategy all need to be built upon the inherent principles of flexibility, modernization, and efficiency. The omnipresent threat of technological obsolescence represents a huge concern from both logistical and cost perspectives, particularly when the industry spec is a custom embedded system application.

A case in point since the mid 1990s, CompactPCI has made a name for itself as a scalable, cost-effective, and easily implemented specification that can be adapted in many ways while maintaining its true integrity. By providing a consistently uniform technology platform, CompactPCI has yielded significant benefits for industries as far reaching as automation and mobile applications, as well as transportation and telecommunications. The CompactPCI bus interface has served industrial computing applications so reliably for the better part of two decades by redefining itself to include the use of enhanced communications capabilities.

The Compact past

The CompactPCI spec originated as a standard for building cost-effective modular industrial computers, and quickly won the support of a large group of suppliers covering a wide range of products from components to complete systems.

However, as requirements for future systems demanded a dramatic increase in speed, solutions would have to be implemented through enhanced serial architectures and new high-speed, higher pin density connectors.

Fortuitously, over the 16-year history of CompactPCI, PICMG has consistently met the challenges of rapid technological advances by adding subsidiary specifications to continually enhance functionality. The most notable (and most recent) developments that serve as a testament to those efforts are the CompactPCI Serial (PICMG CPCI-S.0) specification that exclusively uses high-speed serial interfaces over older parallel ones, and CompactPCI PlusIO (PICMG 2.30), which maintains both parallel and serial interfaces to allow a bridge between the new specification and the legacy systems still in operation.

Pluses of PlusIO

In its relatively short life span, the CompactPCI PlusIO specification has provided convincing evidence that CompactPCI is one industry spec that will not easily fall victim to the fate that all good things must come to an end, which has proven true time and time again in computing technology.

CompactPCI PlusIOs importance lies in a simple fact: because it has been so successful, CompactPCI has a large installed base and to abandon this structure in favor of a completely new system is of no benefit to anyone — manufacturer, developer, or end user.

The CompactPCI PlusIO spec, approved by PICMG in November 2009, is described as defining the connector, electrical and mechanical requirements of 3U/6U System Boards, Peripheral Boards, Switch Boards and Backplanes using PCI Express as peripheral interconnect, and supporting a variety of other switched serial interconnects, with CompactPCI and CompactPCI Express interoperability features[1].

In effect, CompactPCI PlusIO provides for the addition of high-speed serial communication while preserving PCI bus connectivity and maintaining the mechanical parameters of the original CompactPCI standard. It achieves this through the addition of PCI Express, Ethernet, SATA, SAS, and USB extensions to the CompactPCI family of specifications, and defining the use of previously reserved rear I/O pins for the 32-bit CompactPCI system slot with new high-speed serial signals. Also, since CompactPCI PlusIO needs no switch boards in the system and the high-speed connector is low cost, it is an exceptional money-saving option.

The result is a practical migration path for users who require the added capabilities of a high-speed interface without disrupting the continuity of those aspects of their applications for which original CompactPCI hardware components still perform acceptably (Figure 1).

A single step to serial

The CompactPCI PlusIO hybrid system creates a perfect connection between parallel and serial architectures, and a gradual transition from old to new. This type of solution offers the ability to incorporate existing CompactPCI I/O cards within an installation accommodating serial I/O connections, helping maximize the value of user investment in current CompactPCI hardware. This flexibility to satisfy increased operational demand is provided as a quick, easy, and affordable improvement to higher level performance. It is not necessary to completely replace an existing system in order to upgrade it to the latest technological standard, nor is it necessary to scrap successfully proven components. The need for speed can be met without the need for extraordinary capital expenditures by the large community of existing CompactPCI users.

Implementation is surprisingly easy and cost efficient due to compatibility with existing hardware. In its simplest application, the installation of a new CompactPCI PlusIO SBC into an existing system slot can integrate up to seven parallel I/O boards and four serial I/O boards in the same configuration. But whatever the eventual configuration, CompactPCI PlusIO remains true to the mechanical requirements of the original CompactPCI standard – including identical board and backplane dimensions, identical front panels and identical hot-plug mechanics.

CompactPCI PlusIO is already paying big dividends for users looking to supplement analog and binary signals on the parallel bus interface with new serial communications signals from higher level I/O devices. Areas in which the most evolution can be expected are where system performance, ease-of-use (such as in multi-computing networking), increased reliability, and hot-swap functionality count. With the advent of PICMG 2.30, CompactPCI users in those application areas are now able to leverage the high-speed interconnects on CompactPCI Serial by bridging with a CompactPCI PlusIO-based product.

Through the substantial preservation of existing hardware, the migration of the large inventory of legacy systems to CompactPCI Serial applications will result in an evolution rather than a revolution.

Destination: Pure Serial

Geared for new installations, CompactPCI Serial is the latest specification for systems being built on CompactPCI technology. Unlike CompactPCI PlusIO, which is an extension of the original CompactPCI specification, CompactPCI Serial is a new, separate spec, and so given its own naming structure — PICMG CPCI-S.0 (Editors Note: See Elmas article for more information on CompactPCI Serial).

As with the original CompactPCI, CompactPCI Serial maintains the proven 19 mechanics of the IEC 1101, as well as a dedicated system slot and passive backplane. And, like CompactPCI PlusIO, it does not need switches and bridges. It does, however, use a configuration of one system slot and up to eight peripheral slots, and moves from CompactPCI PlusIOs simple star architecture to full mesh for Ethernet functions.

What makes CompactPCI Serial different from its other relatives is the simple fact that it is based solely on serial technology; the parallel bus does not exist anymore in pure CompactPCI Serial systems (Figure 2).

Reaching the horizon

Not surprisingly, the systems, boards, backplanes and a host of other CompactPCI PlusIO and Serial-based embedded solutions are readily available from a number of embedded manufacturers. These products will help ensure that CompactPCI will remain a viable, affordable technology platform throughout the evolution of embedded computing.

Several board level products based on both CompactPCI Serial (PICMG CPCI-S.0) and CompactPCI PlusIO (PICMG 2.30) are currently available. For example, over the past few years MEN Mikro Elektronik has developed a range of board products that meet the new PICMG specifications and are ideal for serial connections on the CompactPCI platform, including several high-performance Single Board Computers (SBCs) and a variety of CompactPCI Serial peripheral cards that allow flexible configuration. All products are easily installed in modular 19 systems to cost-effectively meet the expanding requirements of bandwidth and data processing capacity in embedded applications (Figure 3)

Building promise

Because of hybrid CompactPCI PlusIO and pure-serial CompactPCI Serial, not only is the door to CompactPCI not closing, but rather it has been opened to many new capabilities. The development path affirms that the specification is able to continually evolve while maintaining its original mechanics. This attribute has enabled updated versions to remain compatible with legacy systems, and ensures that the extensive base of installed CompactPCI systems remains viable, relevant, and cost effective within the many industries using CompactPCI, as well as those that can now benefit from high-speed serial interfaces.

The CompactPCI PlusIO specification allows the worlds of legacy parallel-based systems and high-speed serial technology to coexist. In concert with CompactPCI Serial, it forges new paths for the use of cost-effective, highly reliable, and time-proven CompactPCI technology.

These are all important factors to note in the progression of CompactPCI from its origins to the specifications of today and beyond. Without these adaptations, CompactPCI would not have been able to keep pace with the changing embedded landscape over the past 15 years; the ratification of PICMG 2.30 and PICMG CPCI-S.0 has, in all probability, delayed any possible obsolescence of CompactPCI for another 15.

Since 1992, Barbara Schmitz has served as Chief Marketing Officer of MEN Mikro Elektronik. Her tasks include public relations and product positioning as well as development and coordination of global sales channels.

MEN Mikro Elektronik

Barbara.Schmitz@men.de

www.men.de

[1] CompactPCI PlusIO (PICMG 2.30) Specification. opsy.st/CompactPCIPlusIO.

]]> http://tech.opensystemsmedia.com/advancedtca/2012/03/compactpci-plusio-and-the-journey-to-serial/feed/ 0 http://www.compactpci-systems.com/articles/id/?5590 http://www.compactpci-systems.com/articles/id/?5590#comments Thu, 22 Mar 2012 15:00:00 +0000 John Long, RadiSys http://tech.opensystemsmedia.com/advancedtca/?guid=9310a79e434efb8239aeeea87a66eb94

Entire Aerospace and Defense (A&D) networks, from base stations to the core, are being consolidated into small, ruggedized communications platforms that provide the ability for an entire network to be picked up and moved. Femtocells are now being found on Humvees, ships, and even carried in a soldier’s pack, providing unparalleled communications right where it’s needed most. Compact network cores can fit in 2U and 5U ATCA chassis and can easily be transported. However, these ultra-portable cellular networks require a combination of hardware and optimized software that meets specialized Size, Weight, and Power (SWaP) requirements for next-generation network-centric warfare.

Our military networks have been lacking agility and reliability in comparison to the commercial cellular devices the enemy has at its disposal. Efforts in Iraq and Afghanistan have exposed this gap between proprietary radio communications and commercial cellular networks. Smart phones and cellular networks are allowing an unprecedented level of situational awareness, giving soldiers a significant advantage in the palm of their hand, but cellular networks can be difficult to deploy from a military transport vehicle, such as a Humvee or destroyer, because they tend to be very large, heavy, bulky, and power-hungry. In addition, the network nodes are too cumbersome to be portable, lack the ability to deliver ad-hoc communications, and are not easily customizable to deliver the reliability and security that the military requires.

The military wants to take advantage of proven commercial cellular technology and the associated economies of scale for the next-generation mobile communications systems. However, it cannot simply re-use this technology as is. These portable networks require particular architectures and specific hardware and software elements to meet the specific requirements, such as Size, Weight, and Power (SWaP), of network-centric warfare. This is leading to tremendous changes in how the military implements its wartime communications networks as it moves toward adoption of standards-based cellular technology with 3G today and LTE in the future.

Transitioning from proprietary solutions to COTS hardware

The telecom industry has been steadily moving from proprietary to standards-based designs due to refined standards and the development of a healthy supplier ecosystem. As telecom companies transition from proprietary to standards-based architectures, some are now saving resources and capital by outsourcing critical design and validation tasks. By using Commercial Off-The-Shelf (COTS) hardware as opposed to designing a computing system in-house, Network Equipment Providers (NEPs) are now in a position to avoid hardware design altogether and can focus development efforts on software-based value-add features. NEPs are finding that equipment based on open standards architectures typically costs less to deploy because it makes sound economic sense to design scalable platforms that can be employed across multiple applications (Figure 1).

Open standards-based COTS solutions not only address many issues facing equipment manufacturers, they also meet the needs of military programs. Military and aerospace system designers, who are in the process of replacing proprietary architectures, are seeking COTS technologies that competently accommodate the toughest environmental conditions (such as extreme temperatures) yet are efficient enough to meet application needs for power, performance, and heat dissipation. For example, the military is now looking outside of its engineering ranks to guarantee that its components are rigorously temperature tested. Many COTS technologies were designed to both withstand the rigors of military environments, and offer developers readily available, interoperable hardware that reduces design effort.

Putting the pieces together

Next-generation network-centric warfare requires ultra-portable cellular networks that squeeze the entire system, from base station to the core, into a small, ruggedized platform that can be picked up and moved, or even carried in a soldier’s pack (Figure 2). COTS technologies have made tremendous progress in satisfying the size, ruggedness, and performance requirements for a wide range of Aerospace and Defense (A&D) applications.

When combined, COTS technologies such as AdvancedTCA (ATCA) and COM Express provide a complete, deployment-ready solution with the flexibility for design and software enhancements. Together they support a network of networks in a manner that is standards compliant, providing a high level of interoperability and scalability. Many protocols can be consolidated onto one platform of nearly any size to accommodate a variety of missions, with base stations ranging in size from a big box to several smaller distributed units.

No matter the computing technology, year after year designers try to find ways to increase performance. Successfully integrating a high level of computing power basically comes down to board size, board power consumption, and backplane technology. In all of these areas, ATCA has a significant advantage. ATCA is a bladed platform that easily scales features and performance by adding blades that support new applications or more computing power. With its roots in telecom, ATCA was designed to maximize serviceability and availability, leveraging hot-swappable components and redundancy (for example boards, switches, fans, and power entry modules). In the field, an ATCA chassis is powered by stepping up the military vehicle battery voltage to 48 volts, thus avoiding the 120-volt (AC) supply required by a rackmount server. Yet, to attain the maximum benefits from ATCA equipment, manufacturers have realized it takes a combination of telecom and ATCA expertise to bring all of the elements together — chassis, blades, operating system, middleware, and platform management software — into a cohesive platform.

Boosting performance is especially challenging for designers of small form factor systems who face stringent space and power constraints. It’s also difficult to keep up with the design churn associated with implementing new processor generations and increasingly complex design rules. As a result, military system developers are turning to COM Express boards, which remove the processor, chipset, and memory from the rest of the design. For example, for the purpose of reducing size and cost, a leading provider of military mobile telecommunications technology and software development completely revamped its system architecture using COM Express, and now the core network is the size of a shoebox and one-tenth the cost of other available solutions.

The case for small cells in military applications

Small cells provide unparalleled communications right where it’s needed most without adding extra weight or taking up a lot of space. As opposed to a traditional macrocell on a hilltop or a tall tower, a small cell is a wireless base station that is portable and transmits at very low power. Small cells typically use an IP broadband connection (such as cable, DSL, or fiber) for backhaul and eliminate the need for dual-mode handsets, as virtually any existing wireless handset should work seamlessly with a small cell offered by the carrier.

A wireless equipment manufacturer recently set out to design a flexible LTE network solution that could scale from small to large networks to serve U.S. state and local governments seeking to improve public safety. Increasing capacity had to be as simple as adding processing blades to the chassis and activating additional subscriber licenses, while minimizing SWaP was essential for supporting military or disaster response applications in which the wireless network may need to be transported via van or military Humvee. For customers with existing mobile infrastructure, the solution required the flexibility to make use of legacy equipment. To meet its objectives, the equipment manufacturer developed an Evolved Packet Core (EPC) that is available in different hardware configurations, making it a highly scalable and cost-effective solution. The EPC ships in either a 2- or 14-slot ATCA chassis from Radisys, running the full complement of Trillium LTE protocol software including open interfaces for integrating external network elements.

But is it secure?

Commercial cellular networks have built-in security and integrity protection features. These, however, are being modified for military applications. Existing features that can be customized include:

1.  Air interface ciphering – In commercial networks this is based on the Advanced Encryption Standard (AES) and KASUMI and SNOW 3G algorithms, but can be modified to use any defense-grade encryption approach.

2.  Integrity protection – Mobility and session state information is encrypted and decrypted in the core of the network leveraging commercial-grade algorithms, which may be customized for military requirements.

The ATCA platform enables a robust telecom security gateway that offers world-class security features with multi-gigabit performance to secure the backhaul capabilities — the infrastructure for connecting cell sites to the core network. Furthermore, the COM Express combination of Intel Active Management Technology (Intel AMT) and Trusted Platform Management (TPM) ensures remote access transactions are safe and secure. In addition, since small cells are portable and not left in the same spot for long periods of time, they are less vulnerable. However, many NEPs are also addressing security through protocols. For example, Radisys provides the COTS solutions for mobile infrastructure and the expertise needed to customize the solutions based on SWaP constraints, while NEPs bring the specific insight needed to wrap A&D security features around the standard offering.

Warfighters need more situational awareness on the battlefield and better communications back to the command center. Adoption of commercial standards-defined cellular technology solves the agility, reliability, and cost challenges, but does not deliver an ultra-mobile solution enabling ad-hoc network roll-out and the network of networks concept central to next-generation network-centric warfare. These ultra-portable cellular networks require a combination of hardware and optimized software that meets specialized security and SWaP requirements. Modular, ruggedized computers combined with a customizable carrier board provide COTS-based hardware ideal for ultra-portable warfighter communications applications and are specifically developed to support the extreme conditions in the field. The addition of small cell software solutions provides unparalleled communications right where it’s needed most, without extra weight or bulk.

John Long is a product line manager at Radisys, with a focus on ATCA single board computers and storage.

Radisys

www.radisys.com

john.long@radisys.com

The ATCA Extensions group has been busy expanding the power and space allowances beyond the existing ATCA 3.0 specification, resulting in a double slot width form factor for the front and rear boards as well as mechanical changes to the subracks that offer a substantial component real estate increase over the ATCA 3.0 RTM form factor. Yet, with all of these advantages come legitimate concerns regarding the cooling of these larger and more powerful blades and the subrack as a whole.

The ATCA Extensions subcommittee has been hard at work expanding the AdvancedTCA architecture. Among these improvements, Extensions offers a wider, double-slot form factor, increased PCB real estate on the rear blades, increased maximum power (to as much as 800 watts per blade), and enhanced cooling management. As we take a look at some of these in more detail, we will examine some of the challenges and how they are being tackled.

Reform factor

Let’s start with the support of a double-wide blade, namely a single blade comprised of two standard 6HP slots. While this is something we have seen done numerous times in AdvancedTCA subracks, where one may need additional component, I/O space, or mezzanines, the Extensions specification standardizes this form factor as an option, outlining the front panel dimensions, datum locations, and tolerances, as well as the increased component area and available mezzanine envelopes for consistent implementation. This new form factor provides the option of locating the PCB in either the left (bottom) position of the front panel to maximize the available Component Side 1 height envelope, or centered to utilize an expanded component envelope for Component Side 2. In addition, this facilitates the ability to develop even wider, multi-slot configurations[1].

Additionally, a substantial increase of PCB real estate is available on the rear modules due to Extensions’ support of standard AdvancedTCA front boards. Boards can be implemented in the front and rear of the subrack, complete with Zone 1 power and Zone 2 data transport connectivity. This, in concert with other configurations, more than triples the component area available on the current AdvancedTCA Rear Transition Module (RTM). As a way to differentiate the two sides of the subrack, Extensions designates the front as “Side A,” and the rear (RTM in the AdvancedTCA specification) as "Side B" (Figure 1).

In order to facilitate the use of front boards in this new Side B configuration, it was necessary to adjust the orientation of the pitch line from front to back. As we know, the existing AdvancedTCA spec maintains the same pitch envelope from the front boards to the RTMs. With the new Extensions configuration, the front side pitch for each slot stays exactly as it currently is with the AdvancedTCA spec, but the rear side is offset a little more than a millimeter. In short, the reason for this is to maintain an equal front-to-rear overall subrack aperture width and gasket interface aperture without requiring any additional subrack features or increases in overall subrack width.

Maintaining faceplate orientation of a front board in the rear of the subrack results in the PCB not being aligned in the same plane front-to-rear. This, along with the pitch offset, presents some challenges with Zone 3 interconnectivity. This may be addressed with some unique interposer designs, and the specification will be kind enough to actually provide some examples of how this can be done. Other solutions could be connector based, but this would require new connector designs, so the level of demand will dictate the availability of those solutions.

Extended opportunities

Anyone that has ever had to contend with the limited real estate offered by the AdvancedTCA RTM will be interested in the new specification for the “Extended Transition Module.” This blade was developed for use in the rear (or Side B) of the subrack. This is, in essence, a full front board configuration with an extension area for direct mating to the front board through Zone 3. Another new configuration is the “Extended Board,” a blade that supports Zone 1 Power and Zone 2 Data Transport, along with the Zone 3 interconnectivity to a front board[2].

Of course, these new rear board options will need the support of additional backplane configurations. Supporting the implementation of Extended Transition Modules, the subrack utilizes the same backplane as the current AdvancedTCA 3.0 specification for the front, but one with an increased depth in the rear. This configuration is categorized as a “Single-Sided Backplane Shelf.” There is also a “Dual Backplane Shelf” that uses a separate Side B backplane for connectivity to rear blades, and would support the use of standard front boards along with the new Extended Board. The option of a “Monolithic Backplane Shelf” – a single backplane supporting both front and rear blade interconnects – is also available. With this configuration, the thickness of the backplane would dictate the total shelf depth.

As you can imagine, all of these advancements vastly expand shelf configuration options. Along with these improvements comes an increase in power, from a previous maximum of 400 watts to a possible 800 watts per blade. This, coupled with the expanded shelf depth, could prove to be a challenge for thermal management.

Keeping it cool

Air cooling via forced convection will continue to be the most simple and cost effective method used, but maintaining consistent airflow distribution through all blade regions for Side A and Side B blades will no doubt require additional consideration.

One area of concern is in the vicinity of the backplane, due to the additional space added between the front and back of the subrack for supplemental backplane configurations. This additional space will have to be sealed off, thereby preventing air from escaping between the backplanes (the open area between Side A and Side B). Figure 2 displays this blockage and the subsequent airflow.

Most likely, this will be managed with features added to the subrack structure, and while the Extensions specification does not specify exact methods for accomplishing this, recommended locations for these features are outlined for guidance.

For extended blades with Zone 3 interconnections, restricting front-to-back airflow through this interface area will also be important. While the connectors could inherently block some of this airflow, additional air blocking features will most likely be required. While this is not all that different than the initial AdvancedTCA spec, the way this is handled may vary somewhat. AdvancedTCA defines an airflow seal for unused slots that is attached directly to the backplane support bar in the subrack, accessible from the rear. As Extensions offers a much greater depth in the rear section, getting to this area, especially if slots are populated, may prove very difficult. So what are some ways that airflow can be managed in this area?

A critical concern has always been the management of unused slots. While there are ways to restrict airflow within the chassis structure itself, primarily front panels with air restrictors (or “baffles”) are used. This allows various shelf configurations to be easily managed in the field. One of the problems noted with these devices has been the wide variety, and frankly inconsistency, of existing designs. To better control the consistency of these fillers, the Extensions Committee has worked on defining a “Universal Filler” displayed in Figure 3. This design is focused on providing maximum air blockage for unused slots in either the single- or double-wide applications, as well as setting a consistent location for the air impedance feature.

This design of the Universal Filler is not exclusive to the Extensions chassis, and can be used in the front of any ATCA-compliant subrack. Also included is a feature to better control the location of this dummy blade in each slot by interfacing with the backplane alignment keys. To address the concerns with the difficulty of managing the Zone 3 airflow mentioned above, the Universal Filler also includes a feature to block front-to-back airflow in the Zone 3 area. This will serve to seal Zone 3 on both Side A and Side B of the subrack for both single- and double-slot form factors. All of the features built into the Universal Filler will result in forcing as much air as possible to active blades for maximum cooling of those slots.

Enhanced outlook

The ATCA Extensions specification will introduce some exciting enhancements: PCB and front panel space, blade configuration options, increased power … and all of these improvements need provisions for viable component and subrack cooling solutions. This new specification provides that, and presents an easy-to-implement expanded platform for implementation in new applications.

Matthew Travers is an applications engineer at CBT Technology and has more than 20 years’ experience designing front panels and mechanical systems for the telecommunications industry.

CBT Technology

www.cbttechnology.com

MTravers@cbttechnology.com

References:

[1] Given the increased width of the front panel, it has been noted that some sort of simple bracket may need to be added to maintain structural rigidity and perpendicularity between the PCB and front panel.

[2] Both of these boards are required to include a feature protecting them from inadvertent insertion in a Side A slot opposing a previously installed Extended Transition Module, as this has the potential to cause damage to the blade connectors if they come in contact with an installed Side B Extended Board.

]]> http://tech.opensystemsmedia.com/advancedtca/2012/03/axie-extending-the-ecosystem/feed/ 0 http://www.mil-embedded.com/articles/id/?5544 http://www.mil-embedded.com/articles/id/?5544#comments Thu, 16 Feb 2012 15:00:00 +0000 David Pursley, Kontron http://tech.opensystemsmedia.com/advancedtca/?guid=7d3a0b0f2c313e0213c8da52c982db1a

There are many COTS technologies available for implementing radar and sonar applications, including CompactPCI and VME, and newer switched-serial standards such as VPX and MicroTCA. By using real radar and sonar examples, the author illustrates how the communications topology can point designers toward choosing an optimal COTS architecture, in this case VPX (VITA 46) and CompactPCI.

Radar and sonar are mainstays and pervasive applications for military platforms worldwide. More recently, these Digital Signal Processing (DSP)-based systems provide a sophisticated foundation for missile defense – searching, tracking, and launching with great precision. System demands are increasing even further today, as systems must simultaneously locate and discriminate targets through tracking and identification to launch effective and appropriate countermeasures. At the same time, the Size, Weight, and Power (SWaP) of systems is required to decrease; for example, functionality previously implemented by 19" rack-mount servers installed in a pressurized wide-body aircraft must now be implemented in a ½ ATR on an Unmanned Aerial Vehicle (UAV). DoD requirements add to this growing challenge, mandating that systems are flexible and upgradable to respond to new threats and new applications. COTS-based systems gain an advantage here, as tech insertions to upgrade to the latest CPUs and communication technologies will be necessary during the lifetime of these deployed systems.

In response to this paradigm shift, depending upon the particular application, DSP-based radar and sonar systems can be achieved by using virtually every blade form factor available today; 3U/6U CompactPCI, VME, MicroTCA, or 3U/6U VPX can all be implemented with success. Additionally, contractors and manufacturers are responding to the latest challenges by offering a greater array of technologies for high-end DSP computing, including standards-based CompactPCI and VPX options. While high processing power is a common requirement, one COTS computing architecture does not fit all radar and sonar applications. It is usually the communication topology of the specific radar and sonar applications that suggests the optimal COTS computing architecture. Examples of CompactPCI and VPX illustrate this point.

Digital Signal Processing in action

The bulk of the computation in radar and sonar applications involves DSP. The essence of DSP is to efficiently transform a stream of data into relevant information quickly enough to be highly useful and applicable. In radar and sonar applications, for example, this may mean processing incoming electromagnetic or acoustic signals to determine the location, speed, and direction of potential threats, targets, and terrain while filtering out irrelevant data such as a small bird or fish.

Processing the data in an appropriate timeframe requires a high amount of computing power as well as the ability for each compute node to communicate with other nodes. The amount of processing and communication required is highly application dependent, varies widely, and likely increases with each tech refresh. But the topology of the communication is generally fixed, and that is the most likely discriminator in determining the best COTS architecture for a given application.

Figure 1 shows the communication topology of two real-world DSP applications. Each node in these topologies is a compute node, which is a sequence of transforms and filters implemented on one CPU node. The arrows represent data flow (communication), with darker arrows indicating higher bandwidths. For simplicity’s sake, only the higher-speed data plane communication is shown; each application also used GbE for control plane communication. Topology 1(a) was used for a sonar-based mapping application, while 1(b) was used for a high-end radar application for real-time use in theater.

For each communication topology, an appropriate COTS-based architecture was selected and implemented to meet the application requirements while still optimizing for SWaP.

CompactPCI meets the challenge in underwater sonar

The topology shown in Figure 1(a) for the sonar application reflects a typical “well-behaved” DSP application. The bulk of the communication is essentially a pipeline, with data flowing from one node to the next.

The digitized sonar data from the sensors is front-end processed by the left node, which then passes the data to a bank of three main compute nodes. Each of these implements a series of transforms for beamforming and filtering. The final node consumes all the data and synthesizes it into a spatial representation. The required bandwidth between nodes was less than 1 GBps in the main direction of dataflow [heavier lines in Figure 1(a)], with the backflow and control plane communication links requiring much lower bandwidths.

Given this topology, conduction-cooled 3U CompactPCI was chosen as the optimal COTS architecture for this application based on its small size and relative simplicity. Routinely considered a bus-based architecture, CompactPCI also supports multiple GbE communication links over the backplane, which was essential for this sonar application. Although originally implemented with dual-core processors, the COTS approach and a consistent pinout from generation to generation will allow this deployment to be extended, using multiple quad-core boards if and when higher precision is required for a technology refresh.

6U VPX for military radar

Conversely, the radar application’s communication topology shown in Figure 1(b) is much more complex. It requires many nodes, all able to directly communicate with each other at high bandwidths.

Sensor data is injected via high-speed links (>5 Gbps) in parallel to each six-node cluster. Within each cluster, a mesh topology allows the nodes to operate as a tightly coupled supercomputer, communicating with each other at >10 Gbps bandwidths. The clusters, in turn, require high-speed communication with the other clusters, also in a mesh topology.

The sheer number of high-speed data connections suggests that a switched-serial topology would be required, provided the data switches allowed enough bandwidth for all nodes to simultaneously communicate at full speed. VPX was a logical architectural choice because it allows for multiple high-speed interconnects; 6U VPX was selected specifically because its power envelope and Printed Circuit Board (PCB) real estate allow for two high-performance CPUs to be implemented in a single slot. Thus, each six-node cluster can be implemented with only three slots. This also makes the architecture scalable from a single six-node cluster in three slots up to 6 six-node clusters (36 CPUs in total) in 18 slots.

To handle the hierarchical high-speed communication topology, multiple data plane interconnect technologies were used. Within each cluster, PCI Express links provide high data throughput and a deterministic latency between CPU nodes. Between clusters, 10 GbE provides the required bandwidth and scalability. Figure 2 shows a simplified version of this as implemented on a 6U VPX architecture, including the aforementioned high-speed data plane links and the GbE control plane. Note that the architecture supports more connectivity than strictly needed to meet the requirements. Specifically, multiple 10 GbE links are available for each cluster, and nodes within adjacent clusters can directly communicate via PCI Express. These additional communication links currently go unused, but provide a valuable upgrade path looking forward.

A potential challenge of this type of VPX architecture is software complexity, resulting from the use of multiple high-speed serial communication technologies (PCI Express, 10 GbE, and GbE), each with a different software interface. Kontron VXFabric removes the complexity of these high-speed protocols by providing an API for a thin layer of software that allows IP-based data transport over PCI Express. As a result, from the software’s point of view, each interface looks like a high-speed IP socket, regardless of the underlying electrical implementation.

Determining COTS DSP approaches

It is important to note that both VPX and CompactPCI support multiple communication topologies beyond those highlighted here. However, a convenient rule of thumb is that complex board-to-board interconnect topologies with multiple high-speed connections tend to lend themselves well to a VPX implementation; applications with more “well-behaved” communications tend to use less complex and more pervasive technologies such as CompactPCI. Only careful analysis can determine the optimal COTS architecture for a given application. Specifically, the communication topology is the discriminating factor pointing toward one architecture or another. Regardless of the underlying architecture, the COTS approach will allow future upgrades and seamless tech insertions well into the future.

David Pursley is Product Line Manager at Kontron. He is responsible for business development of Kontron’s MicroTCA, AdvancedTCA, CompactPCI, VME, and VPX product lines in North America and is based in Pittsburgh, PA.

Kontron

800-523-2320

www.kontron.com

]]> http://tech.opensystemsmedia.com/advancedtca/2012/02/radar-and-sonar-applications-find-a-home-in-compactpci-and-vpx/feed/ 0 http://www.embedded-computing.com/articles/id/?5525 http://www.embedded-computing.com/articles/id/?5525#comments Tue, 07 Feb 2012 15:00:00 +0000 Nabil G. Damouny, Netronome http://tech.opensystemsmedia.com/advancedtca/?guid=b142b7072adf26f4d652e4d64af69e76

Part 2 in a 2-part series: Embedded systems migrating to 40G today and 100G in the next few years demand an intelligent in-line preprocessor capable of handling traffic at this high line rate, while communicating with the x86 CPU subsystem over a high-performance, virtualized PCI Express interface. Part 1 in this series examined the challenges of processing network traffic at 100G and some of the commercially available solutions attempting to solve such challenges. Part 2 highlights the need for a coprocessor that is tightly coupled to a multicore x86 CPU and can manage functions such as intelligent L2/L3 switching, flow classification, in-line security processing, virtualization, and load balancing for x86 CPU cores and virtual machines.

To keep pace with the explosion of traffic in the enterprise and carrier network, embedded designers have tried a variety of methods to meet the demand for 100G secure communication, including embedding hardware accelerators into multicore processors or using devices such as network processors, Ethernet switches, or Ethernet controllers. These approaches each come with their own drawbacks that limit performance and increase complexity. Furthermore, attempts to use a single-chip heterogeneous multicore processor to bypass performance issues have led to proprietary architectures that are not operating system friendly.

A high-performance multicore heterogeneous architecture builds on a single-chip multicore heterogeneous processor, but divides the solution into two processors: a general-purpose multicore x86 CPU focused on application and control plane processing and a separate in-line multicore coprocessor focused on L2-L4 processing and accelerating L4-L7 applications. The key to this architecture is having a tightly coupled interface between the two processors that is in-line, secure, virtualized, and high-performance (see Figure 1). A good analogy here is the use of a graphics processor unit alongside a multicore x86 processor in workstations and other graphics-intensive servers.

Efficient processing and memory utilization

The coprocessor needs to access packets, forwarding the packet and its associated metadata (packet state) in a timely manner with minimal latencies. This dictates having hierarchical memory architecture of on- and off-chip memories, with packet data effectively managed through the hierarchy. For example, first-level lookup tables can be in on-chip memories, while large volumes of data can be stored in external memory tables.

In addition, the use of multiple threads per processing core can bypass the memory wall problem. A core or thread continues to execute until an external memory access is needed, at which point another processing thread takes over. The resulting asynchronous memory architecture decouples external memory accesses from processing, maximizing overall system performance. This allows for bulk memory transactions, where many memory accesses are pooled together into one memory transaction, further increasing the efficiency of the external memory interface.

In-line or look-aside processing with security and virtualization

The coprocessor is in-line with ingress and egress traffic and should be able to, on-the-fly, encrypt and decrypt the packets, classify packets into flows, and look up the flow state table to determine the action needed on the flow. The coprocessor also implements I/O virtualization, allowing the x86 cores and their Virtual Machines (VMs) to share the I/O subsystem. In addition, the coprocessor should be able to dynamically load balance the traffic to the x86 cores and VMs based on flows.

Fast interconnect with x86

Supporting a heterogeneous processing architecture requires a high-performance interconnect to the x86 processor with I/O virtualization capability. For example, an 8-lane PCI Express Gen 2 interface supports up to 40 Gbaud of traffic to an x86 CPU socket. (Note: Overhead on read and write cycles brings this number down to the low 20s.)

Cut through/intra-flow cut through

Ideally, not all flows need to be transmitted to the x86 processor, as the coprocessor is intelligent enough to classify packets into flows. Based on the flow state table, an action can be taken to cut through, drop, or forward to x86. In some cases, the first few packets of a flow are forwarded to the x86 subsystem for inspection. The x86 processor can then instruct the underlying coprocessor to cut through the remainder of the packets in the same flow.

Inter-VM switching

The advent of VMs and the need for I/O virtualization have created a new set of requirements that mandates a more intelligent approach for managing I/O. This has prompted the need for an intelligent way to interconnect VMs on different cores to handle the so-called east-west traffic. Such VMs can belong to different tiers of servers in the data center. Having the VM-aware switch on the coprocessor can achieve the VM interconnect.

Passive NIC mode

The coprocessor should be able to support a mode where all network I/O traffic is passed to the x86 processor. This mode is required for monitoring and statistics or for applications requiring 100 percent of x86 CPU processing.

Implementing the OpenFlow protocol

Software-Defined Networking (SDN) allows users to bring the benefits of virtualization – including shared resources, user customization, and fast adaptation – to the switched network by defining traffic flows and deciding how these flows are treated in the network. In other words, it allows the system user to remotely control the network hardware with software in a dynamic and programmable fashion.

SDN puts the intelligence of the network into a hierarchy of controllers. In this hierarchy, switching paths are centrally calculated based on IT-defined parameters and then downloaded to the distributed switching architecture. A hardware-agnostic architecture that uses standard open interfaces to the hardware can change the way we build networking systems today.

The new OpenFlow protocol supports SDN. An OpenFlow controller typically runs on a multicore x86 processor and implements the control plane protocols. It downloads the state information onto multiple flow state tables in the coprocessor, implementing the data-switching plane through a standard OpenFlow API. The coprocessor, being a stateful flow processor, can be optimized to support the OpenFlow architecture.

Best of breeds for the future

As line speeds continue to grow, it remains to be seen how application workloads will be divided among x86 general-purpose multicore CPUs and external supporting coprocessors. The flexibility of riding a product roadmap for multicore x86 processors separate from that of coprocessors gives designers the choice to use the best of breeds in trying to meet ever-increasing future challenges.

Editor’s note: Read Part 1 in this series online at http://embedded-computing.com/managing-processors-40100g-part-of-2.

Nabil G. Damouny is senior director of strategic marketing at Netronome.

Netronome 408-496-0022 info@netronome.com @netronome www.netronome.com

]]> http://tech.opensystemsmedia.com/advancedtca/2012/02/managing-network-traffic-flow-for-multicore-x86-processors-at-40100g/feed/ 0 http://www.embedded-computing.com/articles/id/?5519 http://www.embedded-computing.com/articles/id/?5519#comments Thu, 12 Jan 2012 15:00:00 +0000 Nabil G. Damouny, Netronome http://tech.opensystemsmedia.com/advancedtca/?guid=dab4dab84dcf6ad46ac817c86dd35999

Embedded systems migrating to 40G today and 100G in the next few years demand an intelligent in-line preprocessor capable of handling traffic at this high line rate, while communicating with the x86 CPU subsystem over a high-performance, virtualized PCI Express interface. Part 1 in this series examines the challenges of processing network traffic at 100G and some of the commercially available solutions attempting to solve such challenges. Part 2 will highlight the need for a coprocessor that is tightly coupled to a multicore x86 CPU and can manage functions such as intelligent L2/L3 switching, flow classification, in-line security processing, virtualization, and load balancing for x86 CPU cores and virtual machines.

Traffic in the enterprise and carrier network has exploded in recent years, driven by consumer broadband, corporate traffic, and newer IP-based services such as mobile connectivity, remote cloud services, IP video, and IPTV.

In addition, the advent of virtualization and the need for higher-performance (up to 100G) secure communication have put tremendous pressure on communication system designs, including the I/O subsystem. These demands, coupled with the success multicore x86 CPUs have had in embedded applications and the data center, have created the need for a coprocessor that can handle packet processing at tens of millions of stateful flows with a glueless, high-performance, virtualized interface to the x86 CPU subsystem.

The pressure of packet processing

Today, service providers offering cloud-based services and enterprise data centers are enabling access to valuable resources anytime, anywhere over wireline and wireless networks. The resulting increase in traffic is putting aggregation switches/routers and intermediate network nodes under constant pressure to meet ever-higher bandwidth demands. These processing elements do not simply switch or route traffic; they must also perform functions such as building a firewall with Deep Packet Inspection (DPI) capability and offering virtualization support for multi-tenant cloud environments.

The underlying Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and Real-time Transport Protocol (RTP) traffic comprises many packets belonging to a network connection. An intermediate node such as a switch, router, or gateway at the network edge must process millions of network connections simultaneously.

Trying to process each packet in the connection individually inhibits the network element from being able to keep up with ever-increasing line rates. This is further complicated by the need to perform DPI for at least a portion of the traffic. Moreover, an intermediate node located deep in the network must process hundreds of millions of packets.

Each packet has no correlation with any other packet; that is, they are not related in space or time. Such asynchronous traffic is better served by grouping packets into flows. A flow is a collection of packets belonging to the same network session, usually between a source-destination pair. Incoming packets must be classified into flows. The processor then deals with all packets belonging to the same flow in the same way based on rules in a flow state table.

Stateful flow processing

All network elements require states for millions of flows, especially when it comes to implementing security processing such as firewalls, intrusion prevention or detection systems, and application-level load balancers. The resulting platform architecture must support flow state management by monitoring packets within a flow, updating a TCP connection, creating and timing out UDP connections, and tracking Virtual Private Network (VPN) connections. State handling is also required to support TCP proxy and TCP splicing.

System software should thus maintain flow state tables supporting millions of flows. Hardware must support software by performing a complex hash and lookup in a flow hash table. Software is responsible for analyzing the flow hash result and managing new flows, updating the hash table and maintaining the flows’ state.

System performance requirements at 100G

To meet the stringent system requirements at 100G, both processing and memory architectures must meet the time budget offered by one packet time at the worst case of 64-byte packets, which is as low as 5 ns.

Processing instruction and memory budgets

Given that most networks continue to use Ethernet frames or packets as the underlying transport, it is important to understand the composition of these frames and how they affect network performance.

The Ethernet frame

A typical Ethernet frame starts with an 8-byte preamble, followed by 12 bytes of addressing information for destination and source addresses, a 2-byte type/length field indicating the type of date used, and the length of the payload. The payload data can be as low as 46 bytes and as high as 1,500 bytes. A 32-bit (4-byte) cyclic redundancy check is computed and appended at the end of the frame (Figure 1).

Performance calculations at 100 GbE

System throughput calculation is usually expressed in a packets-per-second (pps) figure. The maximum number is calculated when all Ethernet frames are 64 bytes in length, or the minimum size frame. For 10 GbE, this number is 14,881 million pps, or commonly known as 15 Mpps. For 100 GbE, this number becomes roughly 150 Mpps.

Smaller packets present a challenge in meeting the short time budget, while large packets present a challenge in meeting the highest line rate. The per-packet time budget required to process a 64-byte packet is as little as 6 ns. With a processor running at 1 GHz, the instruction cycle time is 1 ns. Hence, a 64-byte packet translates into a 6-cycle budget at 150 Mpps. One way to get around this constraint is to use parallel processing with multiple cores and threads. For example, a 100 cores/threads processor will increase this time budget to 600 cycles – a far more manageable window.

Memory considerations at 100G

The use of specialized memories is not recommended in networking devices. At present, DDR3 memories are the preferred external memories. DDR memories operate well in longer bursts; however, transaction rates for clocks higher than 1,666 MHz reach maximum rate for 64-bit wide interfaces. Exchanging a 64-bit channel for two 32-bit memory channels can deliver higher transaction rates at clock frequencies of 2,133 MHz and higher.

Current approaches to fulfill 100G requirements

Multicore processors

In the early 2000s, many new and established chip vendors started offering multicore CPU products based on standard general-purpose processors, creating Symmetric Multi-Processing (SMP) Linux structures. In leveraging the relatively simple programming model for SMP Operating Systems (OSs), networking vendors were able to introduce products to market in less time. However, this approach was limited to sub-10G levels of performance.

Performance in these processors is limited primarily because traditional general-purpose CPUs have relied on caches to work around memory latency issues. Cache misses force the CPU cores to starve for memory accesses, where main memory latency is way too slow compared to cache memory. This so-called “memory wall effect” implies that the SMP multicore model for processors does not scale to the hundreds of processor cores required to flexibly address 100 Gbps solutions. Attempts to minimize cache misses through branch prediction and speculative execution techniques fall short of solving the relatively low-cache hit-rate problem.

In an attempt to circumvent the performance bottleneck, vendors began embedding hardware accelerators into multicore processors to handle common performance-intensive functions such as security and DPI (see Figure 2). The resulting single-chip heterogeneous multicore processor has given way to proprietary architectures that are not OS friendly, and has defeated the original intent in having a simple, easy-to-program multicore processor.

Network processors

Network processors are a category of processors focused on optimizing L2-L4 packet performance. In general, they contain smaller cores that scale reasonably well and can deliver 100 Gbps of performance. Memory performance is addressed through pipeline architectures, and in some cases, Very Long Instruction Word (VLIW) architectures.

Flexibility and intelligent processing are hampered in network processors due to complex programming and fixed internal structures focused at packet forwarding. Furthermore, performance in pipelined network processors suffers when traffic consists of several tunnels and/or when deeper tunnels are required.

Ethernet switches

This category of chips typically includes small pipelines with internal lookup engines and does not support external memory. Usage was common in enterprise Ethernet wiring closet switches. As the usage models grew in complexity with top-of-rack switches, the flexibility requirements also became more pronounced. Larger lookup tables and greater performance levels are now required from Ethernet switches, as well as several deep tunnels needed to support the many layers of virtualization in the data center.

Although some Ethernet switching chips have access to external ternary content-addressable memory for fast table lookups, a typical Ethernet switch can’t access external DDR memory, making it difficult to cater to networking applications that require support for millions of flows.

Ethernet controllers

This category of products is used in server and client environments to connect multiple Ethernet interfaces to the host x86 CPU through a PCI Express interface. These devices can’t be programmed to perform complex networking tasks such as switching or in-line security. They have no access to external memory and hence can’t support millions of flows.

Now that the challenges of processing network traffic at 100G have been identified, it is important to discuss what is needed to address these challenges. Part 2 of this series, which will be featured in the February issue of Embedded Computing Design, will highlight the need for a coprocessor that can meet the challenges that arise with 100G network traffic. Additionally, the second article will discuss how the new coprocessor manages functions such as intelligent L2/L3 switching, flow classification, in-line security processing, virtualization, and load balancing for x86 CPU cores and virtual machines.

Nabil G. Damouny is senior director of strategic marketing at Netronome.

Netronome
408-496-0022
info@netronome.com
Twitter: @netronome
www.netronome.com

]]> http://tech.opensystemsmedia.com/advancedtca/2012/01/managing-network-traffic-flow-for-multicore-x86-processors-at-40100g-part-1-of-2/feed/ 0 http://www.vmecritical.com/articles/id/?5509 http://www.vmecritical.com/articles/id/?5509#comments Fri, 06 Jan 2012 15:00:00 +0000 Jerry Gipper, Editorial Director, OpenSystems Media http://tech.opensystemsmedia.com/advancedtca/?guid=4d5609c820ead310e3e936ad38633c8d

Computing systems used in rugged applications have traditionally been designed from scratch using
semiconductor-level components. As COTS system-level technology has increased in availability and popularity, the designers of these rugged systems have looked for more integrated levels of technology. These designers would like to leverage the cost effectiveness and time-to-market advantages of COTS boards and systems. Until recently, they have had few choices. That is rapidly changing as the list of possibilities grows. One of those compelling and emerging options in the small form factor arena is VITA 73 (Rugged Small Form Factor).

What began as a solution to a network attached storage problem soon turned into one of the newest small form factor system solutions for rugged embedded computing platforms. Struggling to find a suitable method to package a Solid State Disk (SSD) or a hard drive, PCI Systems CEO Claus Gross pondered a 2.5-inch “X-frame” carrier for SSDs that had been sitting on his desk for some time. Suddenly, on a Monday morning, it struck him that this was just the right size and form factor for a next-generation embedded computing platform.

Many customers over the previous months had commented that they could really use a small-sized system package that was conduction cooled and capable of using the latest in high-performance, multicore processors. A set of requirements soon emerged that would inspire the design for a next-generation platform. The modules they required must:

1. Be small yet high performance.
2. Be rugged, conduction cooled, and completely closed for robust shielding.
3. Be usable in blade configuration with a backplane or as a mezzanine on a carrier by simply replacing the interconnect connector.
4. Be able to operate in a stand-alone mode if necessary, precluding the need for other modules.

These requirements expanded the thought process to include developing a platform with an industry leading function-to-size ratio. This ratio or functional density needed to be higher than anything currently on the market in this class of product. The higher functional density would be key to lowering total system costs because fewer modules would be needed.

These requirements led to the development of a specification for a new rugged embedded computing platform. And PCI Systems brought this specification to the VITA Standards Organization (VSO) to complete the work and turn it into an industry standard. A working group was formed in 2010 under VITA 73 to start the process. VITA 73 was submitted as a specification describing a small, rugged form factor for board modules and the associated backplane profiles. Also included was a specification for standard I/O using MIL-DTL-38999 connectors to make the standard even more desirable for rugged deployments.

VITA was chosen as the most appropriate place to conduct this work because of the dedication of the members to develop open standards for the critical embedded computing market. The experience of the members and the recent work on VPX made the decision even easier. VPX was the impetus for the module interconnect methodology and is used as the basis for the interconnection portion of the VITA 73 specification.

Further requirements helped to guide the development of VITA 73. A complete system or box-level solution was highly desirable. Users of this new platform were not to be burdened with the worry of the integration challenges that other architectures often imposed. The combination of primary and secondary requirements quickly led to a box that did not require wedge locks to retain the modules, as those would have used too much of the premium board real estate defined in the small form factor. The box would instead completely enclose the modules, providing both cooling and secure confinement for rugged usage models.

VITA 73 features

How well does VITA 73 match up to its original design requirements? Let’s look at some of the key features of the specification to find out.

Size: VITA 73 modules are 3 inches wide by 4 inches deep. They are designed to be housed in an enclosure that can have from 4 to 16 slots. The total package for an eight-slot chassis is 4.5 inches wide by 4 inches high by 6 inches deep. This certainly puts VITA 73 firmly in the small end of small form factor platforms yet provides plenty of room for expansion when an application calls for a larger system. Also, the ties to VPX give an additional option to expand into a full VPX system if necessary.

Weight: Size, Weight, and Power (SWaP) are major concerns for many platforms in a multitude of industries. A VITA 73 chassis, when empty, is no more than 1.5 KG in weight (slightly more than 3 lbs). Fully loaded, with a typical payload of modules, results in a box less than 2.5 KG (5 lbs), making this a very lightweight contender. The clamshell packaging eliminates the need for heavy and bulky wedge locks on the printed circuit boards and saves board real estate for valuable functions (Figure 1).

Power: VITA 73 is specified to disperse up to 120 W in an eight-slot cold-plate-cooled chassis. With its conduction-cooling packaging, it can handle most of today’s highest-performance processors, giving it an edge in both electrical and computing power. Computing performance is maintained between modules by using PCI Express as the module interconnect fabric. Modeled after the VPX specification, it can handle similar data speeds between modules. The connectors chosen for the standard are specified to handle 10 GHz signals. To keep the design simpler, interconnects between modules are limited to a star-only topology. This reduces latency, making the overall system faster. It also simplifies the fabric switching between modules, requiring no switching on the modules. VITA 73 uses PCIe Gen2 with a bus width of four lanes and a possibility for a bus width of eight lanes per slot.

Other advantages of VITA 73

Pin-in-socket connectors are used instead of blade-edge connectors, improving system reliability. Readily available straight connectors can be substituted for the right-angle connector to allow the creation of a family of mezzanine modules using the same exact design.

Zero cables and wires are used to interconnect the modules to the I/O connections. PCI Systems’ “No Wires” strategy is used throughout. Wires in rugged applications are not a solution. They will vibrate in the chassis and eventually break at the solder points. Small printed circuit boards are used instead to route signals between modules and I/O connectors, enabling high-speed differential signaling with carefully matched impedance for the high signal speeds. Additionally, assembly and maintenance are simplified because the interconnect modules prevent missed or wrong connections and reduce failures caused by vibration.

Six backplane profiles are defined to accept processing modules, two types of peripheral I/O modules (single-ended and differential), and RF input modules, SATA drives, and power supplies. Allowing for RF coax inputs provides a very reliable and readily available I/O connection.

There are several bonus features included in VITA 73. A 10 MHz single-ended frequency is defined to aid in systemwide data acquisition and synchronize power supplies. Also a star trigger and other trigger functions are implemented. For next generations of PCI Express, the usage of the PCIe 100 MHz clock is defined for all boards used in the chassis and a separate instrumentation frequency of 100 MHz is part of the specification.

Market needs

The analysis of the current market for military computers has shown that the market interest in very small, ruggedized systems is very high, especially for unmanned aircraft with highly integrated electronic control systems. This has spurred interest in the military hardware community to push for development of a standard for a small form factor system.

A new market

Complimentary to VITA 73, there is also a new VITA 71 working group, which is creating a 3U/6U VPX mezzanine board standard that is also compatible with VITA 73.

The VITA 73 working group is on-time and on-track to position itself as “the standard” for unmanned systems, securing all members’ and interested parties’ early stakes in the new market.

]]> http://tech.opensystemsmedia.com/advancedtca/2012/01/evolution-of-a-small-form-factor/feed/ 0 http://www.vmecritical.com/articles/id/?5508 http://www.vmecritical.com/articles/id/?5508#comments Fri, 06 Jan 2012 15:00:00 +0000 Thomas Roberts, Mercury Computer Systems http://tech.opensystemsmedia.com/advancedtca/?guid=0954b7bb3ed4f5ffd68e6c995d591f20

While VME has been supplanted by standards like OpenVPX, which support higher system bandwidths, investments in unique VME modules can be preserved by using hybrid backplane designs.

For more than 25 years, the VME architecture defined COTS systems that met the demand for increases in computing and connectivity. Successive generations of new processors provided more and more compute cycles, while VME bandwidth evolved in a similar fashion from 40 MBps on the original VMEbus to 80 MBps, then 160 MBps, and finally 320 MBps on double-edged source-synchronous transfer.

In its familiar 6U form factor, VME found its way into small 6-slot chassis and large 21-slot systems, as well as many ATR and half-ATR configurations. However, after an incredibly long run, the VME connector finally ran out of gas. As processors continued to get faster, it simply wasn’t possible to coax out any more bandwidth from the bus.

VITA addressed the need for a new generation of standards by pursuing two options. The first option, VXS (VITA 41) has a much higher bandwidth than VME, delivering up to 5 GBps to each payload slot, and also offers a large degree of backward compatibility at the module level. Because the bandwidth is delivered via a switch fabric such as Serial RapidIO, the overall performance impact is even greater.

The other new standard option is VPX (VITA 46), which was developed without the constraint of backward physical compatibility. VPX defines a multiplane architecture approach that provides support for very high-bandwidth communications. The standard delivers more than 10 GBps via a switch fabric to each payload slot over the data plane and equivalent bandwidths over an expansion plane using a point-to-point connection such as PCI Express.

After its initial definition, the VPX standard morphed into a family of specifications, often referred to as “dot specifications,” defining a number of board-level implementation options. The flexibility was nice but resulted in a situation with severe interoperability problems – modules developed by multiple manufacturers didn’t work together. Thus, OpenVPX (VITA 65) was developed to address this issue. Building on the VPX definitions, OpenVPX added the concepts of planes, pipes, and profiles to define an architecture framework for interoperability. OpenVPX is being adopted rapidly in new embedded designs; however, widespread use of VME means the standards will coexist for some period of time.

The need for hybrid backplanes

Despite its success in addressing application requirements, OpenVPX cannot instantaneously achieve the coverage breadth built up by VME over decades. On the financial side, proven VME modules represent significant investments. For example, current intelligence, surveillance, and reconnaissance programs are often challenged to combine data from different types of sensors in real time. Some sensor interfaces have already been developed and deployed on existing programs. Other interfaces are completely new. The goal is to use them all within one platform in an efficient and cost-effective manner.

Meeting this type of challenge sometimes requires the use of hybrid backplanes to bridge legacy technologies by bringing together heterogeneous backplane architectures such as fabric-based OpenVPX and legacy VME into a single system. A major advantage of a hybrid backplane is the ability to continue using specialized, existing hardware and thus preserve years of development and system cost.

OpenVPX lends itself to a hybrid backplane approach. It offers flexibility in terms of interconnects and topologies to mix and match with legacy boards, which enables integrators to custom-design the interconnects over a hybrid backplane to meet the application’s unique needs.

When hybrid backplanes make sense

Not every legacy application is a good candidate for a hybrid backplane solution. However, when key factors align, using a hybrid backplane can save a significant amount of time and money.

In many cases, recreating a custom-designed VME board as an OpenVPX module is cost prohibitive. Industry experience shows that spinning, testing, debugging, and respinning a new 6U board of moderate complexity will cost more than $1 million and require at least nine months, often more than a year, to complete. Alternatively, using a hybrid backplane, development time can be cut to three or four months with costs as low as $50,000. In addition, this approach lowers overall project risks by using proven technology for a specific function.

Hybrid backplanes are an optimal choice for a system upgrade in situations where (a) an existing legacy board performs a function that won’t cause a system bottleneck; and (b) a legacy board was highly customized for a specific purpose and can’t be replaced with a commercially available component.

Hybrid backplane challenges

Although customized hybrid backplanes can be attractive in many situations, they require design and manufacturing expertise to be implemented effectively. As a start, design engineers must determine how many slots are required; which subsidiary protocol each slot will support; which interconnection topology will be required from slot to slot; how communication between the modules will be managed; what voltages will be supported at each slot; and what slot(s), if any, will need rear transition modules. Physical spacing between the slots differs between standards, which must be accounted for in the design plan.

Establishing communication between legacy modules and new system components is a key function provided by a hybrid backplane. For example, communication between a VME slot and an OpenVPX slot involves customized connections between mapped pins on both types of connectors. On the OpenVPX side, the concept of profiles can be used to assist this mapping.

The OpenVPX standard defines a set of system architectures within VPX and provides a framework for interoperability between modules and backplanes. With OpenVPX, system integrators can more readily architect an application-specific system based on compatible OpenVPX profiles for modules, backplanes, and development chassis.

An OpenVPX backplane profile is 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.

Reviewing the following two generalized hybrid backplane options will help show what is possible; however, a great number of variations could be implemented.

Hybrid backplane design approaches

OpenVPX bridge slot

A straightforward approach is to use an OpenVPX bridge slot. VITA 46.1, part of the VPX specification, maps the VMEbus interface directly onto specific VPX connector pins. A hybrid backplane connects the VMEbus signals from the pins in the VME slot to the defined pins in the OpenVPX bridge slot. The bridge module in this slot accepts the VME traffic and then routes it to a VPX-friendly interface – either the control plane (many recent VME applications use VMEbus for control) or the data plane.

When a VITA 31 module is used, other considerations must be examined (Figure 1). Because VITA 31.1 is a full 1000BASE-T implementation and VPX utilizes a 1000-BX SERDES interface, a PHY conversion must be completed to interconnect the Ethernet interfaces. In a conduction-cooled embedded system, a specialized Active Interface Module (AIM) is often created to break out I/O. This conversion can be placed onto that module. The hybrid backplane must be laid out to make the connections from the P0 pins in the VITA 31.1 slot to the designated user-defined pins on the AIM. Note that a bandwidth mismatch exists from what would be available with VME (320 MBps) compared to 2 GbE at 250 MBps.

Map user-defined VME pins to OpenVPX connector

Another simple yet effective method for implementing a hybrid backplane is shown in Figure 2. User-defined pins in the VME P2 connector are mapped by the hybrid backplane onto selected VPX connector pins.

This approach can be used with a PMC or XMC I/O interface attached to the VME module, which brings the I/O down to P2 pins. The user can then implement a lower-speed serial protocol or another parallel interface. Depending on what is being implemented, this could connect to the VPX module’s data plane, control plane, expansion plane, or into the user I/O area.

Meeting unique requirements with a VME/OpenVPX hybrid backplane

Designing a hybrid backplane, mapping out communications, and defining and routing signals all require special skills. And, like most complex technical tasks, these activities are greatly aided by experience.

With careful planning and experienced system architecture design, custom hybrid backplanes can create a path forward for defense contractors. These backplanes help contractors evolve to next-generation technology while continuing to use critical legacy boards, thus minimizing costs, risks, and time to deployment.

Thomas Roberts is a solutions marketing manager at Mercury Computer Systems. He has more than 20 years of experience in systems engineering and technical marketing with IBM, Nixdorf, Data General, Digital Equipment, and Compaq. Tom has a BS in Engineering from Cornell University and an MBA from the University of Kansas. Contact him at troberts@mc.com.

Mercury Computer Systems 978-967-1291 www.mc.com

]]> http://tech.opensystemsmedia.com/advancedtca/2012/01/hybrid-backplanes-combine-openvpx-and-vme-components/feed/ 0 http://www.compactpci-systems.com/articles/id/?5518 http://www.compactpci-systems.com/articles/id/?5518#comments Wed, 04 Jan 2012 15:00:00 +0000 Brandon Lewis http://tech.opensystemsmedia.com/advancedtca/?guid=7e31aa8c7666eb046c8405fd28c92924

Editor’s note: The LTE build out seems at a crossroads, as the technology and availability to transfer voice over an all-IP network while retaining QoS is still not in place. However, the dilemma of offering the exceptional data speeds of LTE with the quality voice services of legacy circuit-switched networks until a Voice over LTE (VoLTE) solution arrives may have found an answer. The Circuit Switched Fallback (CSFB) allows wireless devices to “fall back” to legacy domains to send/receive voice calls. A virtual panel – Drew Sproul, Adax; Venkataraman Prasannan, Radisys; and Niv Kagan and Avi Fisher, SURF – presents details on the CSFB and the partnership resulting in this recent solution. Edited excerpts follow.

CPCI: How close are we to a truly “all-IP” network? What is the status of LTE?

PRASANNAN: If you say, “There is nothing but all-IP network,” no one will agree because there are all kinds of networks in place and a huge amount of copper in the ground that is not all IP. But if you ask, “Are there people who are still deploying the old network? Who’s deploying LTE versus 2.5 G?” you would probably find a small tract of investment in 2.5 G from entities that have some foreseen function, but for the most part everyone else is deploying LTE.

KAGAN: We see our customers starting to deploy LTE networks, and requiring that equipment manufacturers support those different technologies and services. This is driven by the consumer using applications such as real-time video communications, all the way to the operator, who is subsequently required to increase investment in IP, driving an IP network.

CPCI: What is going prevent LTE from arriving at a fate similar to IMS (IP Multimedia System)?

SPROUL: The IMS network standard came out before LTE standards were solidified and when there was not yet the driving demand for multimedia services there is today; Voice was fine and the data speeds weren’t in place to support new multimedia. But tablets and smartphones drove data, video, video streaming – the mantra of “mobile broadband access to the Internet” – and in a way pushed the industry to jump over IMS to LTE, so there are very few IMS subsystems in play today.

PRASANNAN: IMS is being implemented much more slowly on the wireless side, and that’s why it feels like it’s at such a standstill; IMS is getting traction in some of the broadband side infrastructure and getting used. It provides more of a framework and means of dealing with the control and management plane elements, and it has taken much longer to implement that and a service creation aspect in the wireless world.

The LTE promise is the need for speed, and that comes with upgrading the infrastructure to accommodate new network topology and architecture. LTE collapses certain network elements together and makes them more comprehensive or intelligent, if you will. The mobility management that had been very much a part of the Radio Network Controllers (RNCs) and some other base station controllers has been simplified, which translates not only to higher speed but also a cheaper network from an OPEX/CAPEX point of view, ensuring LTE’s viability for the future.

KAGAN: While IMS was driven to provide a next-generation solution for voice infrastructure, LTE is the next generation for both voice and data architecture. As we see subscribers pushing the limits on wireless data usage and willing to pay for wireless data access we believe LTE will continue to deploy for data usage, but constraints on voice are forcing the operators to find other solutions for their currently deployed voice networks, which is where the CSFB comes into play.

CPCI: Generally, what are the past, present, and future of the CSFB?

FISHER: Voice networks have been and are still built on circuit-switched networks, and the technology and network availability is still not in a place to transport voice over an all-IP network to the subscriber. At the same time, adoption of data services is increasing at an exponential rate, forcing operators to adopt technologies for IP networks. The challenge is to maintain all relevant voice services and QoS while providing great data service. This led to the adoption of CSFB, which maintains a circuit-switched network for voice while providing a high-speed data network.

SPROUL: The migration to packet processing requires a middle ground of interworking between the legacy service, switched services signaling, the user plane, and the emerging packet processing-based service. So where we’ve come from is a background of legacy PDM circuit-switched services to LTE, which today is principally focused on building out mobile broadband access to the Internet from smartphones, tablets, and so on, for non-voice services.

KAGAN: We believe that as LTE is adopted, the requirements on CSFB will grow. Initially it will serve as the primary infrastructure for voice communications while it provides the flexibility to migrate to a true all-IP network in the future.

CPCI: How does the CSFB help facilitate the transition from legacy to LTE, and how did the players implement this?

FISHER: The CSFB maintains a circuit-switched voice channel to the subscriber while the transport of media in the backhaul is achieved over IP. This guarantees QoS for voice in wireless networks by interworking with Public Switched Telephone Networks (PSTNs) like wireline, and with circuit-switched networks such as 2G wireless networks that utilize Adaptive Multi-Rate (AMR) over circuit switch (Transcoder and Rate Adaptation Unit (TRAU) frames).

SPROUL: Specifically, in a Radisys ATCA server platform, we’re bringing in Transition-Minimized Differential Signaling (TMDS) zeros from the GERAN network through our T1E1 ports – voice over 64-kilobit DS zero slots; it doesn’t get any more legacy than that. Then our smartcard interworks that voice into Internal Time-Division Multiplexing (I-TDM) packets, which are Ethernet packets based off of an MPLS (Multi-Protocol Label Switching) framework. Then it is sent to the SURF DSP card.

When we set up the connection we exchange Media Access Control (MAC) addresses – no IP involved here. We’re setting up an IPDM channel between us and start sending these packets over the backplane. Then the SURF card gets the IPDM, does whatever magic it needs to do for voice encryption/decryption, and sends it out onto the IP network.

PRASANNAN: In this particular instance, the customer is building a network element which requires a particular functionality and incorporates a Line Interface Card, a DSP resource, and because a modular AMC form factor is being used as a host to incorporate the two, the customer is left with the task of putting these three pieces together, integrating them, and building an application on top of it.

Radisys, ADAX, and SURF brought our contributions together to make this integration as seamless as possible, accelerating time to market. At Radisys we have a framework and a mechanism to make this happen more naturally with our Alliance Partner Program, in which all of the players were already involved.

CPCI: How long will it take to complete the transition to LTE, and what is the CSFB’s longevity?

SPROUL: There is still a lot of legacy gear and service in the field that needs to be interconnected, and it’s not just a holding pattern while those are decommissioned and replaced. What’s actually happening is that LTE is an add-on to existing service networks to provide data services, and therefore you get upgraded legacy systems with the CSFB.

The transition depends on how TEMs (Telecom Equipment Manufacturers) address the VoLTE and circuit-switched connection. What the VoLTE initiative requires is an IMS services plane for LTE networks to send voice traffic for true VoIP. In an LTE network, this is gobbledygook, but in an LTE/IMS system, the network just picks it up like it always has. For now, all the arrangements that support voice and text messaging will remain in place.

FISHER: The complete transition will only occur once the LTE network provides the same level of quality for the voice channel over IP as over circuit-switched network. Then there will be a truly all-IP network from the subscriber to the network and beyond, but we haven’t seen a deployed technology that is able to achieve this yet, and therefore it will take at least a few years before the CSFB will not be required anymore.

CPCI: If there were no such thing as AdvancedTCA, would it have to be invented or is CSFB more agnostic?

SPROUL: ATCA is the perfect vehicle for CSFB because you can re-architect your existing concentrator networks by leaving the RAN in place and architecting access gateways and concentrators to legacy networks like GERAN and UTRAN.

So now you’ve got TDM and ATM (Asynchronous Transfer Mode)-based services that you want to get onto your IP core; ATCA-based products facilitate that by on the one hand speaking legacy via zero or ATM, and on the other speaking IP, and the beauty of ATCA is that the Ethernet IP cores are built into the architecture.

That is a crucial component of the ATCA architecture, and the second main point as the CSFB gets to deployment is the need for High Availability (HA) and preventing loss of service. Because ATCA already has a redundancy built into it, it makes it easier for things like HA for the user plane to be implemented. That’s all an integral, fundamental part of the ATCA architecture; so yes, if ATCA didn’t exist it would have to be invented.

CPCI: How significant do you anticipate ATCA to be in your next win? What are the promising ATCA markets moving forward?

SPROUL: Our next two opportunities in this domain are in China, and ATCA is crucial because of, again, scalability, flexibility, and the challenge that we’re addressing now: interworking. Adax has always been an advocate of open system standards, both in terms of software and hardware development and platforms. We sell to the broad telecom market, and an open standards-based interoperability is one of our core business and technical principles.

KAGAN: LTE is built in a flat IMS architecture and therefore promotes independent nodes of different scale and functionality, as opposed to the legacy approach of a centralized large switching system. This approach promotes different TCA architectures based on the network requirements.

On a global scale, we feel that the promising ATCA markets are those with a high concentration of users that adopt technologies requiring high-performance, real-time computing and communication technologies, especially in video with its vast requirements for real-time processing and ultra-high bandwidth in the all-IP domain.

PRASANNAN: We are seeing it pretty well balanced, and our ATCA split is one-third, one-third, one-third (Europe, Asia, and North America). It tends to be driven by where the TEMs are, and if you look across those geographies, there are definitely equipment manufacturers present in all three.

The telecom market will continue to be present and grow at a fairly attractive rate, but ATCA is also spreading its wings to other market segments. I’ve seen some network monitoring, which is a segment that has a lot of ATCA presence, and I’m sure it will continue to grow in that space. Another opportunity I can cite is Aerospace and Defense, which is looking for more of the ruggedized alignment and performances dictating higher processing power and higher network performance; it’s just a combination of time and the artifact of the segment.

Telecom itself was a fairly long cycle compared to enterprise, and Aerospace and Defense is an even longer cycle: 15 to 20 years. You start seeing growth after the fourth or fifth year. That’s the nature of the segment and it also takes time for those things to come up for re-evaluation on that long of a cycle, so you have to wait it out.

]]> http://tech.opensystemsmedia.com/advancedtca/2012/01/fallback-to-the-future-circuit-switched-networks-as-a-voicedata-solution/feed/ 0 http://www.compactpci-systems.com/articles/id/?5512 http://www.compactpci-systems.com/articles/id/?5512#comments Wed, 04 Jan 2012 15:00:00 +0000 Tony Romero, PT http://tech.opensystemsmedia.com/advancedtca/?guid=083d6ebde2fecdc201c27e031a5994dc