The logic of trusting FPGAs through DO-254

Any doubters of the importance of FPGA technology to the defense/aerospace industry should consider this: each Airbus A380 has over 1000 Microsemi FPGAs on board. That is a staggering figure, especially considering the FAA doesn’t trust FPGAs, or the code that goes into them.

The lack of trust isn’t a reflection on the fine folks at Achronix, Altera, Lattice, Microsemi, Tabula, Xilinx or any other company, or their FPGA technology. Rather, it is a reflection on a general state of mind in defense program offices and aerospace agencies regarding risk avoidance. I’m sure the other companies can offer their aerospace success stories, but I think all would agree it has been an uphill battle to gain acceptance for FPGAs in safety-critical applications.

The resistance is deeply rooted, pushing back on much of today’s complex computing technology. Consider this mind-blowing exchange from an RFI issued in February 2012. The question of interest: could respondents consolidate four ARINC 653 operating system partitions onto a single board with a multi-core processor to reduce hardware costs? The response:

Read it for yourself; I can’t just make up stuff that funny. Imagine these folks walking into a Best Buy and asking for a non-multi-core PC, tablet, or phone. Never fear, yours truly devoted a few paragraphs of guidance in my written response to that RFI, citing reasons why multi-core processors aren’t evil per se. However, in the business of safety-critical systems, I can sympathize with their position somewhat.

In the government’s thinking, the prevailing consideration in evaluating risk of an approach (beyond it has to function) is determinism. A given piece of hardware or software must respond the same way, every time, regardless of surrounding conditions or other system activity. Things like multi-core processors and hardware GPUs and FPGAs present rampant opportunities for non-deterministic behavior, because they are very capable of having multiple things going on simultaneously. Simulating things is, well, still a simulation, and potentially inexact enough to leave the door open for something to sneak through.

Unless, of course, you can prove otherwise with a set of hardware design policies and test results, guaranteeing responses to all potential stimuli are in fact predictable and repeatable in a known order. Proof is relatively straightforward with analog or small-scale digital logic, but for programmable things it becomes much more complex. The solutions in an avionics context are guided by DO-178B/C for software, and DO-254 which really targets FPGA-based hardware.

In the circles of DO-254, there are many approaches. Cadence, Mentor Graphics, and Synopsys and others bring RTL verification tools in various forms, and companies like Atego, ENSCO Avionics, and Patmos Engineering Services can help on the design methodology and policies side. DO-254 contains requirements for in-target testing, and this is where theAldec DO-254/CTS combined with their RTL verification tools comes in.

In-target means that the RTL is tested in the actual device of deployment, which leaves out simulators and emulators as a final step although they can help earlier in the process. While certainly the RTL can be verified in an FPGA-based prototyping system, unless it happens to be based on the FPGA of choice in the design, this also doesn’t meet all the DO-254 requirements. See above discussion on risk and strict determinism, and leave nothing to approximation.

In their DO-254 approach, Aldec has decoupled the target FPGA from a motherboard, which allows them to design a custom daughterboard with the exact FPGA model number in use. The motherboard then runs test vectors, gleaned from the RTL simulator, at the target FPGA at full operational speeds clocked by oscillators on the daughterboard at up to 250MHz. The results are then compared back to the golden vectors from the simulator. This not only shakes out functional bugs in RTL, but rattles the entire design with better coverage to uncover any interactions between IP blocks running at-speed, or any bottlenecks in the FPGA as speeds are cranked up.

Once an FPGA and its RTL have been put through the paces at-speed, only then is the FAA ready to trust a design. Without a solution like the one Aldec has, securing that trust can take person-years; instead, using in-target DO-254 testing can shorten the process to person-weeks.

Got a DO-254 story you’d like to share? We’d like to hear it.