FPGAs, expensive and difficult to program, but essential to radar & electronic warfare systems

Story

November 23, 2015

Every month the McHale Report will host an online roundtable with experts from the defense electronics industry ? from major prime contractors to defense component suppliers. Each roundtable will explore topics important to the military embedded electronics market. This month we discuss the impact of FPGAs on military electronics designs -- how they are game changers in radar and electronic warfare signal-processing systems, but still difficult to program and expensive.

This month’s panelists are: Flemming Christensen, Managing Director, Sundance Multiprocessor Technology Ltd.; Rodger Hosking, Vice President and Founder of Pentek; Ryan Kenny, Sr. Strategic Marketing Manager, CISSP, Military Business Unit at Altera; and Jeff Milrod, President and CEO of Bittware.

MCHALE REPORT: FPGAs, once considered expensive and difficult to integrate into military signal processing designs when compared to ASICs and general-purpose processors (GPPs) are now enabling unprecedented performance in radar and electronic warfare (EW) systems. What are the benefits these components bring to military systems?

CHRISTENSEN: FPGAs are still expensive, but not compared to custom ASICs. They are still difficult to integrate, compared to a general purpose CPU. What is the benefit then? Instant re-configurability, compared to the ASIC. Magnitude performance, compared to a CPU. The benefits are: configurability, configurability, and configurability.

HOSKING: Unlike alternative devices such as CPUs and GPUs, FPGAs offer many unique features critical for military and aerospace systems. Their re-configurability lets designers arrange and interconnect hardware resources in parallel to match even the toughest real-time requirements. We are now delivering FPGA products with 3600 DSP engines and 2 million logic cells, now with the ability to reconfigure those elements under software control during a mission to adapt to evolving threats. FPGAs also provide configurable interfaces for wideband sensors like A/Ds and D/As operating at gigahertz sampling rates, as well as gigabit serial system interfaces like PCIe, Serial RapidIO, and Infiniband. Sophisticated memory controllers for the fastest SDRAMs support read/write data rates up to 1.6 GHz. With these diverse, high-performance capabilities, FPGAs deliver complete acquisition, processing, and interfacing sub-systems ideally suited for EW and radar systems that require fast I/O, low latency, and computational intensity.

KENNY: Without a doubt the primary benefits are parallelism and developments in parallel programming languages. The key to performance increases for multi-element systems (typically multi-beam, and in the future MIMO) is to break out computation into parallel compute elements, provide tailored processing capabilities to each stage (heterogeneous computing), and allow design entry methodologies that automates some of that parallelization, like OpenCL.

MILROD: FPGAs are still fairly expensive and certainly more difficult to code than GPPs, but unless you need millions of them they will almost always be cheaper and easier than ASICs now. I think that it’s generally accepted that FPGAs can provide more processing per watt, especially with the 1000s of DSP blocks now available. Most military electronics have rather tight and strict power budgets, so FPGAs provide a clear benefit there. Another significant, but less obvious benefit is the greatly reduced latency of a well-architected FPGA solution. Since designers can massively parallelize and create optimized computational units, the pipeline latency can often be reduced by orders of magnitudes compared with more conventional implementations; this is a critical benefit in close to the sensor processing such as radar, and EW, and also yields the additional benefit of determinism.

MCHALE REPORT: Aside from EW and radar, what other military electronics systems rely on FPGAs?

KENNY: Altera and Intel’s next generation military solutions include high performance computing and data analysis combining multiple sensor sources, smart ballistics and unmanned vehicles, and a resurgence in both commercial and government microelectronics in low earth orbit.

MILROD: Far and away the fastest growing segments of our military electronics business are network packet processing (NPP) applications and big data analytics (which is usually implemented through high performance computing, or HPC, techniques). These deployments are almost always in benign environments with commercial grade PCIe boards in rack servers. While these customers tend to be more closed lipped than normal about what they are doing, the NPP applications perform packet capture and deep packet inspection of network traffic for cybersecurity.

FPGAs are uniquely capable of interfacing to a large number of high-speed data ports (typically 10Gb/40Gb, and now rolling out 25Gb/100Gb) while providing agile deterministic, and reconfigurable stream processing of the extreme traffic bandwidths without dropping packets. These systems are sometimes implemented as ‘bump-in-the-wire,’ where the FPGA receives the data, inspects/modifies it, and sends it back out, or alternatively as a preprocessor to offload and/or filter traffic processed by a more complex GPP/SW solution.

Several standard algorithms have gained wide acceptance and deployment, including SNORT, Suricata, and BRO. Big Data Analytics is used for a wide range of applications, but always involves compute acceleration of big data (duh) looking for a needle (or needles) in haystacks and/or unidentified correlations. These HPC applications tend to require huge amounts of memory and very little network connectivity, with the emphasis on huge amounts of processing and correlation per data point, rather than the fast stream processing and agility required by NPP.

CHRISTENSEN: The biggest non-military use of FPGAs is communication with their low-latency and multiple high-speed parallel and serial interfaces options. The additional option for bespoke encryption of sensitive data makes them ideal for military applications – and already widely used.

HOSKING: In this increasingly unsafe world, real-time signals and communications intelligence gleaned from the overwhelming glut of radio traffic, provides vital, actionable information for military operations as well as homeland security. FPGAs are well suited to handle the acquisition, demodulation, decoding, decryption, pattern recognition, and signature classification of a wide range of radios. For example, a single FPGA can now process 1,100 channels of GSM traffic in parallel, capturing the entire traffic capacity of a given cell. In addition, FPGAs can help enhance the security and operational range of military communication systems with complex encryption and coding, adaptive spectrum management, and beamforming techniques.

MCHALE REPORT: In what applications would you not use an FPGA? Where don’t they fit in?

HOSKING: FPGAs often challenge the power consumption limits for small systems such as miniature unmanned vehicles or handheld or wearable devices. Apart from power considerations, it is generally better to implement a given task on a programmable processor, if the processor can handle the real-time requirements. Writing a C program is simpler, faster, and easier to maintain than configuring an FPGA.

MILROD: I’ve always thought of FPGAs a bit like an idiot-savant. They do some things incomparably well, and other things rather poorly. High-bandwidth data interfacing and processing incomparably well; running huge, complex, and legacy code very poorly. I would lean toward FPGAs when there is lots of data and/or lots of deterministic processing (however complex), and shy away from FPGAs when there are lots of data dependencies, exception handling, and decision making to be done.

CHRISTENSEN: Use a delicate hammer for a fine nail. Use a sledgehammer to break down a wall. The reverse is possible, but wasteful, even dangerous. Use the right tool for the job in hand. The same apply for FPGAs. If you need lots of digital signal processing for filtering, use a digital signal processor (DSP). If you need graphics processing for rendering, use a GPU. Surely, the FPGA can do everything, but its cost and the power consumption make it a bad choice.

KENNY: The cost equation for FPGAs versus ASICs always comes down to volume, which is why FPGAs are so popular in military systems that will never achieve commercial product volumes. So in the smallest and highest volume applications – perhaps micro-UAVs and expendable sensors – I expect FPGAs to play an important prototyping role but make way for highly optimized fixed circuits that will likely benefit from research efforts from [the Defense Advanced Research Projects Agency (DARPA, the Naval Research Laboratory (NRL), and the Air Force Research Laboratory (AFRL.)].

MCHALE REPORT: The downside of using FPGAs has traditionally been the difficulty in programming them in VHSIC Hardware Description Language (VHDL) as VHDL jocks are hard to find and expensive to employ. Have there been improvements in using software tools to program FPGAs? What are some examples?

MILROD: Huge and dramatic improvements! Both Altera and Xilinx have made enormous investments in to tools that enable abstractions of the FPGA complexities to algorithmic allow coding in High-Level Languages such as C, C++, and OpenCL. This is done by requiring the low-level connectivity, such as network I/F, memory controllers, clock sources, and PCIe, to be implemented in a board support package (BSP) using HDL (typically VHDL or Verilog) and then brought out to some type of standardized internal bus that the HLL compiler can use as an API.

I think of the BSP as defining fixed peripheral interfaces for the FPGA as is done in silicon for a GPP/BIOS, however, the FPGA can have many BSPs to optimize it for different boards/applications. With a BSP in the place, the FPGA can be programmed in HLL, much like a GPP , by using the HLL to HW/RTL compilers from the FPGA vendors . I like the analogy I heard one FPGA vendor’s tools manager humorously use, he liked this programming model as a jelly donut, with the BSP as the doughnut and the user code as the jelly – they can fill it up with how ever much of what ever flavor jelly they want.

To be clear, this is still early days and more polishing is required, but we now have almost 100 customers using this model for coding their FPGA’s algorithmic ‘jelly’ in C and OpenCL. Although few of them have finished implementation and deployed with HLL implementations yet, it is clear that there have been huge and dramatic improvements, with more on the way soon. As you indicated in your first question, the biggest challenge to FPGA adoption has been difficulty of implementation and lack of productivity. These dramatic improvements promise to remove those barriers soon, if they haven’t already, which could really open the floodgates for FPGA adoption and deployment.

HOSKING: Xilinx’s latest offering, the Vivado Design Suite, uses HLS (high level synthesis) for creating FPGA IP from C/C++ design input to better accommodate software-oriented engineers. Alternative design input choices include HDL using Verilog or VHDL and block diagram tools like MATLAB using System Generator. In addition, the Vivado IP Catalog is an extensive collection of plug-and-play IP modules for signal processing, communication, imaging, matrix processing, data manipulation, coding, and formatting. Third-party IP and RTL design entries can be turned into compatible IP modules using the Vivado IP Packager. Regardless of the Vivado design input, all of these newly created IP modules are compatible with the existing IP Catalog modules and all utilize the AXI4 interface, a popular derivative of the open AMBA specification from ARM. Vivado IP Integrator streamlines the installation of AXI4 interconnects as required, ensuring interoperability between IP modules.

KENNY: Altera has primarily benefited in military applications through the internal and partner support of OpenCL compile tools and accelerator cards. Stratix V and Arria 10 based OpenCL accelerator cards are making their way into Government and military enterprise systems today.

CHRISTENSEN: Difficult to program? Say whom? “A software engineer,” I guess. FPGAs are like electronic circuits and best used with tools that match, i.e. VHDL or Verilog.

However, like the “four-leaf clover,” then for each “VHDL Programmer” there are 10000s of “software programmers.” Lots of efforts, by “software engineers” going into making tools to become “FPGA Programmers,” as VHDL experts are well paid. It has been attempted for the past 20+ years and is still ongoing. More vendors are trying than days in a year, but I think VHDL will stay forever, as a “hardware description language.” The right tool!

MCHALE REPORT: Predict the future... how will FPGA impact military system designs five years from now? Will they still be as relevant or will another technology or design approach replace their importance military electronic systems?

CHRISTENSEN: When humans becomes a perfect species, then software will always work and all ASICs will work first time, then FPGAs will no longer be relevant and vanish from the market.

Ahh, you did only ask for a five-year prediction. Well, the single biggest revolution in FPGA-land is the entry (yes... – re-entry) of Intel. This is driven from the fact that all FPGA vendors now have a family of FPGAs with an ARM CPU or a ‘softcore’ CPU. The system-on-chip’ with a CPU plus a FPGA will drive everything forward, like nothing we have ever seen before. Yes, the tools will then also finally allow non-VHDL programmers to join the party and poke a toe into water with using the CPU to control the FPGA fabric, using tools like “C-to-VHDL,” MathWorks and others we have not heard about yet.

HOSKING: FPGAs devices will continue to evolve in logic density, interface speed, and processing capacity, ensuring their unique and critical role in future military systems. FPGAs with embedded ARM processors are becoming more popular. These SoC (system-on-chip) devices encompass the functions of a system CPU for control, status, decision-making, and communications along with the high-performance real-time computing functions of the adjacent FPGA fabric. The AXI4 interfaces common to all elements help in optimizing task assignments between these two domains.

KENNY: [We at] Altera and our competitors are heading the same direction, and diverging, at the same time. All of us are providing substantial integration solutions with integrated general purpose processors and hard IP blocks, and will continue to do so with advances in 3D system-in-package integration, memory integration, analog, and optical component integration, and finally advanced system design tools that interoperate with tools used in military systems design today.

MILROD: I’m quite sure I’m not qualified to predict the future, and I’ve proved that repeatedly. That said, I have no idea how FPGAs can be overcome in the next five years. Semiconductors have gotten much, much harder to develop cost effectively; therefore, an application-specific chip needs to be extremely well defined and have huge volumes to justify its existence. Niche applications, like military electronics, and changing specifications, like military electronics, will not be able to reasonably take advantage of application-specific silicon. FPGAs have regular logic and memory fabrics that are ideal for process improvements (this is why many new process lines are ‘pipe cleaned’ with FPGAs), thus I think they will continue to provide leading edge performance at least through the next sub-10nm nodes… which probably takes us out past five years.

One very interesting twist that might radically change things is Intel’s acquisition of Altera. Is it still an FPGA if it’s an integrated accelerator on, or in, a GPP? For that matter, are the existing SoCs with embedded ARM processors really ‘just’ FGPAs? Regardless, I think that while the lines of demarcation have blurred, we will continue to see more and more adoption of FPGAs in military electronics, with or without on-chip integration with GPPs, for at least the next five years.