Michael Thompson on the 40-Gbit challenge

May, 2010
By: dl

Michael Thompson, Principal Engineer at Pentair Technical Products, has left his imprint on innumerable embedded computing standards over the past decades as part of the VSO and PICMG efforts. What’s Thompson working on now? OAR asked.

OAR: So, what have you been working on lately, Mike?

Thompson: I’ve been working on lots of ATCA and uTCA projects related to PICMG specification enhancements. One item in particular should be quite a challenge: supplying more than 600 Watts to double-slot ATCA blades that support 40 Gbit Ethernet. There are challenges here in performance, cooling, power distribution and mechanics.

OAR: Whew!

Thompson: The original ATCA systems were intended for use with 1 Gbps Ethernet fabrics on the backplane. This was not difficult to achieve with careful PCB design. The second generation of ATCA systems supported 10 Gbps fabrics. This required lots of simulation and empirical testing to determine the optimum PCB design for a reliable fabric. Now the goal is 40 Gbps fabrics. That will yield a really impressive theoretical max bandwidth through a full mesh backplane of over 10 terabits/second!

OAR: That’s a pretty good leap.

Thompson: Getting 40GBase-KR4 running on a backplane has been very challenging.

OAR: We’re really talking about 10 Gbits/sec on a differential pair, not 40 Gbits/sec, right?

Thompson: That’s correct, 10GBase-KR is 10 Gbits/sec on a single pair, and 40GBase-KR4 is four of these pairs. The signal integrity requirements are very stringent and very difficult to meet. The signaling rate is significantly higher than what the ATCA specification originally planned for and what the backplane connectors were originally designed for. There are higher performance connectors in the works, though, that will mate with the existing connectors.

OAR: So have you been successful running 40GBase-KR4 on ATCA?

Thompson: Yes, through a combination of very careful PCB design for the blades and backplanes, even more simulations and empirical testing, the improved backplane connectors, and some real magic in the transceivers, we have demonstrated a backplane working reliably at 10 Gbits/sec per pair. 40GBase-KR4 is just four of these pairs. Our backplane wizard, Andreas Lenkisch, spent a lot of time simulating different layouts to determine the best design, then we built and tested different versions of backplanes to prove that the simulations reflected reality.

OAR: Who do you mean when you say “we”?

Thompson: Pentair/Schroff simulated, designed, and built backplanes and then verified their behavior with Agilent signal integrity tools and a 10GBase-KR4 test set from Vitesse. We then sent the backplanes to Intel who tested their behavior with 10GBase-KR transceivers. They reported excellent behavior and a BER of less than the required 10-12.

OAR: How important were chips and connectors in reaching the goal?

Thompson: Both were important. Because of the way the connectors are manufactured, the performance of the right-angle connector that goes on the blades was easier to improve. Both Tyco and Erni have developed an improved blade connector that can handle the higher frequencies. They are backwards compatible with the original connectors but have reduced crosstalk, better impedance control, reduced intra-pair skew and improved insertion loss characteristics. We would really like to see the via size for the backplane connector reduced, though. That would further reduce impedance discontinuities and signal reflections.

OAR: And chips?

Thompson: Chip manufacturers have improved their designs to the point where I would call their behavior “magic.” I have seen images of eye patterns on backplanes (not ours) that were completely closed, yet the data transmission worked flawlessly. With all of these improvements in the interconnect, we can demonstrate–and we have demonstrated–systems that work reliably at 40 Gbps.

OAR: What were the cooling issues you faced?

Thompson: When ATCA was originally developed, cooling 200 Watts per single-slot blade was a stretch goal for existing technology. We are now working towards much higher blade power dissipation levels. Fortunately, the target market is the Enterprise and not the Central Office. This means that the maximum ambient temperature will be about 20°C less than it is for existing telecom ATCA equipment.

OAR: What is the cooling burden of these megablades?

Thompson: We will need to move massive amounts of air to cool the proposed blades while keeping the acoustic noise from the chassis at reasonable levels. Fan manufacturers have really increased the flow rates for the fan sizes that we use. Just as with the backplanes, we are performing simulations and empirical testing to improve the air flow rates.

We also offer liquid cooled cabinets to house the ATCA chassis. These cabinets reduce the ambient temperature by about 20°C, reduce the acoustic noise from the fans and increase the system’s MTBF. This allows for very high power densities without the associated noise. In cold climates, you can even recover the heat from the ATCA blades and use it to help heat the building.

OAR: That’s interesting. How would you get the heat from the blades into a building’s heating system?

Thompson: Many office buildings circulate water for cooling and heating. During the winter, furnaces heat the circulating water and then heat exchangers use the water to warm the air in the rooms. Instead of dumping the thermal energy from the blades into the atmosphere, you put it into the building’s circulating water. Then you can use the blade’s energy to heat the building.

OAR: What are the power distribution issues you face?

Thompson: An existing ATCA system has a maximum possible dissipation of less than 4 kW, or about 80A of -48V. We are now considering systems with a maximum dissipation of more than 10 kW. That means we need to distribute more than 200A of -48V. This is a huge amount of power to move through a backplane that supports redundant hot-swappable FRUs.

OAR: And the solution is…?

Thompson: The solution is always lots of copper. The power connector manufacturers are retesting their products using a procedure that is closer to reality than traditional testing. The results show that the existing power connector can handle the increased current as long as there is sufficient copper in the PCB.

OAR: You also mentioned that there are some mechanical challenges. What are they?

Thompson: One of these chassis could be over two feet deep and weigh about 75 kg empty. Supporting the weight of 14 high-power blades will require a substantial mechanical structure. We can’t just add massive amounts of metal to the structure because it would increase the cost and possibly impede the air flow. So we are back to simulations and empirical testing again.

OAR: Mike, you noted that this hypothetical 40 Gbit/sec-capable system is taking aim at the enterprise market. Does that mean that the T in ATCA doesn’t stand for “telecommunications” anymore? I remember a few historical precedents such as when RAID changed from redundant array of inexpensive disks to redundant array of individual disks.

Thompson: Even though the original target market for ATCA was telecom, we quickly found that our customers were using ATCA systems in the enterprise and even the military market. Maybe we should change the “T” to “technology?”

OAR: What attracted these two other market segments to a telecom-oriented architecture?

Thompson: I would say that the primary interests are threefold: management, very high performance fabrics and flexibility.

The comprehensive shelf management capability of ATCA will let you know when sensor readings are abnormal long before they generate an alarm. For example, the fan tachometer sensors can tell you that one fan is running 500 RPM less than the other fans in the chassis. This slow fan will fail but not for quite a while. This will give you ample time to schedule a fan tray replacement when it is convenient, not after cooling is compromised.

There are also System Management solutions available from companies like ENEA and GoAhead that can automatically reconfigure the blades in the chassis based on abnormal sensor readings or if a blade fails. These management tools can really increase the MTBF of the chassis. Achieving high MTBF is not just a telecom goal.

OAR: What about performance?

Thompson: The potential bandwidth of a full-mesh backplane running at 40 Gbps is really impressive. It is much simpler to run 40G between blades over the copper in the backplane than it is through a nest of optical cables between rack- mounted servers.

OAR: And flexibility?

Thompson: The fabric agnostic backplane allows you to run Ethernet, PCIe and Fibre Channel on the same backplane at the same time. This allows the user to reconfigure the chassis architecture as needs change, instead of replacing the whole chassis. Everyone likes flexibility.

*************************

Michael Munroe on the 10-Gbit challenge

May, 2010
By: dl

Michael Munroe, a product specialist at Elma Bustronic, is one of those unsung heroes who populate the technical working groups of industry organizations and do the nitty-gritty work to create real-world standards. OAR caught up with Munroe between working group meetings a few weeks ago to discuss the 10-Gbit signal integrity challenge.

OAR: What are the most challenging technical issues facing the embedded computing community today?

Munroe: Unquestionably the biggest challenge is the implementation of a channel that meets the IEEE 802.3-2008 requirements for 10-Gbit Ethernet Base-KR: that is, a single bidirectional link with one transmitter pair and one receiver pair. That’s a challenge that’s common to VSO, PICMG and other standards organizations and one that’s only been dealt with in a notable way by the OIF [Optical Internetworking Forum], which has defined a physical link layer for 11-Gigabit Ethernet on the backplane: OIF-CEI-02.0

OAR: But doesn’t IEEE 802.3 take care of business?

Munroe: The IEEE spec is media independent. You can implement any kind of backplane across any kind of connector up to about 30 inches. While it does give you the BER [bit error rate] requirements for the entire channel, as well as some non-normative requirements, it doesn’t precisely define the division of channel segments or suggest how the loss budget might be divided between backplane and daughter cards.

OAR: Why is that a problem?

Munroe: Somewhere between 3 and 10 Gbits/sec, we crossed into a different world where life began to get more complex and our standard tools became insufficient. Reaching towards 10 Gbits/sec, defining requirements is no longer as simple as finding the S parameters for a channel or portion of the channel. It is no longer enough to simply define the S21 attenuation limits for the channel at different frequencies. There is no longer agreement among experts as to how to define a good channel by any commonly used parameters other than BER.

At these new data rates, the channel becomes so sensitive to the combined effect of many parameters that a set of parameters that works for a long backplane path will not work for a shorter and therefore presumably less challenging path length. Not only are accepted ratios for crosstalk and insertion loss uniquely dependent upon the specific impedance profile for a path, but the moisture present during PCB processing can degrade the path in subtle ways that cannot be defined by any single parameter but which are revealed only in an overall BER measurement.

OAR: Can’t defining more variables help?

Munroe: Let’s assume that you had a sufficiently precise physical description of a fabricated PCB assembly including the location of every glass fiber and every copper nodule and the distribution of each polymer constituent and you had a usable electrical model of how these high-speed signals transverse that precisely defined geometry. Even then, you would still have the challenge of manufacturing this exactly defined physical structure.

To be able to manufacture it with exact fidelity, probably molecule by molecule, would really be fantastic because not only would you have solved today’s signal integrity dilemma, but at the same time, you would have also created the world first working Star Trek replicator.

OAR: Can’t we already manufacture these assemblies with exact precision?

Munroe: Even in better materials like the PCB laminates from Rogers, Isola or Matsushita, the glass fibers float around in a matrix and it’s only predictable in a statistical way where those fibers are going to be in relationship to any given trace. At these speeds, that has become a significant problem.

OAR: Any help on the horizon?

Munroe: One fortunate aspect for now is that Intel is scheduled to release some studies this month which show that today’s transceivers are 10G Base-KR capable even in environments that clearly do not meet the signal integrity requirements of that spec. They are so capable that they can work with sort of a negative noise margin. In other words, it appears that today’s transceivers can salvage information successfully out of this murky and unpredictable soup of circuit noise.

OAR: Well, doesn’t that take some of the pressure off?

Munroe: It probably does provide more latitude in getting the backplane physics right, but it doesn’t simplify the challenge of choosing a useful collection of parameters that will accurately define a required backplane channel.

OAR: Does that latitude translate into looser specifications and, therefore, lower cost for 10-Gbit systems?

Munroe: Well, first let me state that I am primarily focused on a lower-volume rugged industrial and mil/aero market segment. For our market, I believe that a more loosely defined backplane would result in a false economy. A lower cost in backplanes is only one aspect of a loser system cost.

My feeling today is that the backplane should be very tightly defined because that establishes a known environment that’s more attractive and easier for blade manufacturers to design to. Having the backplane portion of the channel tightly defined also invites more applications and signaling protocols. If you try to leave wiggle room so you can design something really inexpensive that could still meet the requirements, in the end that makes the entire architecture itself less attractive.

OAR: We’ve both seen situations where people didn’t want to define things too tightly but preferred to provide flexibility instead.

Munroe: Yes, that might seem like a thoughtful motivation, but it can work in a very subtle way to give you things that, as Ray Alderman would say, are “festooned with the barnacles of bureaucracy,” but don’t provide actual interoperability. When people choose to leave a specification loose so as to allow flexibility to be implemented at less cost, that also means you’re going to be dealing with a world that’s not well enough defined to attract a lot of people to the same table.

OAR: How far along are the various working group committees on their 10-Gbit work?

Munroe: The issues are being addressed in PICMG 3.1R2, 10G Ethernet over ATCA; and VITA 68, VPX Channel Compliance. We will be occupied for a while because for many debatable reasons, the IEEE did not really do its job by defining rigorous test methodologies that are translatable into writing definitions to characterize an interconnect channel.

OAR: What’s VITA 68 all about?

Munroe: VITA 68 was formed to allow VITA 65 and the VITA 46 versions to move ahead without having to address all the signal integrity issues that in general are beyond most of us who aren’t signal integrity engineers. It is establishing the requirements for a number of different signaling protocols, the most challenging of which is 10G Ethernet. That will probably be followed by DDR Serial RapidIO and PCI Express Gen 2. 

OAR: Aren’t there any signaling integrity specialists at the working group meetings?

Munroe: Some of the larger companies do have signal integrity resources that are of the caliber required to make these decisions, but they’re too valuable to commit to what can seem like endless committee meetings. The working groups will define the general requirements for channel characteristics and, then, in the balloting stage, the documents will be placed in front of members’ best signal integrity people who are really qualified to comment on it. That’s a better use of their time.

OAR: Any particular challenge come to mind regarding 10-Gbit Ethernet Base-KR? 

Munroe: Handling 10 Gbits/sec on a single channel is a real challenge. We know how to do it on four channels, but we haven’t always adequately defined many aspects, such as where the reference points are. The reference points can be theoretical, by the way, because there’s a lot of math that allows you to de-embed a channel to different points. We often need this latitude to define to reference points that can’t be instrumented directly. That’s because once you actually instrument a circuit, you disturb it too much to learn how it would behave in an undisturbed condition.

OAR: Then how (or where) do you instrument?

Munroe: You instrument at a point a little distance away, where you have something really well defined between where the instrument is and your desired reference point.

OAR: So the measurement point is really not at the reference point?

Munroe: Right. And there are also techniques that allow us to make the measurement points nearly invisible in the frequency band where we want the measurement to be most accurate.

OAR: So it sounds like single-channel 10G Ethernet is still a ways off.

Munroe: We’ve all demonstrated our ability to implement a 10-Gbit link on a single-channel, and devices exist that are needed to build the circuits. However, for the VITA and PICMG communities, to define a family of standard backplanes that are useful for multiple protocols, to create the needed recipes everyone can follow reliably, and to agree on how to validate these platforms as meeting the full requirements—-this task is still months away from completion.

******************************************

Ernest Godsey on B2B marketing

March, 2010
By: dl

Ernest Godsey has been involved in embedded systems since the advent of the microprocessor. Along the way, he’s served as vice-president of business development at Interphase Corporation and president of MEN Mikro Elektronik’s U.S. subsidiary MEN Micro Inc.  Godsey is currently the president of Godsey Technical Associates, a consulting firm that provides marketing services to companies in the embedded marketplace. He also maintains EmbeddedDIRT.com, a website with blog devoted to news, information and commentary on the embedded computing industry. OAR caught up with him to discuss some of the in’s and out’s of marketing for high tech companies in the embedded computing space. 

OAR: What are some prime examples of B2B marketing that worked great and ones that bombed?

Godsey: VITA’s a great example of B2B marketing that works. You and I remember when it was not much more than two printed directories a year. I always thought that VITA was primarily Lyme Hevle’s retirement plan, but Ray Alderman had enough vision to translate it into an ongoing enterprise that is still delivering value today. The landscape is littered with organizations that didn’t make that transition.

OAR: Like the Multibus Manufacturers Group?

Godsey: Yes, the Multibus Manufacturers Group would be an example of an organization that has disappeared, but I also had in mind the VXI-related publications and tabletop shows organized by Fred Bode et al. He was publishing a directory of VXI products and companies, more or less at the same time VITA was publishing the VMEbus product directories. Concurrently he was organizing the DATA shows, which were very successful tabletop VXI shows.

Today, all of that seems to have evaporated, even though companies are still deploying VXI-based machines in the test environment. I don’t know if this speaks more about the differences in the energy and inventiveness of the practitioners involved in the two groups or about the differences in the leadership of the two groups. Regardless, the end result is not a matter for debate. VITA and the VSO are still robust, providing an organizational framework for activities in a variety of endeavors.

OAR: All of VITA’s moments haven’t been golden. Remember the VFEA—VMEbus-Futurebus Extended Architecture–aka the Futurebus fiasco?

Godsey: You are absolutely correct. Not everything that Ray Alderman and VITA touched over the years turned into gold. But perhaps knowing when to move on is one of the hallmarks of real genius. Hockey great Wayne Gretzky said: “I skate to where the puck is going to be, not where it has been.” That’s what technology leadership and good marketing are all about: correctly assessing where the market is going to be and then positioning yourself there.

OAR: Any other positive B2B marketing efforts worth mentioning?

Godsey: I also admire the guys who pay attention to the details of marketing, to the blocking and checking of everyday marketing in the embedded space. To follow the hockey analogy: It may be fun to skate free to where the puck is going to be, but once you start toward the goal with the puck, you’d better be ready for some serious body checking.

John Wranovics [of Curtiss-Wright Controls, Embedded Computing]  is one guy I know who pays attention to the details of marketing. All of the marketing from Curtiss-Wright Controls is on message, on target and easy to navigate. He does this day in and day out. Much of it’s not glamorous, but he’s getting the job done. But it’s more fun to talk about stuff that doesn’t work, perhaps because there’s so much of it.

OAR: Can you share some of your favorite negative examples?

Godsey: I once had an advertising agency tell me that their “client did not believe in landing pages.” They were planning an e-mail campaign and were using this as the explanation of why there would be no landing page, no unique URLs and no trackability. I wanted to ask them if their client believed in gravity.

Another piece of B2B marketing that doesn’t work is a website with no search function. Presumably the objective is to make the poor schmuck click thorough every piece of arcane navigation on the website. But the Internet does not have an exclusive lock on dumb marketing. The inside back cover of the Feb. 1, 2010 issue of eWeek has a 2D barcode for Microsoft Windows Server and Microsoft SQL Server. What a great plan! I have no doubt that 2D barcodes (and smart phones) have a great future interacting with mobile consumers in real time. But what mobile consumers in real time have to do with an ad aimed at data center managers and database administrators is beyond me.

OAR: What are your favorite marketing tools?

Godsey: I like trade shows. (I miss BUSCON and COMDEX.) I actually enjoy talking with real engineers, who have real projects and who could use my product to solve a problem. One of the really dumb things I see at trade shows is a booth arrangement that keeps people out of the booth. Typically it’s the guys in 10′x10′ booths. They position a long table right up against the aisle … like a bake sale. I highly recommend this arrangement if your objective to keep visitors out of your booth.

OAR: Trade shows, of course, aren’t what they used to be.

Godsey: Trade shows have been supplanted by Internet based social media like Twitter. So now marketers have more hi-tech ways to do dumb things. Like the guys who know they can’t spend 8-hours a day tweeting, but they read somewhere that to be effective they should make 6 to 8 tweets every day, so at 8:05 a.m. every day, they send 8 tweets out, one right after the other. Guess they haven’t heard of any of the scheduling tools like HootSuite. These are probably the same guys who never “listen” to what’s being tweeted about them (or their companies). It’s a shame, because Twitter is a neat tool for learning what is actually important to your users/customers.

OAR: What are the silliest and/or worst sounding product names you’ve encountered?

Godsey: Two of the worst are Wii and iPad. The Wii has been very successful, and I suspect the iPad will be very successful, but neither is because of the cool name.

Before I arrived at Interphase, they had been successfully marketing products with numbers and products with names. I was of the opinion that in the B2B market, it didn’t make any difference, so I started assigning names and marketing numbers to new products. For a while, we used the names of fast cats–Jaguar, Panther, Cheetah, etc.–for our disk controller products.

I remember one COMDEX where we were introducing one of these new “fast cat” disk controllers. We had done a good job getting press coverage before the show so we had a fair number of engineers come by the Interphase booth on the show floor and ask to see the board, to talk about it, etc. I kept an informal tally. About half asked for it by name, and about half asked for it by number. Since then, I haven’t lost any sleep over a product name.

OAR: That type of labeling for embedded products irks me. Does it really work?

Godsey: Sure it does because the engineers who specify and design-in products are people. So a lousy name can hurt, if it’s hard to remember, for example, or it conjures up something unpleasant. But you don’t need to spend $50k to figure out if a name is offensive. On the other hand, a great name won’t help if the product is too expensive, doesn’t have the performance that is required, isn’t reliable, etc.

OAR: I remember when Interphase was one of three high-end disk controller companies in the 1980s, sharing the stage with Ciprico and Xylogics. Only Interphase has survived. Why do you think that is?

Godsey: There were (and still are) a lot of smart engineers at Interphase. We realized that the “standalone” disk controller was going the way of the buggy whip, so we looked around for other places where we could apply our proprietary “BUSpacket” technology. The first area we tried was in various NICs [network interface cards]. Just as disk controllers are the interface between the processor bus and the mechanical clap-trap of a disk drive, NICs are the interface between the processor bus and an external data stream, with both physical layer and protocol considerations. So in many ways, much of the technology of NICs was similar to that of disk controllers.

We started with Ethernet controllers. (Yes, it took an entire 6U VMEbus card to implement a single Ethernet controller in those days.) Then we moved to FDDI controllers, where we eventually dominated the market. After that, to offload protocol processing from the main processor, we started putting additional compute bandwidth on NICs.

OAR: What was the rationale there?

Godsey: At that time, network bandwidth was being raised by a factor of 10X with each new generation, while processor clock speeds (and processing bandwidth) were inching forward by only factors of 1.5X or 2X per generation. So just when processor bandwidth would catch up to the network bandwidth, the network would ratchet bandwidth up by another factor of 10X, leaving the processors overwhelmed by the task of processing the network traffic. Thus, there was a market for NICs that furnished additional processor bandwidth, bandwidth that could be applied to handling the protocol stack.

OAR: What are today’s 3-5 biggest buzz words? Do they really mean anything?

Godsey: My favorite buzz word today is MID, which is Intel-speak for Mobile Internet Device. I love it! Do you know of a single product that has been introduced as a MID? I don’t. Now, plenty of Mobile Internet Devices have been delivered, but they’re called iPhones and, as far as I know, they’re powered by ARM processors, not Intel Atoms.

My next two favorite buzz words are “Cloud Computing” and “Green.” These are both great buzz words because they can (and do) mean almost anything. When you use them to describe your product, the listener will endow your product with all sorts of positive virtues, which may (or may not) have a basis in reality, but the important thing is that they put your product in a positive light.

There are, however, some buzz words that actual mean something. SaaS (Software as a Service) is one example. No ambiguity here. The listener immediately knows the licensing model without any long explanation. That’s why buzz words that actually mean something are useful. They speed up the information transfer, and it is almost always a good thing to improve the utilization of the available bandwidth.

OAR: If you could give only one piece of marketing advice to companies making embedded computing products, what would it be?

Godsey: I maintain that marketers in the embedded space not only need to understand the technology that they are marketing, but also need to remember that they are marketing to engineers who also understand the technology. This has two implications.

First, they need to use this knowledge to direct new product development. The successful companies in the embedded space will be those companies that have a “high view” of product marketing. In such companies, it’s the guys with the overarching understanding of the direction of the technology and of the market who set the direction for new product development. This is, after all, the direction of the company.

Second, they also need to let this knowledge impact their marketing message and the medium they use to deliver their message. This is getting harder to do. For example, how do you deliver a compelling marketing message on the latest deep packet inspection technology in 140 characters? The successful guys will figure out how to do it.

***********************************************

Bob Burckle on small form factor computing

February, 2010
By: dl

WinSystems vice president Bob Burckle has been involved in small form factor computing since the late 1970s and the days of STD Bus. How do small industrial computers stack up today, four decades later? What’s been the impact of high-speed serial links? How powerful are legacy interconnects? Burckle discussed these questions, the schism between the PC/104 Embedded Consortium and Small Form Factor Special Interest Group (SFF-SIG), and other topics with Open Architecture Review. 

OAR: What are tha major trends you see in embedded computing today? 

Burckle: When you look at things from the 30,000-foot level, the big picture is “How do I get I/O out of a computer?” How do you attach one of the latest generation processors to an application and make it useful? Just having the best performance from a processor module doesn’t do you much good without the right I/O.  

Another issue is size.  We see more and more functionality packed into less and less space.  Designers are faced with issues of heat, packaging and interconnect technology. 

Finally how do you balance legacy vs. the newest technology?  We see this with PCI Express [PCIe] replacing PCI, USB replacing COM, LPT, mouse and keyboard interfaces, and SATA replacing PATA on the newest processors and chipsets.

 OAR: What’s the “right” I/O? 

Burckle: There’s a plethora of different answers to that question which are dependent upon whether it’s a commercial, industrial, medical or military environment. One needs to consider the issues of functionality, as well as physical interconnection, safety, security, redundancy, RFI/EMI, regulatory compliance, extended temperature operation, plus shock and vibration. System designers need to take different paths to provide the same basic I/O in different environments, especially as it relates to areas of ruggedization. 

OAR: What about in the stackable small form factor world? 

Burckle: What we’re seeing in the stackable realm are different architectures and products from a number of different vendors and standards organizations, all trying to address the same issue: how to get from the real world to the digital domain to wherever the final decision making or monitoring has to occur. What differentiates different approaches is how they package it and balance the amount of I/O power, the size of the connector, the size of the board, etc. Typically what we’re finding is that smaller is better for more and more applications. 

OAR: WinSystems is a member of both the PC/104 Embedded Consortium and the Small Form Factor Special Interest Group, which have competing approaches to bringing the PC/104 framework into the modern age. You’ve opted for the SFF-SIG’s architectures: SUMIT  (Stackable Unified Module Interconnect Technology) and COMIT (Computer on Module Interconnect Technology). Why? 

Burckle: First of all, SUMIT is a connector specification, not a form factor. It allows boards to be stacked together while supporting high-speed signals such as PCIe Gen2. This allows the smaller SUMIT-enabled interconnect solution to be used on a variety of different boards from as small as a 60 x 72-mm Pico-I/O modules to a 5.75 x 8.0-inch EBX-sized board. 

SUMIT represents an amalgamation of a number of very popular interfaces that we’re continuing to see on new x86-based silicon from major semiconductor companies. And that’s PCI Express, USB, LPC Bus, SPI/Microwire and SMBus/I²C Bus. 

From my perspective, as well as that of other embedded companies, SUMIT has the best mix for our particular customer base, especially since it [the SUMIT connector] can be used on different SBCs or I/O cards while taking up a very small amount of space yet supporting tremendous processing power. 

OAR: Why include low-speed buses such as LPC and SPI in the SUMIT mix? 

Burckle: LPC and SPI are gradually replacing the popular ISA bus. These signals are supported in the latest generation of chipsets since they reduce total pin count while still offering an easy, cost-effective way to interface with simple I/O devices. 

If you’re going to do something like toggle a relay on or off, using PCI Express is like trying to get a drink of water out of a fire hose. The data’s coming out so fast and hard that you have to add bridges and software to be able get the data down to where you can use it. So you think to yourself, “Isn’t there an easier way to do this?” And the answer is “Yes!” So it makes sense to dedicate a small number of pins to do such things. The LPC bus is particularly useful for that, as well as providing a bridge to support legacy ISA bus devices on PC/104 cards. 

OAR: When SFF-SIG splintered off from the PC/104 group a few years ago, it reminded me of the STD schism in the early ‘90s over the issue of 32-bit expansion. Is this the same kind of schism? 

Burckle: Unfortunately, yes. It comes down to a philosophical difference between two groups. The SFF-SIG’s charter is devoted to identifying, creating and promoting standards that help companies move to small form factor technologies in their products in order to protect their investments over the long term. The SIG is focused on the new ultra low power and mobile processors, as well as other emerging technologies. 

The Consortium’s new specification supports PCIe expansion on a 90 x 96-mm board but no longer directly supports PC/104 modules since the PCIe connector occupies the exact location of the PC/104 connector, forcing its obsolescence. This requires another interface board to convert either PCI or PCIe signals to ISA so that existing off-the-shelf standard or customer-designed PC/104 boards can be added to a stack. 

The Consortium also opted for a x16 PCIe, which requires a larger, more expensive connector and does not support as many USB and other legacy interfaces. We feel that x16 PCIe may be appropriate for high-end video displays, but it demands too much power otherwise, creating cooling issues for small, stackable solutions. Moreover, x16 PCIe is not supported by the latest Intel Atom and VIA Nano families of low-power chipsets designed for the embedded market. Besides, most of that market already went to COM Express due to the advantages of using a simple heatspreader over custom heat pipes and milled aluminum blocks. 

In my opinion, these issues are show-stoppers. We weren’t able to philosophically work out our differences, so we agreed to disagree. The SFF-SIG has come to market with our SUMIT-ISM [Industry Standard Module] solution, and embedded customers wanting stacking solutions will vote on the alternatives with their dollars and Euros as to which suits their needs best. WinSystems is still dedicated to PC/104-based products since the ISA bus is not EOL in stacking applications, and we will continue to introduce new products based on this popular worldwide standard.    

OAR: I can’t say I’ve seen much activity yet in SUMIT and even less in COMIT. Will this change?

 Burckle: The SFF-SIG expects 2010 to be the breakout year for people designing them in, but SUMIT has the most activity based on the connectors showing up on PC/104 size boards plus EPIC and EBX size boards. You also have SUMIT-based products on Pico-ITXe and Pico-I/O boards.

COMIT is behind because it came out a year and a half after the SUMIT specification. However, WinSystems introduced the first COMIT-based SBC using Intel’s Atom processor at ESC/Boston in September 2009. Look for significant activity and new product introductions at Embedded World in March [this year] and the Embedded Systems Conference/Silicon Valley in April. 

OAR: There seem to me to be too many COM specifications around like COMIT. Couldn’t the SFF-SIG have adopted something that was already out there?

 Burckle: We first surveyed the market of COM products in an attempt to use an existing standard.  However, none of them met our design goals at the time. 

OAR: Specifics? 

Burckle: The then-current PICMG spec, for example, only supported PCI, and we wanted a smaller, more robust, high-speed connector with one instead of two connectors to eliminate connector registration tolerances. For COMIT, we wanted to support at least second-generation PCIe, USB 3.0, SATA 300 and 10 Gbit Ethernet. For long-term availability, we didn’t want to define a product that we would have to redesign in a year or so. 

OAR: Frankly, I don’t understand the rationale for the ISM spec. Do I understand right that it addresses only board dimensions and mounting holes and that these are the same as for PC/104?

Burckle: Yes. The purpose of ISM is to define a truly open standard for modular, stackable systems.  Customers were confused about whether PC/104 refers to the bus, the board outline or both. We’re trying to codify, define and provide some semblance of clarity and structure within the multiple variations you’re seeing in 90 x 96-mm boards. 

The 90 x 96-mm board size has certainly become an industry standard module; however, there are multiple variations with connectors located in different parts of the board. It makes a great deal of sense to separate connector issues from the expansion board form factor. That lets you choose a different connector and place it where it’s most appropriate on the board. By sticking to the 90 x 96-mm “PC/104” form factor and mounting holes, you can upgrade a system using the same form factor and sometimes the same enclosure. 

OAR: Upgrade from buses to high-speed serial links? 

Burckle: Yes. The challenge for small form factor suppliers is how to embrace the next generation mobile and ultramobile chipsets coming out from Intel, Via, AMD and others in that space. We’re in a transitional period right now and, to use a Texas colloquialism, we’re beholden to the semi vendors and have to use what they provide. 

OAR: The first PC/104 kicker was PC/104-Plus, which added a PCI bus to the existing ISA bus. SUMIT-ISM replaces the PCI bus in that specification with a selection of high-performance and legacy serial links. Why do you like that approach? 

Burckle: The main reason that SUMIT-ISM was defined and subsequently adopted by the SFF-SIG is that we don’t want to abandon existing customers that have designed or purchased PC/104 modules for years. Somewhere in the range of 50-80% of existing customer stacks include PC/104 (ISA) bus cards. If you’re using the PC/104 bus, you don’t want additional stack height or software changes for existing I/O cards from third party vendors or the customers themselves. To go out and summarily dismiss all that–to say “Sorry, we’re moving on and you’ve got to requalify with all new PCI boards and device drivers, or add a bridge card that increases the stack height by 0.6 inches”—is not cost or time effective and doesn’t make a whole lot of sense to me. 

SUMIT-ISM allows you to preserve the size envelope but doesn’t tie you down to the older I/O expansion. The PC/104 connector and PC/104-Plus connector together take up from 10 to 15% of a board. The SUMIT connector gives us about sixteen times the bandwidth of the PCI connector in about one-quarter of the space. 

OAR: Don’t you also support other approaches, as well? 

Burckle: Yes. Our product offering is evolving. We’re in transition and in two or three years, our product line-up will look different than it does today, but we wanted to make sure that we didn’t leave any of our customers behind. Newer Intel and VIA chips have dropped the ISA bus entirely, so we can use LPC and SPI [on a SUMIT connector] to replace it for low-speed signaling. In that case, we don’t need the PC/104 connector and it can drop off. 

OAR: What’s an embedded computer company’s biggest challenge today? 

Burckle: Managing obsolescence coupled with the rapid movement of technology, and that’s our customers’ biggest problem, too. But if we have good open standards, then when a particular device is no longer available for whatever reason, we can probably expect to replace its functionality with little or no impact on anyone’s wallet. 

OAR: That sounds easier than it probably is. 

Burckle: Yes, but it’s the tightrope all of us in the technology field have to walk. 

OAR: Meanwhile, as we travel into the future, tell me how powerful is legacy when it comes to industrial computing interfaces? 

Burckle: Remarkably. We’re still making Z80 and 8085 STD boards that we made 20 years ago because people still want them. When Hurricane Katrina hit, we had refineries calling and asking for replacements for an STD Bus processor and I/O boards with an NSC800 [National Semiconductor microprocessor], and some of the earliest express deliveries going into Louisiana were these boards to get the refineries back on line.

OAR: You don’t actually have STD boards available off the shelf when people call, do you?! 

Burckle: Many we do, and others we just have bare boards; it’s a function of inventory control and how active the products are. If just a handful are trickling out, we may have pretty much brought them down to zero. With the Katrina example, we had enough boards in finished goods stock. We just needed to add conformal coating. In other instances, if we have the bare PC boards in stock, we try to find enough components to build the boards. 

The revolution is coming with SUMIT and all the new interfaces, but it’s important to support existing customers as long as possible because in a lot of cases, the engineers who designed their products aren’t there any more, and it’s a tremendous burden for a customer to go back in and redesign everything. If it’s possible to manufacture, test and warrant old products, we will, until it’s no longer physically possible.  However, we work with our customers to find a solution. 

In certain instances, we have no choice. If we can’t get the components and the manufacturer stopped making them, then we’re dead in the water. It seems a lot of times it’s the small stuff that bites you: an oscillator or baud rate generator or some PAL for combinatorial logic that we used many years ago that we can’t get anymore.

Click SUMIT to see a white paper on SUMIT.  

Click COMIT to see a white paper on COMIT.

**************************************

Andy Reddig on I/O processing trends

February, 2010
By: dl 

Andy Reddig is the founder, CEO and CTO of TEK Microsystems Inc., a real-time I/O processing specialist serving signal processing applications in defense, intelligence and elsewhere. He recently discussed I/O processing trends with Open Architecture Review, along with interface evolution, the pluses and minuses of FPGAs, fabric protocols and other issues.

OAR: TEK Micro was an early supporter of the RACEway and RACE++ switched fabrics from Mercury Computer Systems within the VMEbus environment. Do you still support that legacy? How strong is that legacy among your customers?

Reddig: Surprisingly, we still get a fair amount of our business from RACEway. Some, as you might expect, is for things that were designed-in ten years ago that people are just making more of. But what’s even more surprising is that we are still getting new design activity with RACEway today. In some cases, it’s very risk averse customers who want to stick with what’s been working for them for years. In others, it’s customers who have a big investment in infrastructure and want to continue to reuse that. Maybe ten to twenty percent of our new designs have something to do with RACEway.

OAR: That’s pretty surprising.

Reddig: One design win we got recently was for a hybrid: a VXS card with a RACEway grafted onto it. The customer is hedging, working with RACEway to sort of look backwards and with VXS to look forwards. The FPGA on our board talks to the [VME] P0 connector for VXS and also to the RACEway connector [on part of VME P2]. Their migration plan is to use RACEway today in an architecture that lets them use the VXS interconnect if they need more bandwidth in the future. And they can make the change by just changing the firmware.

OAR: Can I assume that most previous VME/RACEway customers have now moved to VXS?

Reddig: We are seeing a pretty strong market in VXS from entirely new customers. We actually also deliver a lot of VXS boards to customers who are retrofitting an existing VME system and continue to use just VME, not VXS. They’re not driven by I/O off the card but rather by how much functionality they can put on the card. They’re just replacing an old VME card with a new VME/VXS card with much better performance. Frequently, though, they do want VXS as an option for the future.

OAR: It’s said that VXS is the evolutionary path forward from VME and VPX is the revolutionary path. Now that you’ve announced your intention to start offering VPX boards this year, do you expect VXS to just shrivel up and die as VPX becomes established? 

Reddig. From the customers we talk to, it looks like there will be a long-term market for people continuing to upgrade VME in an evolutionary way, and we don’t plan to suspend activity in VXS for a long time. Nevertheless, VPX has some advantages–such as about twice the speed on the backplane–and as that ecosystem becomes more mature, for new designs that don’t have any legacy concerns, VPX is what people should use. But we’ll be offering both VXS and VPX for quite some time, I think.

OAR: Will your experience with VXS simplify the design and development of VPX boards?

Reddig: Certainly. If you look at one of our 6U VXS cards and imagine our 6U VPX card sitting next to it, there’s not going to be a lot of difference between them. It’s still FPGA based and still using the same modular I/O on the front, all the same software, all the same firmware, all the same system management. We are literally designing our 6U VPX products by taking the artwork for our VXS products and hacking off the [VMEbus] connectors and redoing that part. Our customers don’t want us to change anything on our cards. They pretty much want our 6U architecture except with VPX connectors.

OAR: Why is that?

Reddig: Our customers have the same issues that we do. Their biggest investment is in firmware and software, and if they’ve architected their design to base itself on our firmware and our “funnel” architecture [two FPGAs at the front end and one at the backend], their preference is not to have to change any of that. A large part of our value add is that if you migrate your application to a different card or form factor, everything that can possibly stay the same stays the same. Also, we spend a lot of time and energy on layering so that our firmware hides all the [hardware] details and protects user investment.

OAR: But what about the VMEbus on your VXS boards?

Reddig: Our current Virtex-2 and -5 [Xilinx FPGA] products don’t use VMEbus for anything, although they plug into a VMEbus chassis. We don’t even have a VME interface on those cards. We just use the VME [P1] connector for power and reset.

OAR: What about the P2 connector?

Reddig: We use P2 I/O for a bunch of random little things.

OAR: Such as?

Reddig: For A/D cards, for example, customers frequently need to have a PPS [pulse per second] input or a 10 MHz time input or something like that, so those things get done through a rear transition module on P2, and we hook up P2 to the FPGA.

OAR: So if you don’t have VME, what do you do for a control plane?

Reddig: We never really saw a lot of value to VME as the control plane, and the [interface] chip costs a lot of money and takes up a lot of space. But of course, we’re driven by customers, and if they say they want a VME control plane, we’ll give them a VME control plane.

What people tend to use to control our cards is Gigabit Ethernet. Our firmware and software make it really easy for an SBC to talk to the FPGAs on our cards over Gig E, which abstracts you completely from the bus.

Fairly early on in the old RACEway days, we had a PMC carrier with both VME and RACEway interfaces; actually, we still sell a fair number of them. What we found was that 95% of the customers just talked over RACEway, and VME was irrelevant. Ironically, though, some customers have now requested that we put a VME interface back in, so our next VXS card will have VME on it.

OAR: What do you think about that?

Reddig: There are customers migrating their applications who said they want to continue doing control operations through VME, so we have to accommodate them. Instead of putting a VME interface chip on, though, what we’re doing is putting a soft VME core in a small FPGA in the next card, so we can talk VME to people who want to talk VME, but we don’t make a big investment on the card in terms of power or space.

OAR: With the OpenVPX/VITA 65 activity, there are apparently now a select number of legal “profiles.” Do you have to decide which SBC companies’ profiles you want to interoperate with?

Reddig: That remains to be seen, but being FPGA based gives us an advantage in that we can be protocol agnostic and support multiple protocols just by changing firmware.

OAR: In terms of the high speed point-to-point (P2P) links on the VXS P0 connector, which protocol or protocols does Tek Micro support, and do you expect that to change?

Reddig: In our applications, it’s very common to use the P0 connector to do FPGA to FPGA links using Aurora [protocol from Xilinx], but customers have asked us about just about every protocol. We support Aurora, serial FPDP and Gigabit E.

OAR: Is there any appeal to PCI Express?

Reddig: We have done work with PCI Express, but there aren’t yet any PCI Express enabled VXS SBCs, so there isn’t anything to talk to over it yet. So far, that ecosystem hasn’t developed, though I expect it will. But if you’re talking from FPGA to FPGA, it’s much lower overhead to use Aurora as a high-speed spigot, and PCI Express doesn’t actually add a lot of value.

OAR: What about RapidIO?

Reddig: We’ve had customers ask us about Serial RapidIO, and we’ve confirmed that they can integrate a RapidIO core onto our card. But we’ve never had a customer ask us for it, and we don’t have any direct experience with it.

I think there’s a chance 10 Gbit Ethernet will supplant RapidIO, but I’m not sure how soon that will happen. It’ll happen a lot faster as soon as Xilinx puts a 10 Gbit E core on an FPGA, and I mean a hard core because a soft core uses up a lot of gates. I think RapidIO has a place these days, but it hasn’t been driven nearly as strongly as PCI Express, 10 Gig E, 40 Gig E and those sorts of things. So while it has a niche, it will be a declining niche over time.

OAR: What’s missing?

Reddig: The way people in defense electronics really get bang for the buck these days is by figuring out clever ways to leverage existing technologies whose performance and cost are being driven by other market forces. There is now a second-gen RapidIO spec, but how many people are making chips with it? How many processors? How many switches? It’s a huge investment to get a semiconductor manufacturer to make chips with the technology in them, and until you actually have processors and switches that make use of that [second-gen speedup], board vendors can’t take advantage it. How soon will they get there? Three years from now? By that time, 10 Gig E or 40 Gig E or whatever will be out there and faster.

OAR: Unlike VXS, VPX allows both 3U and 6U form factors. Do you have any plans for a 3U line of products?

Reddig: Yes, and 3U presents some interesting tradeoffs because it’s less space efficient than 6U in terms of the physical overhead of connectors, card guides, front panels and so forth. That makes it especially important to pick the right feature set, and there are some tradeoffs we’re working through. What’s the tradeoff between having one large vs two smaller FPGAs? How do you tradeoff FPGA density vs memory? Some applications need very deep memory buffers, some don’t need memory at all, and that makes it tough for board designers to come up with something that meets everybody’s needs.

OAR: How do you see mezzanine boards evolving over time? Will hybrid XMC boards, with both PMC and XMC connectors on them, be a short- or long-term phenomenon?

Reddig: In the early days of VITA 42, which defined the XMC mezzanine standard, I predicted that very few people would make a hybrid module, and now I find myself making one! The reason is that we had a set of functional requirements and found we could meet them by making one hybrid product rather than making two products, one with PMC and one with XMC, so we did it. But going forward, I think our products will be XMC only because SBCs will migrate away from hybrids, and PCI [for PMC] will become more and more problematic to implement for board vendors. 

OAR: What’s the primary appeal of FPGAs in the markets you serve?

Reddig: If you’re size and power constrained, they give you bang for the buck that you couldn’t get with general-purpose processors. The flip side of that is that for a lot of application that are not so constrained, things move from things like VME, VXS and VPX to servers and blades, 1U things, because the cost effectiveness is ten times as good as anything you’re going to get in a traditional kind of rack-mounted configuration. But if you really need absolutely maximum performance within a given volume or power or both, FPGAs offer between a 5x and 10x performance capability than general-purpose process if you’re willing to take the time and effort to deal with the firmware and code up an FPGA.

OAR: Are there any tradeoffs to FPGAs?

Reddig: The axiomatic thing is that they’re much harder to program then general-purpose processors. There’s a dream of being able to take your C code and punch it through some kind of VHDL C compileresque type of thing, or being able to put your application into some graphical form and crunch it to come up with something about as efficient as a human being writing firmware. But we’re an order of magnitude away from that. You can take general-purpose C code, turn it into FPGA code and run it on an FPGA, but you wind up with an FPGA that’s about ten times faster running on code that’s about ten times slower, so the result is just about the same as having a general-purpose processor, only it’s a lot more expensive.

OAR: In what kinds of applications are FPGAs the most suitable approach?

Reddig: We see two classes of problems in embedded. One class is more or less fixed and, over time, what was a 20-slot chassis becomes a 10-slot chassis, which then becomes a five-slot chassis and so on, so the problem gets easier and easier to solve. The other class of problem is infinite, but there’s a certain size or power constraint, and you want to do more and more over time within the constraints—have more resolution or more signal bins, listen to more simultaneous channels or whatever. Here’s where FPGAs fit. If they can give you, say, 10x the performance in a particular size box, that’s worth almost any price to the customer. There’s a fair amount of pain and anguish involved in getting them programmed, but they solve problems that would not otherwise be solvable within the size or power constraints.

OAR: How do the FPGAs shape up powerwise?

Reddig: That’s a very interesting issue. Customers always ask how much power a board uses and with, for example, a PowerPC, that might be 62W if not much was going on and, say, 68W if the processor was very busy. But with FPGAs, it’s not so straightforward. If you fully load up an FPGA, it might max out at 40 to 50W, but for a different application, it might use only 20W.

OAR: What are the implications of that?

Reddig: It’s brought a very interesting change to systems engineering over the past three to five years. It’s no longer sufficient to just ask your vendors how much power a board uses and then figure out the chassis that’s going to cool it. You now have to think very hard about modeling how much power your application is going to use.

We’ve hit the point, particularly with the new Virtex-6, where we have the ability to put on the order of 300W of FPGA power burning capability on a 6U card, and if you fill up all the FPGA gates and work them very hard, there’s no way you’re going to cool that, at least not in an air-cooled environment. You have to spray cool it or liquid cool it. We have customers doing these kinds of things, but it’s a totally different world.

Five years ago, the challenge was fitting all the chips on the board, and the constraint was physical. Today, we can fit more chips on a board that you can easily cool, and power and thermal management is the constraint. Chassis design used to be a much simpler problem, but today, it’s become critical to work closely with customers to understand the implications of using FPGAs.

**************************************

Rodger Hosking on signal processing

Jan. 4, 2010
By: dl

Rodger Hosking, a cofounder and vice president of Pentek, has seen many generations of signal processing come and go. He discussed a variety of current topics of interest with Open Architecture Review, including the emergence of point-to-point serial links, the roles of VXS and VPX, mezzanine trends, the FPGA phenomenon and the uncertain future of general-purpose DSPs in military and government electronics.

OAR: The system interconnect of the past was primarily the parallel bus, and now it’s the point-to-point (P2P) serial link. How has this changed signal processing?

Hosking: It has pretty much revolutionized our architectures. About three years ago, we migrated our VME designs towards VITA 41 VXS, which augments parallel VME with Gbit serial interfaces on the same board. That’s very effective for solving some problems where VME used to be a bottleneck.

OAR: And VXS lets you continue to use legacy VMEbus boards, right?

Hosking: Yes, and there are going to be an awful lot of designs going forward that will still use VME and legacy boards over the next ten to fifteen years. And when the VME backplane is not sufficient to handle the bandwidth you need, you can use VXS to give you rates that are twenty times higher than what VME can do.

OAR: Doesn’t having to handle all that traffic introduce some complications?

Hosking: Sure. As I said, we’ve pretty much revolutionized our architectures because of it. We’ve moved from communicating over a shared resource, a bus, to communicating via direct pathways with no contention. The architecture is fundamentally different.

OAR: Can you point to one relevant difference in board architecture?

Hosking: To support the change for one particular processor board, we incorporated a Gbit serial crossbar switch to serve as traffic cop for on-board resources, connecting a PowerPC processor, XMC mezzanines, FPGA resources and backplane. That’s a major change for us.

OAR: How is the market trending in mezzanine boards? Where is there movement to XMC and serial P2P links? Where are people staying with PMC and its legacy parallel PCI bus?

Hosking: PMCs are being replaced by XMCs to add the Gbit serial links. We originally made PMC modules, then shifted to hybrid XMC modules with both PMC and XMC connectors on them, and our latest introduction has XMC connectors only. You can see the progression from parallel, to parallel plus serial, to straight serial.

OAR: Pentek chose PCI Express as its P2P link. Why PCI Express?

Hosking: PCI Express is really nice because you can reuse a lot of the software you’ve previously developed for PCI and PCI-X under Windows or Linux and not have to do very much to it to support the shift from parallel buses to serial P2P links. A lot of the software remains the same.

OAR: Do you support PCI Express exclusively?

Hosking: At this point we’re promoting PCI Express as the standard control and data plane fabric, but we’re also supporting and delivering the [Xilinx] Aurora protocol. We just announced a family of beam forming products for software radio, communications and radar. They use PCI Express for controlling and loading data on and off the modules, but they also use Aurora protocol as a high-speed interconnect between boards in kind of a daisy chain.

OAR: Doesn’t PCI Express provide that capability?

Hosking: Aurora is a very low-level, lightweight protocol with very low overhead, whereas PCI Express has many layers of protocols and conventions you have to follow in order to be a true PCI Express entity. Something like Aurora is the best way to handle the high speed summation across multiple channels, which is the critical operation in beam forming.

OAR: Do you run Aurora over the VXS backplane?

Hosking: No, over cables, like people always did (and some people continue to do) with the old FPDP [Front Panel Data Port]. We can daisy chain boards down a card cage as many slots as required, pretty much without limit, by simply attaching cables for the Gbit serial connection. At the end, you pull out the final sum and send it out across the PCI Express interface; but from the beginning to the end of the daisy chain, you don’t have to rely on the motherboard or carrier at all. It really simplifies a lot of the beam forming operations people need to do.

OAR: You’re supporting Aurora on a PCI Express board. If you did the same on a VXS or VPX board, would you continue to use cable for the traffic?

Hosking: That depends on what it’s attached to. The cables that we provide for the PC environment are definitely not what people are looking for in a military VPX chassis. There, Aurora links would probably be done through backplane connectors, and the boards could either be joined by a switch board or by a custom backplane that’s hardwired between slots to provide the daisy chaining capability.

OAR: Regarding VXS, I see very little activity in support of it these days, and most VXS suppliers seem to be plunging into VPX as rapidly as possible. Is there a shift going on here? Was VXS just a short-term, transitional standard?

Hosking: VXS was definitely a transitional move. It represents a shift from parallel only to parallel plus serial. The next shift is to serial only: that is, to VPX. The same shift is going on in mezzanines: first from PMCs to XMCs with both PMC and XMC connectors, and then to XMC-only boards.

OAR: So what are your VPX intentions?

Hosking: We will be announcing a VPX product line in Q1 2010, primarily for 3U and eventually for 6U VPX.

OAR: Pentek didn’t have a small form-factor 3U line for VXS.

Hosking: There’s no room for a P0-type connector on a 3U board. But VPX made provisions ahead of time for both 3U and 6U, and things are extremely well laid out and defined. The 3U VPX specification is more mature and more uniform across suppliers than 6U.

OAR: Has the stampede to VPX we’ve been seeing been influenced by the OpenVPX collaboration?

Hosking. Very much so. The OpenVPX initiative, the migration to VITA 65 in October, 2009, and its eventual adoption by ANSI will do a lot towards unifying the market.

OAR: When do you expect ANSI adoption?

Hosking: The first quarter of 2010 or so.

OAR: What motivated OpenVPX was the real-world interchangeability difficulties users have been having with VPX boards. Does the new specification solve the problem?

Hosking: There are still quite a few government agencies and organizations that are concerned that VPX is not yet stable enough. They want to know that the VPX system they buy today will accept future boards from different vendors, and that everything will work together. I expect their fears will fade over the next year or so.

OAR: What has been causing the incompatibilities?

Hosking: It’s just based on the individual choices that designers made when they put together the first VPX boards and systems.

OAR: Examples?

Hosking: Clock distribution and management, chassis configuration and control, naming the various Gbit lane bonding conventions, and defining slot profiles for different types of VPX cards. Many of these issues were addressed in the OpenVPX effort.

OAR: Did the same type of problem arise with VXS?

Hosking: Because VXS is simpler with only two 4X VXS ports on any card, there were fewer design choices. Even so, there are several flavors of both switched and switchless VXS backplanes. With VPX, though, each card can have 20 or more different ports ranging from 1x to 16X, all needing to go to specific destinations. VPX has the capability for doing a lot of very, very high-performance embedded computing, but that freedom comes with a penalty in how all those interconnects are actually implemented.

OAR: So what does the near term look like for VPX?

Hosking: We see a lot of vendors lining up with available products. One complication is that VPX will require a diverse range of backplanes, which is quite different from VME. There will probably be four or five popular backplane configurations, but major programs will probably require custom backplanes with specific interconnections. That wasn’t the case for VME.

OAR: Will VXS just wither away and eventually die?

Hosking: Someday, but VME will definitely help prolong VXS. For us, VXS was a very positive thing and an important stepping stone. It really helped enormously to get VPX started because it got us building hardware and software to support interboard Gbit serial links. Once we developed software for VXS boards, we were immediately able to take advantage of the interfaces and drivers for VPX, as well.

OAR: Have the P2P serial links in any sense been a leveler in terms of performance differences between motherboards and backplanes?

Hosking: You can do a tremendous amount of processing and achieve a very high interconnect bandwidth in the lower cost motherboard environment, but bandwidth isn’t everything. The trouble is that PCs are not very good in unfriendly environments. Also, as you get into higher density products, thermal management and adequate air flow become a problem because the PC is not a very good environment for cooling. VME or VPX or CompactPCI are much better at handling the heat than a PC.

OAR: Any other caveats?

Hosking: Yes. The PCI Express slot connectors that are found on motherboards often don’t have enough amperage on the pins to power up the devices that are being plugged into them. So, for the PMC carriers we’ve done for PCI Express, we’ve had to implement separate power connectors that go directly to the power supply.

OAR: In the past, I’ve seen FPGAs here and there on various board-level products, but these days they’re being widely used, especially in DSP environments. Why and why now?

Hosking: FPGAs have a traditional role of providing multiple hardware engines that perform a lot of DSP operations in parallel. What has happened more recently is that Xilinx and Altera incorporated Gbit serial engines as dedicated blocks right inside their FPGAs, making it easy for people to incorporate those serial interfaces.

Also, the high-speed devices we are typically involved with — high-speed A/Ds, D/As, network interfaces, serial FPDP, etc. — are all supported beautifully with the configurable I/O that FPGAs provide. So, you can comply with a lot of different logic levels and signaling rates up in the hundreds of MHz, and tune the I/O to match the characteristics of the peripherals you’re trying to connect to.

OAR: That’s a pretty powerful story.

Hosking: It gets better. You can now also get memory controllers, either from the FPGA vendors themselves or third parties that install inside the FPGA to allow you to interface to virtually any kind of external memory available. And the icing on the cake is that the devices have become faster and denser with each new generation. The latest version of Virtex-6 from Xilinx has over 2000 DSP engines on board, each capable of performing multiply/accumulate/addition operations in parallel — that’s tough competition for a general-purpose DSP!

OAR: So will general-purpose DSPs wither away and die?

Hosking: They’ve definitely waned in popularity in our markets. That’s because over the past ten years, the leader, Texas Instruments, has focused on the telecom market. As a result, the DSP chips are mostly fixed-point devices and they tend to have dedicated telecom peripheral interfaces on board. Our markets in military/government electronics like to use floating point because it’s easier to have an algorithm work properly without having to worry about scaling and dynamic range.

OAR: So Pentek doesn’t see any general-purpose DSPs in its future?

Hosking: That depends. If, for example, the telecom market appears to be getting saturated and TI gets competition for its DSPs from overseas knockoffs, they might start seeing our embedded markets as an opportunity and perhaps extend their offerings. We’d look closely at anything they might do in getting back to floating-point DSPs. We’d definitely not just give up FPGAs because they do so many different things, but we’d look at a good credible, competitive DSP.

OAR: Competitive in what sense?

Hosking: There are two things a DSP could compete on: power consumption and cost. FPGAs are expensive and they draw a lot of power. If TI could come in and handle the algorithm number crunching we’re using FPGAs for, but at a lower cost and lower power, that might be interesting.

OAR: Do you see any other trends in signal processing?

Hosking: We definitely see more and more people using Windows and Linux, as opposed to the more traditional real-time embedded operating systems like VxWorks. Customers don’t like the run-time licensing and the development tool costs. VxWorks is an excellent product, but we’re seeing that when people can get away from it, they often do.

**************************************

Greg Tiedemann on RapidIO

By: dl
Dec. 7, 2009
Greg Tiedemann, Mercury Computer Systems

Greg Tiedemann, a product line director at Mercury Computer Systems, has been heavily involved with RapidIO since 2001. In this interview, he brings Open Architecture Review up to date on the standard, considers its place in the evolution of system interfaces and describes RapidIO’s relationship with various processor architectures.

OAR: Greg, the last time I took a serious look at RapidIO, the parallel version was happening, and the serial version was expected soon; StarFabric was a viable contender; HyperTransport made noises like a possible competitor; InfiniBand looked to have a future, at least box to box; Ethernet was going to take over everything; and the PCI Express interests were all rallying around Advanced Switching. Bring me up to date.

Tiedemann: Well, the dust has settled and Serial RapidIO is the fabric of choice for embedded fabric applications, the technology all the [telecommunications] systems companies and defense contractors went with. Compared to Parallel RapidIO, Serial RapidIO has a better power signature, delivers a lot more bandwidth and takes up less silicon, so the silicon manufacturers found it more efficient and easier to work with. 

OAR: So is parallel RapidIO dead?

Tiedemann: Pretty much. We have a legacy system we’re still shipping to one customer.

OAR: And the other fabric contenders?

Tiedemann: Advanced Switching was shut down; I’m not aware of any real market share for StarFabric; we don’t see any HyperTransport in our markets; InfiniBand is widely deployed in the IT computing infrastructure, blade to blade and box to box, mostly in the high-end server space; and PCI Express has emerged as a complementary interface to RapidIO, as well as a master–slave fabric in some of the embedded computing systems.

OAR: That’s ironic, given the historical Battle of the Fabrics.

Tiedemann: Yes, in the early days of the fabric wars, the PCI Express community was trying to take over the backplane and displace RapidIO. They looked at it as an all-or-nothing competition and wanted to dominate all of the interfaces—-board, backplane and intersystem. It really was a waste of energy because PCI Express is a very effective chip-to-chip technology that has evolved into a very effective switch fabric for some smaller-scale applications.

OAR: So you’re using both RapidIO and PCI Express?

Tiedemann: Yes. They’re complementary technologies. PCI Express is a good point-to-point solution, so we use it a great deal on the board and between adjacent boards; but whenever we need to move a great deal of data across a number of boards, we generally like to use RapidIO. It’s more scalable and easier to deploy.

OAR: Does PCI Express ever make sense board to board in the applications you serve?

Tiedemann: Yes, we are using it in our co-processing plane. Where there is a compute node in slot 2 and a co-processor, like an FPGA or GPU in slot 3, we use PCI Express to extend the computing to adjacent slots. We are also using it when you have an Intel host in a master-slave arrangement, but when you start to scale up to multiple computer nodes, that’s where RapidIO excels.

The DSP guys like PCI Express because it’s very efficient and doesn’t take up a lot of gates within their processors. It’s designed for packet switching, which the signal processing guys, especially in the base station market, really like. And it’s an easy programming interface. All those things make RapidIO an ideal solution in larger systems and PCI Express an ideal solution in other areas.

OAR: So the two interfaces coexist in a hierarchical arrangement with a division of labor. Don’t you also support Ethernet?

Tiedemann: Yes, exactly, a division of labor. You could also look at it as a “multi-plane” architecture. And by the way, the Ethernet guys also thought they were going to take over everything in the box, but what really evolved is coexistence.

All our systems will generally support Gigabit Ethernet as the control plane interface; above that is the data plane interface, generally RapidIO, which provides a very deterministic data plane that doesn’t interfere with the control plane traffic; and then we have the concept of a co-processing or expansion plane interface, which is usually PCI Express. And they all scale nicely together. 

OAR: What do you mean by coprocessing plane?

Tiedemann: There are architectures where you would like to couple compute resources together between boards. That’s the coprocessing plane, where a PCI Express chip-to-chip interface may extend between boards, say, from a PowerPC on one board to an FPGA on an adjacent board. In this scenario, PCI Express can provide a very low-latency, deterministic interface.

OAR: So what does RapidIO have that PCI Express doesn’t? 

Tiedemann: I don’t think of it anymore as a one or the other sort of comparison. RapidIO was designed from the ground up to scale to hundreds of nodes. PCI Express has evolved as a very effective chip-to-chip interconnect with a tremendous amount of bandwidth. They have evolved from different places and are good at specific things. There are some cases where there is an overlap in functionality and you could use one or the other. You have to look at it on a case-by-case basis.

OAR: Why not use RapidIO chip-to-chip, too? Wouldn’t that simplify things?

Tiedemann: Good question. We will use RapidIO between processors on a board and then extend that interface board to board through switches and in meshes. And where it’s appropriate, we would use PCI Express. You try to use the right solution for the right application, rather than force-fit an interface.

OAR: I assume RapidIO has upped the performance ante over time. If I remember right, RapidIO 1 ran at roughly 1, 2 and 3 Gbits/sec, and x1 (single-lane) and x4 (quad-lane) links were defined.

Tiedemann: Yes. RapidIO 2 brought that up to 5 and 6.25 Gbaud, and it has added x2, x8 and x16 links. The RapidIO Trade Association is now working on Serial RapidIO 3. [Click here to take a look at the RapidIO Trade Association’s roadmap.]

OAR: To what do you attribute the success of RapidIO?

Tiedemann: This is an interesting area to discuss. There were several events for RapidIO that made it successful. The first, I believe, was establishing an open standards group and soliciting the end customers [Ericsson, Nortel, EMC, Lucent and others] to drive the requirements. The second was having a variety of silicon suppliers actively involved to work collaboratively with the end customer to debate what was feasible, both technically and from a business perspective.

Then, it turned into a race to get the silicon to market. Freescale initially only put Parallel RapidIO into one version of its PowerQUICC, then moved everything over to Serial RapidIO once it became available. Then TI and Freescale adopted it for their DSPs; Xilinx and Altera had RapidIO end points available in their FPGAs; and Tundra and IDT put it in their switches.

In the end, getting the right silicon into solutions that the end customers could deploy and demonstrating a high level of interoperability — that’s what really drove the adoption and success of RapidIO. And for that matter, it’s a common model for any open technology standard to be successful. That’s where some of the other technologies we were talking about failed.

OAR: A few weeks ago, you introduced an AMC that couples an Intel processor with RapidIO, which I think is the first time someone’s done that. With its native PCI Express interface, why would you want to use Intel in a RapidIO environment instead a processor with a native RapidIO interface?

Tiedemann: From a technology perspective, Intel processors are attractive to us for a number of different reasons, they have a level of performance we’d like to leverage for various signal processing applications and Intel software support is tremendous. However, as we discussed, the native PCI Express from an Intel chip can’t really scale up in a system architecture. We could use 10 Gigabit Ethernet, but that’s not going to support some of our embedded performance requirements. So in order to provide a more deterministic fabric, we bridged the [processors’ native] PCI Express interface to RapidIO. That will let us use Intel in some higher-end multicomputer applications. 

OAR: You do the bridging in an FPGA?

Tiedemann: Yes.

OAR: So you’re putting x86 processors up against TI DSPs and Freescale PowerPCs?

Tiedemann: Not really TI DSPs; it’s more applicable to PPCs. The DSPs are very low power, very efficient processors, designed for very specific application areas, not general-purpose processing, while Intel chips are heavier-weight, general-purpose processors that could be used in a number of applications. Their power is certainly higher and the footprint of the chip is certainly much bigger, but there are some signal processing applications that can afford the power where the customer wants the flexibility of working with an x86 architecture versus a fixed-point DSP programming model.

The AltiVec engine of the PowerPC products, in turn, really set the bar for multicomputing performance, and we’ve leveraged it for a lot of applications. But if the customer doesn’t want to do that special coding [to take advantage of AltiVec], the x86 might be more suitable.

Intel can scale up to some signal processing applications that we have traditionally used PowerPCs or FPGAs for, but those are mostly single-processor applications. It makes the most sense when you have an Intel host in a master-slave arrangement.

OAR: Can I assume that the Intel approach is less expensive?

Tiedemann: That may be the perception, but there are some challenges to consider when deploying Intel. The chips are designed for commercial applications, so you have to invest in technologies to cool them properly, and then spend some time to make them rugged enough from some of the defense applications. These are just a couple of examples of perception versus reality. In the end, the embedded computing companies have to show a cost-per-performance improvement to stay competitive. So we will always be looking for areas to add value.

OAR: What do you see coming for RapidIO in the future?

Tiedemann: More of the same. It’s widely deployed throughout the defense and commercial markets, and it will continue to grow in market share. We also talked about the improvement in performance with RapidIO that we are tracking and will support. RapidIO clearly has become the fabric of choice for all our high-performance multicomputers.

For an entirely different view (Ray Alderman’s) on PCI Express, click here to read Why PCI Express stinks (for multiprocessing).

**************************************

Doug Patterson on COTS in space

By: dl
November 23, 2009
Doug Patterson, Aitech Defense Systems

Doug Patterson, vice president of worldwide sales and marketing at Aitech Defense Systems Inc., has been deeply involved in the mil/aero side of embedded computing for over two decades. He discussed the emergence of the COTS-in-space phenomenon with Open Architecture Review in a recent interview, along with other issues including the perversion of the COTS concept.

OAR: So what’s all this I hear about COTS-in-space?

Patterson:  There’s been a big change in the last year or so. In the past, the electronics for NASA vehicles, whether manned or unmanned, have always been designed and built from the ground up in what’s traditionally been a program-specific, project-specific, extremely expensive build. 

But as you can see from some of our program awards, like the Ares crew launch escape vehicle, that’s starting to change. The movement towards COTS-in-space–and by COTS I mean commercially-available, off-the-shelf technology–is starting to gain some traction. These products are true COTS, qualified and certifiable for manned or unmanned missions, depending on what version you choose and what pedigree of paper comes with it. 

OAR: Why is this happening now? 

Patterson: For many reasons, including economics. It’s a whole lot cheaper if you don’t have to reinvent the wheel over and over again for every new system. If you have a processor and some I/O cards that act, for example, as the mission controller and RIU [Remote Interface Unit] of a satellite for DARPA, the same processor and almost the same I/O cards can be used for a NASA crew vehicle, and that’s what happening. 

OAR: The economic advantage of an open architecture design is certainly not a new phenomenon. Why wasn’t NASA utilizing COTS gear two years ago or three years ago? What’s taken so long? 

Patterson: There weren’t these types of open architecture products available previously. Functionality, ruggedization and testing have continued to increase, making it possible for these products to operate reliability in radiation tolerant and rad-hard space-based systems. Over the past three to four years, Aitech has forged a whole new field of electronics for space applications. 

OAR: Didn’t you form a space division a year or so ago? 

Patterson: Our space group has been around since 2005, but about a year ago, it moved into its own building with its own stock control, manufacturing and test clean rooms, quality processes, etc. This expansion was due in part to the growing use of our COTS products in space environments. 

OAR: I assume the requirements on space electronics are even more rigorous than they are for military/aerospace equipment? 

Patterson: Yes, absolutely.  There are a number of additional issues to deal with. The main issues with space electronics are radiation, single-event upsets, ionization and linear energy transfer. You have to incorporate power output circumvention in the power supplies and support on-board circuitry to ensure component latchup doesn’t occur, and if it does, that at least the electronics are protected from excessive current overloads that cause them to burn themselves out. 

Those requirements also exist in defense applications where tactical nuclear environments are seen such as MLRS [Multiple Launch Rocket System], the Patriot Missile System, etc. We like to use SOI [silicon on insulator] and SOS [silicon on sapphire] technologies because we find they’re much more resistant to radiation effects than CMOS. 

OAR: What about thermal issues? 

Patterson: Space is a very different environment than your usual defense and aerospace applications. The thermal effects for a device in a space vacuum are very different from those on the ground. Air provides natural convection, and when you take all that air away, leaving only conduction and radiation cooling, electronic components and subsystems react and cool completely differently. 

OAR: Are component screening requirements more rigorous for space apps? 

Patterson: Yes. We test, characterize and screen every component for our Series 500 space products 100%. We take the devices to the linear particle accelerator ourselves with NASA and test and characterize them with complete traceability before being released to production. 

OAR: How do the requirements of space applications affect board design? 

Patterson: They affect everything from basic functionality through component placement right on up to thermal management. For example, we have to build in multiple levels of redundancy—-triple redundancy in the case of memory devices—-and that necessarily reduces the amount of functionality on a board. Parity and ECC algorithms are also implemented in hardware to ensure the bits fetched from memory are exactly what was stored there previously. And those triple redundant memory devices can’t be stacked due to the susceptibility of a single ion particle upsetting the entire memory stack, creating a bad bit or bits. 

To reduce the bit error/upset rates of these memory devices, they must be spread out across the board because you don’t want to risk one ion taking out an entire memory stack. If a bit gets flipped, you want to catch and correct it so the processor can just keep chugging along without the event halting or overtly altering the timing of its mission profile and operation.

OAR: Earlier you talked about “commercially available, off-the-shelf” technology. Is that CAOTS? Are you drawing a distinction with plain old COTS, “commercial off the shelf?”

Patterson: It’s COTS, but there is a distinction. COTS has developed a bad name in the defense and military because some have tried to pass off commercial-only technology as military COTS–you know, 0 to 55°C products that people are buying off the shelf, putting a heat sink on, throwing into a box and saying, “Hey, now it’s good for the military.” Well, real-world programs have proven that it’s not. 

You can’t just take products built for commercial applications, throw them into a military environment and say “It’s COTS.” The classic definition of COTS refers to defense/aerospace technology that’s designed, built and tested for that environment, then stocked and available off the shelf, not commercial technology in some sort of a ruggedized enclosure. 

OAR: Could you regale us with any tales of woe concerning commercial boxes in military environments? 

Patterson: Sure. Remember the early failures of the Patriot Missile System’s mission computers in Saudi Arabia during Desert Shield/Storm? The mission computer electronics are cooled via filtered, direct impinged, blown air which is perfectly fine for North American and European theaters. During the course of a day in the Sahara, the desert sand– which, by the way, no one realized has the consistency of baby powder–sifted right through the normal air filters and filled the computer cabinets with insulating sand.  Once the cabinets filled, the cooling air could not reach and cool the mission electronics, and the systems consistently overheated. 

 OAR: So what did they do? 

Patterson: The program manager told me that what saved the program was a soldier out on the line who made an auxiliary air filter out of a pair of his wife’s panty hose sprayed with Endust. When the baby-powder like sand clogged the nylons, the mission tech ripped off the panty hose, put on another, coated the new aux filter with Endust, and the mission computers would not fill with sand and worked just fine from that point onwards. 

Bottom line, if you don’t do your homework, if you don’t know or can’t accurately predict the actual environment these systems and platforms are going into, and you’ve chosen electronics that won’t meet the grade, you’ve selected the wrong COTS. 

OAR: Any more- recent examples? 

Patterson: Sure. For a while, the military was putting mobile BTOC [Battalion Tactical Operations Center] networks in place by using commercial-grade routers and servers re-packaged into huge transport cases and isolated from excess vibration via wire-rope anti-vibe isolators. One of the battalion commanders told me that they worked great until the little fans in the routers and network servers sucked up all that baby powder sand and…can you guess what happened? The electronics quit and the networks died. 

So in the end, let the buyer beware. It’s a great idea to use commercial technology where it’s applicable, but if it’s not built and tested for military applications, and you throw it in the back of an HMMWV [High Mobility Multi-Wheeled Vehicle, aka Humvee] and, surprise, it fails, you bought the wrong COTS. There are a lot of war stories like that. The point is you have to do your homework and pick the right solution set for the particular application. 

OAR: And always have a pair of panty hose with you, just in case? 

Patterson: I’m not sure the panty hose and Endust approach would work in space. But, next time I get a tech support call from a low earth orbit satellite, I’ll let you know.

**************************************

Mark Littlefield on OpenVPX

By: dl
Oct. 19, 2009
Mark Littlefield, Curtiss-Wright Controls Embedded Computing

Mark Littlefield, a product marketing manager at Curtiss-Wright Controls Embedded Computing, has been intimately involved with the OpenVPX effort and serves as the chairman of VITA 65, which this month inherited the draft specification developed by the OpenVPX Working Group.

Littlefield discussed some of the issues with OAR  the week before the turnover was scheduled to occur.

OAR: What does OpenVPX offer beyond VPX?

Littlefield: VPX was designed to be very broad in order to solve a lot of different problems for the industry, but there are a lot of different ways to approach different problems, and some of the results were not interoperable. OpenVPX offers a set of fixed system-level VPX implementations or “profiles” with a reasonably good expectation of interoperability.

OAR: How is that interoperability achieved?

Littlefield: We achieved that mainly by focusing on different communications planes: the data plane, where the high-speed data movement takes place; the control plane, typically using Ethernet; the expansion plane; and the utility plane, which nails down power and utility signals. VPX has some variability in that [utility] space, so we constrained it a little bit based on industry-best practices.

OAR: What do you mean by expansion plane?

Littlefield: We wanted to have a high-speed communications plane separate from the data plane where we could, say, connect up a carrier board.

OAR: Like what we used to call a “backdoor bus?” An auxiliary data path?

Littlefield: Yes. The data plane is really intended to form a large-scale communications fabric that connects all payload boards in the system. The expansion plane is intended to be a secondary communications link, normally connecting neighboring slots. The general idea is that you might have a payload card like an SBC that could have a mezzanine carrier in a neighboring slot which it talks to through this alternate data path.

OAR: Why is the OpenVPX spec becoming VITA 65 and not VITA 46-dot-something?

Littlefield: Some of the work we’ve done doesn’t address just VITA 46 VPX. At the very least, some of VITA 48 [REDI] would be captured by this, and there’s some desire to capture some alternate connectors, such as the Viper connector, which is pin and signal compatible but not physically compatible with the VPX connector [the Multigig RT connector of Tyco Electronics].

OAR: I’ve heard of a few other alternative connectors being discussed in the VITA 60 group. What’s the motivation here?

Littlefield: Viper is being designed to be somewhat more rugged than the Tyco connector and provide a little extra margin, but we’ve built a lot of product with the Multigig RT and we’re very satisfied with it. That connector underwent more testing by far than any other connector ever in the embedded industry and it exceeded all goals. (www.vita.com/VITA46ContechTestReportrev1.4.pdf) The integrity and ruggedness of the Tyco connector are not in question.

OAR: OpenVPX has been described as a top-down framework that’s “more than just pinouts and protocols.” Can you explain what that means?

Littlefield: You can see it in the organization of the [OpenVPX Working Group] document itself, which reflects that orientation. We start at a high level, thinking about the application space and suitable characteristics for different kinds of systems. We have slot profiles which define pipes [with different numbers of differential pairs], module profiles which overlay protocols onto those pipes, and backplane profiles which tie slots together into architectures. These can scale, and we have standard development chasses defined for the backplane profiles.

OAR: As an ad hoc working group, will the OpenVPX Working Group dissolve now that it’s turning over the results of its labors to VITA?

Littlefield: Our charter goes through April 1, but we’ll probably only stay alive for a few weeks after we deliver our release to VITA. That’s just in case any last-minute gotchas come up, but there’s so much overlap between OpenVPX and VITA anyway that we can probably address them at the VITA 65 level.