Bridgework: Q&A with Mercury Computer Systems on how connectivity to (just about any) fabric on the backplane aids high throughput, low latency, and extreme determinism

Marc Couture, director of applications engineering for advanced computer solutions, Anne Mascarin, product marketing manager, and Arnold Sodder, consulting systems architect, all of Mercury, spoke with DSP-FPGA.com.

Marc: Open Core Protocol, which specifies standard interfaces for IP cores, comes out of the ASIC industry. In May, Xilinx partnered with ARM to develop a next-generation interface standard called AXI 4. One thing to note here is that Xilinx is going to be taking its Core Gen library all public. Because POET will support AXI, for instance, customers can take the Core Gen IP loads, and if they are sticking to the same interface, they can plug in things more easily, so it is a productivity play. It will save them a lot of time.

DSP-FPGA.com: So designers can move more quickly to doing what they do to differentiate themselves from the competition?

Marc: Rather than messing around with the plumbing. Everybody uses half-inch pipe, for example. But in the FPGA world, interface standards have long been lacking, so this is a big step forward.

DSP-FPGA.com: Do you have additional comments on Figure 1?

Marc: Another big consideration, particularly in defense platforms, is being able to insert security-oriented IP. POET is typically the main fabric hub into the card, so this is an ideal spot to place a “guard.” Also, there are multiple different size FPGAs you can put in the same physical footprint. The way we have architected it, if the design needs more space we can size up the FPGA.

DSP-FPGA.com: Do you expect Intel to be the “winner” in the floating point capability processor wars? Why or why not?

Marc: Mercury is processor-agnostic, and we are always evaluating processors in terms of performance per power, specifically gigaflop per watt. A lot of our products end up in size, weight, and power constrained environments. Much of the linear algebra, digital signal processing algorithms we deal with do very well when there is a vector engine. For years the e600 core devices from Freescale were ideal. Freescale has kind of moved away from that. Meanwhile, Intel has in its Core i7 the SSE 4, which is also a 128-bit vector engine. Also, there are some even wider vector engines expected from Intel, so, because of that, right now, Intel is attractive. But Mercury is open to all devices that come along that have good economy behind them and are not from a start up that could disappear.

We are always measuring, and weighing off those different metrics to the device, but right now Intel has a good offering in terms of a strong solid vector engine that can be programmed. And it is applicable to our customers, who are involved in such areas as radar, SIGINT, EOIR, doing FFTs, digital down conversion, and so on.

Arnold: I think Marc hit it right on the head. The main point is picking the right processor for the job, and the job is defined by the size, weight, and power and it is nothing more than that.

DSP-FPGA.com: What checklist are you using to determine that you have gone with the best processor for the job?

Arnold: It is hard to answer that question because it is very, very dependent on the application. An application for radar would be one kind of processor, an application for something else would need a different processor. Each one has its own specific requirements.

Marc: And, to cite another area where Mercury is agnostic, we use both Xilinx and Altera FPGAs. When Altera and Xilinx came out with Virtex 6 versus Stratix IV, there are different things we weighed, including costs. We also considered productivity. If a device is capable of extreme performance, but you need a several post-docs to program it, then it may not be considered a productive device. That also has to be examined, not just the recurring costs of the device being put to a platform of some sort.

DSP-FPGA.com: Anne you wrote an article for Military Embedded Systems, “General-purpose GPUs breathe new life into high-performance embedded computing.” Do we have a case here of this new Open VPX module [the LDS6520] breathing new life into GPGPUs?

Anne: That is interesting and brings us around to Intel. I wrote that article some months ago, and since then we have released a GPU based OpenVPX board that is called the Ensemble 6000 OpenVPX GSC6200 GPU Processing Module. In conjunction with that, the Intel boards that we have recently announced, including the Ensemble 6000 OpenVPX Intel Core 2 Duo SB6521 module and the Ensemble 6000 OpenVPX Intel Core i7 Dual-Core LDS6520 module can support the GSC6200 as host.

Within an ISR subsystem context, the company’s products are becoming more heterogeneous all the time. And you can imagine, in an ISR subsystem, a GPU-based board is performing the super high-speed image processing and exploitation. At the same time, you would have the Intel processor-based SBC feeding the GPU-based board the information and also managing some I/O. In a nutshell, what we offer is an application-ready subsystem for our customers, based on the heterogeneous product set that we have released. We are giving customers what they need to be successful in their defense applications.

DSP-FPGA.com. Does the ISR design methodology need to move away from a one step, then the next, then the next “waterfall” type methodology?

Anne: Yes, definitely. However, many primes aren’t equipped to perform “concurrent engineering”, but quick deployment-types of programs are forcing primes to consider options for system development acceleration. Also, another major problem is integration – the ability to assemble and extensively test all pieces of a system together. We are working on a paradigm called application-ready subsystems, which are comprised of board level components and other elements integrated together, including software, software and hardware services, and potentially custom driver-ware for example, to equip customers with a complete subsystem which will accept their software application.

The plan is to create an application-ready subsystem that is already integrated and qualified and that represents best of breed components that are available on the market today.

Marc: And tied into that there has also been a change in climate, with the emphasis now being on [DoD program] spiral development and quick reaction capability. So if you can have multiple development efforts in a heterogeneous system like that, that is a good thing.

Anne: Because of procurement reform many of the primes need to consider outsourcing to meet the quick demand and the pricing demand, so we see ourselves as being able to provide those application-ready subsystems that are configured, and that are qual-tested at the component level and at the system level. This is the alternative to having to make every component in house and integrate them together in “plug-and-pray” fashion. We are offering plug and play instead.

DSP-FPGA.com. Is the LDS6250 an example of taking what is there plus bringing something new to the table?

Marc: The design of that card centers around thinking in system-level terms. It is an OpenVPX board and with OpenVPX you have 192 differential pairs to play with. How do you really start to make use of all of that interconnectivity?

The sort of thing we were thinking about was, with that Core i7 on there, did we want to have an adjacent GPU board, which we had already announced, [the GSC6200]. With GPUs, if you want to get the kind of teraflop benchmarks they can supply, you have to have I/O, so you will need lots of PCI Express for instance. A strong coupling with the Intel card is essential. All those sorts of things were taken into consideration with that card. It was not “design a board in a vacuum.” A lot of thought went into many different case studies and classes of systems and application-ready subsystems.

DSP-FPGA.com. What challenges had you not expected to encounter?

Arnold: The biggest challenge in all of these designs is balancing requirements with power and space. For example, given an application you can always use more processing power or memory but you only have that much power and space. That is the biggest challenge.

Marc: Physics and also everything to do with higher signaling and signal integrity is challenging. When you change a design to optimize heat versus signal integrity, all of these things constantly have to be looked at if you want a board that is more than just effective on a lab bench. You want something that is effective on a deployed, rugged, platform. It needs high MTBF so that it can satisfy mission requirements for a lengthy period of time – all that has to be considered.

DSP-FPGA.com. Does 40/100 Gbps belong in the set of challenges?

Arnold: It comes back to balance. 100 Gbps is a great invention and the standard is now ratified. Today the bandwidth provided by 100G is more useful for the backbone of the Internet and for the Yahoos and Googles of the world – they have that kind of traffic. On our side, for a fabric, as Figure 1 shows, there are 4 fabric interfaces. So we have potentially four 40-gig interfaces which adds up to 160 Gbps of I/O that is being brought into the payload module. Right now though there are no processing technologies that can absorb that bandwidth. So it is always a balance; it is a balance of processing power to I/O, and that is the constant battle we face.

Today systems are built with 4 fabric interfaces each supporting 20 Gbps, which provides every compute element with 80 Gbps of data to process Supplying this compute infrastructure within the power and space restrictions is our main challenge.

DSP-FPGA.com: What have you noticed about the industry’s reaction to procurement reform?

Anne: The industry is very aware of the procurement reform issues, including the demand for firm, fixed-price contracts, the demand for open architectures, and the demand for rapid deployment. The primes will be taking a hard look at their capabilities and saying, “Last time we built a subsystem it took us three years, that won’t work for this QRC contract. We don’t have expertise with open systems, and hiring consultants won’t give us that expertise in the long term either. Plus, the schedule is tight, and so is the funding we receive from our customer, maybe there is a better way to leverage our internal expertise with some outside expertise who can engineer concurrently with us…and stop us from getting into those science experiments that waste our resources. Maybe some of this should be outsourced….” In short, The procurement reform movement will make people think about what they know versus what they don’t know, and what they can achieve solo versus the impossible.

Marc Couture is currently Director of Product Management for RF and IF Mixed Signal Technologies at Mercury Computer Systems, having served previously as Director of Application Engineering. Previously, he worked at Motorola Corp., Spectrum Signal Processing, Blue Wave Systems, and NUWC. Marc holds a MSEE/BSEE from UMass Dartmouth. He can be contacted mcouture@mc.com.

Anne Mascarin is a Solution Marketing Manager at Mercury Computer Systems, where she has been employed for six years. Previously, she worked at The MathWorks and Analog Devices, Inc. Anne holds a Master of Science in Electrical Engineering from Northeastern University and a Bachelor of Arts in Economics from Boston University. She can be contacted amascari@mc.com.

Arnold Sodder is a Consulting Systems Architect at Mercury Computer Systems. Arnold joined Mercury earlier this year after 20+ years developing products in the networking industry. Previously he has worked at Enterasys Networks, Tenor Networks, 3COM, DEC, EDS/GM and CMC. Arnold holds a Bachelor of Technology in Aeronautical Engineering from the Indian Institute of Technology, Bombay. He can be contacted at asodder@mc.com.

Mercury Computer Systems

http://www.mc.com