Designers of virtually all electronic warfare system applications exploit CPUs and FPGAs, each offering unique strengths and advantages for handling a wide range of tasks. This diversity arises from fundamental differences in the devices. FPGAs consist of hardware logic, registers, memories, adders, multipliers and interfaces connected together by the user to perform a specific function. CPUs consist of ALUs, instruction execution engines, cache memory, dedicated I/O and memory ports all connected in a fixed architecture, whose resources are driven by program execution.
Electronic warfare systems impose some of the toughest restrictions on latency within the landscape of military electronics. For example, systems to defeat RCIEDs (radio controlled improvised explosive devices) must identify a signal that could detonate the device, and then immediately disable that communication through countermeasures. Essential tasks in the chain from receiving the signal, analyzing it, deciding which countermeasure to deploy, and then transmitting the jamming signal at the correct frequency and bandwidth, all must conform to an extremely strict time schedule. Thus, orchestrating the necessary FPGA and CPU resources becomes a critical design effort.
High level decisions and complex data analysis are usually easier to implement in a CPU. If a complex signal processing task can be handled by the CPU, it is usually easier to develop a C program for it instead of trying to develop IP for an FPGA.
An FPGA is typically much better at handling compute intensive signal processing or data crunching tasks because of its DSP blocks. Tasks like FFTs, matrix processing, and digital filtering can exploit the benefits of thousands of DSP blocks operating in parallel. Furthermore, FPGA hardware surrounding these blocks can be tailored for each application. This includes local data buffers, specialized FIFOs, and optimized interfaces to and from external sensors, storage devices, networks, and system components.
The choice of using an FPGA or a CPU for a given task may be obvious because of its nature, but other times it could go either way. If so, the decision is often made for the CPU because a C program is easier to develop, maintain and upgrade. And, from a human resource perspective, it is often easier to hire a C programmer than an FPGA designer.
Next Generation SoC FPGAs
Over the years, CPUs and FPGAs have proven their effectiveness as team players in electronic warfare systems. Because of this complementary relationship, many FPGA vendors now offer SoC (system-on-chip) devices combining CPU and FPGA resources within a single monolithic silicon device. The industry leaders in this market are Xilinx and Altera.
Xilinx offers its Zynq family of SoCs that combine ARM processors with Xilinx FPGA resources. Their most recent offering is the Zynq UltraScale+ series, whose CPU resources include a Quad-Core ARM Cortex-A53 application processor, a Dual- Core ARM Cortex-R5 real-time processor and a Mali GPU (graphical processing unit). The FPGA section includes a different mix of 16 nm resources in each of the eleven members of the series to cover a wide range of complexity. The largest member offers significant computational power with nearly a million logic cells and over 3,500 DSP slices.
A competing family of SoCs devices from Altera is the Stratix 10 series, also using the Quad-Core ARM Cortex-A53 CPU. Based on advanced 14 nm FPGA technology, the Stratix 10 offers ten different resource-balanced versions, with over 5 million logic cells and 5,760 DSP blocks in the largest device. As a major benefit over Xilinx’s SoCs, the Stratix 10 offers DSP blocks that can handle not only single- and double- precision fixed point operations, but also single-precision IEEE 754 floating point functions. Floating point math saves the often tedious task of scaling optimization to avoid saturation and underflow conditions which often plague fixed point hardware. Thus, designers can more easily boost dynamic range for sensitive signal processing applications.
FPGAs excel at processing and delivering high-rate continuous streaming data because of parallel hardware structures connected through FIFO buffers to sensors or dedicated links. CPUs are much more effective when processing blocks of data located in system memory. Because they must be interconnected, this disparity in the way CPUs and FPGAs prefer to accept and deliver data poses a fundamental challenge within SoCs.
Making the AMBA Connection
In order to mitigate this problem, the Advanced Microcontroller Bus Architecture (AMBA) was developed by ARM, Ltd. nearly two decades ago. AMBA is now widely adopted as an open source, well documented, license free interface protocol between CPUs and peripherals, including FPGAs.
A popular derivative of AMBA is the AXI4 (Advanced eXtensible Interface Rev 4) specification. It defines a comprehensive standard for transferring data between master and slave devices for data widths from 32 to 1024 bits in burst lengths of 1 to 16. A master and a slave device, both having AXI4 compliant interfaces can be connected together and communicate, regardless of the nature or function of the devices.
Because simple devices may not need the extra interface overhead required to meet the full AXI4 specification, the AXI4-Lite specification restricts data widths to either 32 or 64 bits and limits the burst length to single transfers. This is ideal for reading and writing to memory mapped status and control registers, often fully satisfying the needs of most small peripheral devices. Still another derivative is the AXI4-Stream specification, which eliminates the addressing overhead of AXI4 and AXI4-Lite. AXI4-Stream supports only unidirectional transfers from the master device to the slave device.
Figure 2 shows how AXI4 connection can be used to join functional blocks of a typical software radio transceiver. Full AXI4 links join the CPU to external memory and complex FPGA resources, while AXI4-Stream interfaces are more appropriate for the data converters. AXI4-Lite easily handles the simpler transfers to and from the operator interface.
SoC developers can take advantage of AXI4 protocols to handle connections among a diverse range of components using this common interface standard to implement system topology and reconcile data widths. AXI4 can also be extremely effective in reducing power and boosting transfer rates compared to competing strategies. This is critical for high performance FPGAs in real-time military embedded computing systems.
SoC Development Tools
A common methodology for SoC design is presented in Figure 3. To start, tasks are defined to satisfy system requirements, and then initially assigned by judgment to either the CPU or the FPGA. During system integration, modeling and testing, it may become apparent that a task should be reassigned to the other resource. This is an iterative process until all tasks are appropriately allocated to the CPU or FPGA for optimum system level performance. Tools from Xilinx and Altera rely upon AXI4 interconnects to facilitate changes in connections between the task modules as they are reassigned.
The SDSoC Development Environment from Xilinx supports their Zynq SoC devices. C/C++ design inputs to Eclipse compiler tools help developers determine which tasks dominate the CPU workload, identifying possible candidates for offloading to the FPGA. SDSoC coordinates execution of both the CPU and FPGA tasks, showing the effects of different partitioning and different implementations of tasks within each partition.
FPGA tasks are handled by the Xilinx Vivado Design Suite, which uses HLS (high level synthesis) to create IP from the C/C++ design input. Vivado also accepts HDL using Verilog or VHDL and System Generator output from MATLAB block diagrams. In addition, the Vivado IP Catalog offers an extensive collection of plug-and-play IP modules for signal processing, communication, imaging, matrix processing, data manipulation, coding and formatting. The Vivado IP Packager creates compatible IP modules from thirdparty IP and RTL design entries.
Since the existing IP Catalog modules and the newly-created IP modules all use AXI4 compatible interfaces, the Vivado IP Integrator can streamline the installation of AXI4 interconnects as required to ensure interoperability. SDSoC links these AXI4 IP interfaces to compatible AXI4 links on the ARM CPU, for a fully synthesized modular SoC design complete with memory mapping, modeling, debugging tools, test benches, and timing analysis.
Altera offers its SoC Embedded Design Suite that includes the Altera edition of the ARM DS-5 Development Studio to support the ARM CPU on Arria and Stratix SoCs. Based on Eclipse Tools, this open source extensible development environment includes compiler, debugger and execution tracer.
For FPGA development, Altera’s QSYS System Integration Tool allows designers to graphically connect AXI4 IP modules from Altera and IP partners. QSYS automatically configures the required interconnects to implement the subsystem by creating custom IP from schematic or HDL design inputs.
Altera integrates the SoC Embedded Design Suite with QSYS using Quartus II System Level Software. It includes Altera’s IP modules, and resources for modeling, analyzing and debugging the interaction between the ARM CPU and FPGA resources. It optionally includes DSP Builder and support for OpenCL.
The SoC Landscape
The latest generation of SoC FPGAs represent major initiatives and investments from both Xilinx and Altera. These companies compete directly for the high-end SoCs designs required for military applications by offering powerful ARM CPUs tightly coupled to powerful FPGAs. In addition to impressive silicon, both companies offer comprehensive and ambitious design tool suites. They realize that system integrators may be influenced to choose their SoC vendor based upon the effectiveness of the tools, more so than on silicon features.
In spite of the many devices available today, we are still in the early days of SoC offerings. Developers of electronic warfare systems can expect significant advances in performance over the next few years as vendors continue to boost silicon resources and race to provide tools to most easily take advantage of them.
This article was written by Rodger Hosking, Vice President, Pentek, Inc. (Upper Saddle River, NJ). For more information, Click Here .