Programmable logic: Understanding the risks in military and aerospace applications

By Dan Gardner

Are you considering the use of next-generation field-programmable gate arrays (FPGAs) to target military and aerospace applications? If so, stay alert for certain pitfalls-and opportunities-along the way.

In addition to providing inherent flexibility and reprogrammability benefits, new families of FPGAs are delivering performance and density levels that, until recently, were only possible using custom application-specific integrated circuits (ASICs).

With embedded digital signal processing (DSP), random-access memory (RAM) blocks, and microprocessor cores now easily available for use in high-end devices, it is clear that programmable logic will play a bigger role in the mil/aero arena.

Making the right choice

Historically, FPGA devices for mil/aero production lagged significantly behind commercial devices in density and performance to ensure reliability. Special packages were necessary, and stringent testing for voltage, temperature, and radiation susceptibility was mandated before devices were even qualified for mil/aero use. These tests made them more expensive and slower to market.

The perception of relatively low overall volumes had also made it less attractive for FPGA vendors to focus resources on mil/aero applications. Some technologies for commercial devices were never intended for use in the harsh operating conditions in mil/aero applications, which often made it difficult to find a direct path from commercial to military devices.

Many logic designers focused on mil/aero applications are not new to FPGAs. Most designers who have used programmable logic in some capacity on mil/aero applications are using commercial off-the-shelf (COTS) FPGA devices for feasibility studies. FPGAs have always been the obvious choice for prototyping because they offer lower cost and added flexibility.

Designing for real production, however, is a completely different story, and there are marked differences in the flows used for mil/aero applications versus those used in the commercial world. The key difference that becomes quite apparent as more and more FPGAs get drawn into mil/aero designs is speed to market. While the commercial world has seen a gradual evolution of features and functionality over time, the sudden emergence of high-end FPGAs on the mil/aero scene may seem like a disproportionately revolutionary change.

With the myriad of hardware and software solutions available for mil/aero FPGA applications, there is inevitable confusion about what is available, or for that matter appropriate, for a particular mil/aero project. Which claims are true or just marketing hype? Which features should a designer specifically look for, and what should be avoided? It is a veritable nightmare to make the correct decisions on software tools, design methodologies, and device choices, so that the final design will meet the end system requirements on schedule.

Some applications only require special extended temperature and voltage ranges, similar to those typically used in industrial applications. On the other hand, others require special care when making design and device choices; for example, to mitigate risk from single-event upsets (SEU).

Another problem involves timing and expertise. As FPGA designs get larger and more complex, it is quite common for multidisciplinary teams of engineers, often based in remote and disparate locations, to collaborate on a single project. The good news is the close partnership of many technology leaders with all the FPGA device vendors. Even electronic design automation (EDA) tool provider Mentor Graphics, which has been traditionally active within the mil/aero segment, is working with FPGA makers to deliver software for electronic-system-level design approach from FPGA design through synthesis and verification.

Platform design approach

An FPGA designer may be tempted to take a myopic view and focus on the functionality of the individual chip currently under development, but that single device is rarely the only thing on the board. Often, several FPGA devices coexist on the printed circuit board, along with several other devices.

This makes the use of an electronic- system-level (ESL) or “platform” design approach critical, especially as engineers from disciplines other than strict hardware-logic design engineering are being drawn into the fray when using programmable logic to satisfy mil/aero needs.

The first step is to shun serial, iterative, point tool approaches that involve designing from scratch. To manage nonrecurring engineering time and costs, and thus create efficient, reliable flows, mil/aero designers must clearly identify which of the various “building blocks” they need to focus on when using a platform approach to successfully implement their design.

Typical building blocks are intellectual property; lower-level blocks; DSP algorithms; RTL blocks; memory; I/O interfaces; and embedded processors.

Next, to design a high-end FPGA efficiently you need early design rule-checking; higher-level design abstraction; functional and system-level verification; and advanced, physically aware synthesis techniques.

Check sooner rather than later; large projects mandate collaboration, which raises the importance of a consistent-as well as device- and architecture-independent design coding style that teams can share effectively.

Incorrect rules and syntax/semantic errors must be rectified before even attempting to tie the building blocks together. As the system is defined in RTL by combining vendor and internal IP, adopt an integrated system design approach to synchronize the development of each specific part in a high-capacity FPGA.

As IP use proliferates, ensure that each component/subsystem developed is designed to be reusable. Moreover, since larger, faster designs have prolonged simulation/synthesis cycles, it is important to find and fix as many code errors as possible prior to the start of simulation/synthesis.

Interactive HDL visualization and creation tools provide automatic documentation and reporting, as well as intelligent debug and analysis, to manage FPGA designs and ensure tracking and accountability. Moreover, tight bidirectional communications with PCB tools from within the design creation process shortens design cycles by integrating and synchronizing HDL design with board design, which gets increasingly complicated in 1000+ pin FPGAs with high-speed interconnect and numerous I/O standards.

Raise abstraction levels. To keep pace with Moore’s Law, algorithmic C synthesis promises to raise the abstraction of hardware design, benefiting ASIC and FPGA designers.

Complexity of DSP applications has outpaced traditional RTL capabilities. To create hardware implementations for blocks of computationally intensive algorithms using RTL, design teams iterate through several steps, including micro-architecture definition, handwritten RTL, and area/speed optimization.

As a result of this slow and error-prone manual process, the micro-architecture and technology characteristics become hard-coded into the RTL description. This makes the whole notion of reuse or retargeting impractical. An optimized C-to-RTL synthesis flow promotes the flexibility to switch quickly between implementation technologies.

Designers tune the hardware for high-performance parallel implementations or to smaller, more serial implementations. This approach to describing functional intent raises engineering teams up to a more productive abstraction level for designing hardware, thus reducing implementation efforts by as much as 20 times while creating a repeatable, reliable design flow.

Verification holds the key-standard RTL verification methods diminish the benefits of faster hardware creation. Design verification takes significantly longer than design development because of the limited speed of RTL simulators and the time needed to manually create an RTL test bench.

High-level design-verification flows are turning to address rapid algorithm validation and verification using hardware acceleration, by leveraging the benefits of a SystemC verification environment. These flows begin with the algorithm designer validating designs in C++, and end with the hardware designer verifying the algorithm in RTL.

This method of using high-level C/C++ synthesis in combination with a SystemC verification environment provides an automated path from algorithm development to synthesized RTL running in an FPGA prototyping environment.

Time to get physical

Small silicon geometries are widening the distribution curve of net delays grouped by fanout, the basis behind industry-accepted wire delay models, so optimization decisions based on wire-load estimates are ineffective. Worse, physical proximity cannot always relate directly to delay, so traditional floor planning falls short.

Advanced physical synthesis techniques solve these issues in several ways. First, to improve accuracy and reduce iterations, designers can analyze real interconnect delay and physical effects up front.

Moreover, FPGA-oriented physical synthesis solutions take into account successful implementation experience. When an engineer completes modules that are optimized using physical synthesis, a good tool ensures that the entire team can reuse them on subsequent designs.

To avoid last-minute timing closure issues, designers may rewrite RTL code and constraints to coax the place-and-route tool to do their bidding. They then iterate through place-and-route-the most time-consuming step-before gaining any visibility whether their changes were beneficial or made things worse.

Any tool used in professional FPGA designs should consider FPGA vendor placement results as early as possible, and only then begin to manipulate the design using physical synthesis-integrated with logic synthesis-to converge on timing at lower cost.

Finally, advanced FPGAs like the Xilinx Virtex-4 and Altera Stratix-II devices now incorporate all major DSP elements-including multipliers, adders, subtractors, pipeline registers, and other arithmetic operations. Therefore it is important for designers to use synthesis tools that effectively inference these advanced DSP functions so as to extract high performance levels, as close to custom silicon as possible.

Mitigate the risk of SEUs

Special logic design techniques have been specifically developed to mitigate the risk of SEUs. Whether it is in finite state machine (FSM) design or metastability filters between functional blocks, key issues-many of which may never cross the designer’s mind-must be considered for a production design. Another big hurdle to overcome is verifying that the techniques used actually provide the protection required for the application.

Of course, most designers do not really want to worry about all these issues, and look for tools or devices to take care of them automatically. Be careful to differentiate between marketing claims and true facts. Always consider the big picture-hardware devices, design techniques, and software tools-all of which must come together coherently to meet the exacting requirements of the application. Every solutions provider seems to have something to say about mil/aero applications and how their solution can be used. What is not so obvious, however, is what’s left unsaid.

In mid-2004, leading FPGA chip vendor Xilinx Inc. in San Jose, Calif., began discussing radiation-tolerant SRAM-based FPGAs combined with triple-module-redundancy (TMR) software and configuration scrubbing as methods to mitigate risk from SEU effects.

Within the mil/aero community, there is still skepticism regarding the efficacy of this approach compared to traditional methods of building radiation-hardened FPGAs, as used in the antifuse, one-time-programmable (OTP) devices (available from companies like Actel and QuickLogic, for example).

In space missions, SEU response by detection and correction through reconfiguration can be acceptable because time is not a dominant factor in most cases. In mission-critical environments (including some satellite applications), in which real-time response ensures mission-execution reconfiguration and reprogrammability, this response still falls short.

Actel’s current radiation-tolerant devices have hardened registers that are immune to SEUs and avoid the overhead associated with TMR. The on-chip RAM blocks are not implemented using SEU-hardened RAM, so other techniques like error detection and correction (EDAC) must be used. Tools such as Precision Synthesis from Mentor Graphics support all the leading FPGA devices used in the mil/aero applications.

Support includes user-selectable TMR insertion for Actel devices not including SEU-immune registers. Mentor Graphics has demonstrated expertise in state machine design using a Hamming distance of three to provide automated FSM error correction for SEUs with less overhead than TMR.

Xilinx announced its QPRO Virtex-II versions in May 2004. The advantage of these devices is that they are reconfigurable (SRAM-based), but since the configuration logic is also SRAM-based and susceptible to SEUs, scrubbing techniques are required.

Using TMR will increase area by about 3.2 times and reduce performance by about 10 percent, according to Xilinx. Since the SRL16s, LUT RAM and BlockRAM features cannot use TMR or scrubbing, device performance and area are likely to be impacted if the design uses these dedicated resources, so the designer must take steps to avoid their use. It is important to note that the synthesis tools must provide this level of control or the designer’s job will be much more difficult. Simple pushbutton tools will not be enough.

The XTMR technology, announced in September 2004, operates on the EDIF netlist and Xilinx recommends that the non-TMR version of the design be verified first (see www.xilinx.com/products/milaero/MilAero.pdf).

Take care to correctly constrain the design because the triplication of the resources makes it more challenging by creating related clock domains that do not exist before running XTMR. Check out the XTMR user guide at http://www.xilinx.com/products/milaero/ug156.pdf.

FPGAs for “real” designs

The news of the massive performance gains in using parallel algorithms with the new DSP-centric FPGAs is promising. These developments have made applications such as unmanned vehicles and software-defined radio feasible, which otherwise would have faced hurdles finding solutions that delivered the levels of performance required.

The problem is the lack of FPGA radiation-tolerant solutions in the leading devices being used in these studies, and existing solutions require TMR insertion and configuration memory scrubbing to mitigate SEU effects.

The leading radiation-tolerant solutions also cannot deliver the performance of these commercial devices, although Actel’s RTAX-S devices give a performance and density boost over what most users are familiar with in the RTSX-SU/S devices.

While caution should be taken when choosing the correct tools and devices for mil/aero applications, it is exciting to see the technology offerings continuing to improve for this market.

The mil/aero community must continue to voice its concerns with the FPGA vendors and EDA tool providers, so that the special needs of this segment are heard amongst those of the other FPGA designers. Of course, it is important to find some neutral or third-party opinions when trying to compare and contrast the various issues. A good source for FPGA mil/aero-specific information and exchange of ideas is the MAPLD conference, www.klabs.org/mapld/index.htm.

FPGAs, which have already found a niche in high-end communications and intelligence applications, are poised to offer significant benefits to the military and aerospace community in real production designs. In the end, new design tools and flows will help companies leverage the advantages that FPGAs offer and thus realize their full potential in applications we may not yet have foreseen.

Dan Gardner is with the design creation and synthesis division of Mentor Graphics Corp. in Wilsonville, Ore.