FPGAs allow customization of SEU mitigation

Teams working on avionics, space-based electronics, weapons delivery systems, nuclear generating plants, medical imaging equipment, and other applications where radiation leads to single-event upsets (SEU) are already sensitive to functional safety requirements. What about automotive applications?

With electronic content in cars booming, complexity rising to support advanced algorithms, and semiconductor geometries shrinking, the potential for SEU errors is growing. The idea that SEUs don’t apply to terrestrial applications is completely outdated – almost any application using the latest chip technology needs a mitigation strategy. SEUs are also a function of how much atmosphere is between the chip and the sun. A chip seated in the Purple Row of Coors Field at just 5280 feet is four times more likely to experience an SEU than the same device at sea level. That same chip driven into nearby Rocky Mountain National Park with road surfaces over 11,000 feet becomes eight times more susceptible.

To solve several problems, many automotive designers are turning to FPGAs. One motivation is ISO 26262 and requirements traceability. Rather than relying on a merchant ASIC with indeterminate steps implemented, an FPGA can be completely customized to support both functional requirements and ISO 26262 requirements.

FPGAs also give designers another customization capability: tuning redundancy and mitigation techniques to handle the possibility of SEU errors. Mitigation steps are important because an error can propagate through an entire chip, and indeed throughout the entire car, very quickly. Detecting and correcting errors close to the source is key to maintaining safe operation.

The question is not if you’re going to get SEU errors – the question is, what will you do about it?

One approach would be just to implement everything in triplicate, and use voting to resolve outcomes. The likelihood that SEUs hit two legs of a triplicated circuit at the same exact time is slim. However, just tripling the real estate for an FPGA design may drive an implementation that fits over the edge. A more realistic approach uses redundancy more efficiently. This also factors in when considering ISO 26262 and realizing different subsystems have different levels of functional safety requirements.

Different FPGA constructs also have different redundancy needs. Finite state machines (FSMs) may use Hamming-3 codes, and safe FSMs may dictate forced resets upon error detection, or a specific error recovery scheme. Triple redundancy can come in three flavors: local TMR, where registers are triplicated and fed to a voter; distributed TMR, where TMR blocks are separated on the chip to further reduce chances of SEUs; and block-level TMR, popular where black-box IP is deployed. Memory and I/O can also be triplicated, and other techniques such as inferencing ECC and creating error flags can protect memory.

Synopsys has spent huge amounts of effort on Synplify Premier to automate high-reliability techniques for FPGA synthesis. Automotive designs can just tap in to that experience, adding functional safety steps in weeks less time compared to manual implementations.

Joe Mallett, formerly of Xilinx and now senior product marketing manager at Synopsys, has written his thoughts in the Synopsys Insight newsletter:

http://www.synopsys.com/Company/Publications/SynopsysInsight/Documents/snps-insight-issue1-2016.pdf

This newsletter contains other articles on ISO 26262 and automotive-certified IP which should be of interest to automotive teams.

Where mitigating SEUs used to be a gory, manual process, Synopsys is making the road to functional safety in FPGA designs much easier with Synplify Premier.