In short: A single energetic particle can silently flip a bit in an SRAM-FPGA's configuration memory and corrupt the running circuit, so flight-grade designs defend themselves with triple modular redundancy on critical logic, continuous configuration-memory scrubbing, and a hardened error-correction block such as Xilinx's Soft Error Mitigation (SEM) IP.
Single-event upsets (SEUs) are the reason an FPGA that passes every bench test on Earth can still misbehave 400 km up. This article explains where the upset actually lands, why SRAM FPGAs are uniquely exposed, and the three mitigation layers aerospace teams layer on top of each other.
What an SEU actually is
An SEU is a change of logic state caused by a single ionizing particle — a high-energy neutron, proton, or heavy ion — striking a sensitive node and depositing enough charge to flip a storage cell. It is a soft error: the silicon is undamaged, and rewriting the cell restores correct operation. That distinguishes it from a destructive single-event latch-up or gate-rupture, which permanently kills the device.
The deposited charge only matters relative to the cell's critical charge, Qcrit — roughly the node capacitance times the supply voltage. As geometries shrank from 90 nm to 16 nm FinFET and below, Qcrit fell with it, so a given particle now flips cells that an older node would have shrugged off. Shrinking nodes also raise the odds of multi-bit upsets, where one ion track crosses several adjacent cells at once.
At sea level the terrestrial neutron flux is about 13 neutrons/cm²/hr. At commercial-aircraft altitude it is roughly 300× higher, and in low Earth orbit the galactic-cosmic-ray and trapped-proton environment is harsher still — which is exactly why avionics and spacecraft, not your desktop, drive SEU engineering.
The configuration-memory problem
In an SRAM-based FPGA the user's entire design — every LUT truth table, every routing switch, every I/O setting — lives in a sea of SRAM configuration cells loaded from the bitstream at power-up. This is the critical insight that makes FPGA SEUs different from an SEU in a CPU's data path.
If an SEU flips a cell in configuration memory, it does not just corrupt one data value — it rewires the circuit. A flipped routing bit can connect a net to the wrong driver; a flipped LUT bit changes a gate's function permanently until the frame is reloaded. The fault persists across clock cycles and will not clear on its own. Contrast that with an SEU in a user flip-flop (block RAM or a CLB register), which corrupts one data bit that is typically overwritten on the next clock edge.
Flash- and antifuse-based FPGAs (Microchip's RTG4/PolarFire, for example) hold configuration in non-volatile cells that are far more robust to SEU — a key reason they are popular for space. But most high-density, high-performance parts remain SRAM-based, so the rest of this article addresses that case.
Mitigation layer 1 — Triple Modular Redundancy (TMR)
TMR instantiates the critical logic three times and feeds the three outputs into a majority voter: if one copy is upset, the two healthy copies outvote it and the correct result still propagates. Registers are usually triplicated too, with feedback voting so that a struck flip-flop is corrected the next time it is refreshed.
The cost is blunt: roughly 3× the logic plus the voters, and a drop in maximum clock frequency from the added voting delay. Teams therefore apply TMR selectively — state machines, reset logic, and watchdogs get it; a deeply pipelined datapath with downstream error checks may not. Tools such as Xilinx's XTMR and Synopsys Synplify Premier's automated TMR insertion triplicate logic at synthesis without hand-editing RTL. A subtlety: a single voter is itself a single point of failure, so robust flows triplicate the voters as well.
Mitigation layer 2 — Configuration scrubbing
TMR masks the effect of an upset but does not remove the flipped bit — leave it and a second upset in the same redundant group eventually defeats the vote (error accumulation). Scrubbing is the background process that continuously reads configuration frames, checks them, and rewrites any that are wrong, keeping the upset count near zero.
- Blind scrubbing periodically reloads every frame from a known-good golden copy in radiation-hard flash, whether or not an error exists. Simple, but it rewrites good frames constantly.
- Readback scrubbing reads each frame, verifies its ECC/CRC, and only rewrites a frame flagged as wrong — lower bus traffic and able to report where upsets occur.
Each configuration frame carries per-frame ECC (single-error-correct, double-error-detect) plus a device-wide CRC, which is what lets a scrubber localize and correct an upset rather than reloading the whole bitstream.
The figure of merit is the scrub rate versus the upset rate. If a mission sees, say, one configuration upset per few seconds, a scrub cycle completing in tens of milliseconds keeps the probability of two coincident upsets in one TMR domain vanishingly small — that margin is what you size the scrubber for.
Mitigation layer 3 — SEM IP: scrubbing done for you
Rather than hand-building a scrubber, designers drop in a vendor error-mitigation core. On AMD/Xilinx parts this is the Soft Error Mitigation (SEM) IP; Intel/Altera offers an equivalent through its ED-CRC / advanced SEU detection flow. SEM continuously runs readback through the internal configuration access port (ICAP on 7-series/UltraScale), uses the per-frame ECC to correct single-bit upsets and detect double-bit ones in place, classifies each as essential or non-essential, and exposes a status interface so the system can log the event or trigger a reset.
SEM and TMR are complementary, not alternatives. SEM corrects configuration upsets quickly to prevent accumulation; TMR keeps the design functioning correctly during the window between the upset and its correction. Serious missions use both, plus a golden image in rad-hard flash for the cases SEM flags as uncorrectable.
| Technique | Fixes the bit? | Masks the effect? | Main cost |
|---|---|---|---|
| TMR | No | Yes | ~3× area, lower Fmax |
| Scrubbing | Yes | No | Config-port bandwidth |
| SEM IP | Yes (SBE) | No | A little fabric + ICAP |
Where this lands in real aerospace design
A representative LEO payload FPGA flow: pick an SEU-aware device or run SRAM parts with full mitigation; triplicate control logic and voters with an automated TMR tool; enable SEM IP for continuous configuration repair; keep a CRC-protected golden bitstream in rad-hard flash for reload on an uncorrectable event; and quantify the result with a predicted error rate from CREME96 environment models combined with the device's measured cross-section from heavy-ion beam testing. The same discipline shows up, scaled down, in automotive ISO 26262 and medical designs, where terrestrial neutron SEUs still matter for safety-critical logic. Teams building these systems often lean on specialist FPGA and ASIC partners such as Avecas's semiconductor design services to run the beam-test characterization and mitigation sign-off.
Once you understand how the bitstream maps to physical configuration frames, scrubbing and SEM stop being black boxes — see our companion piece on the FPGA bitstream and configuration process, and the deeper treatment of FPGA reliability and fault tolerance for failure-rate budgeting.
Want to design and verify radiation-tolerant FPGA systems hands-on — TMR insertion, SEM IP bring-up, and beam-test interpretation? Explore the FPGA and VLSI tracks on our CourseTron courses page.
Frequently asked questions
Does TMR alone make an FPGA SEU-proof?
No. TMR masks the effect of a single upset but leaves the flipped bit in place. Without scrubbing, a second upset in the same redundant domain eventually breaks the majority vote. You need TMR for masking and scrubbing/SEM for repair.
Why are SRAM FPGAs more vulnerable than flash or antifuse FPGAs?
SRAM FPGAs store the entire design configuration in volatile SRAM cells, so an upset there rewires the fabric and persists. Flash and antifuse FPGAs hold configuration in non-volatile cells with far higher critical charge, so configuration SEUs are negligible — though their user flip-flops can still be upset.
What is the difference between a configuration upset and a user-logic upset?
A configuration upset flips a bit that defines the circuit (routing or LUT) and stays wrong until the frame is scrubbed. A user-logic upset flips a data bit in a flip-flop or block RAM and is usually overwritten on the next clock, so it is transient unless latched into state.
How fast does scrubbing need to be?
Fast enough that two coincident upsets in one TMR domain are extremely unlikely given the mission's predicted upset rate. In practice the scrub cycle is sized to be far shorter than the mean time between upsets — milliseconds against seconds — leaving a wide safety margin.