A single event effect is one particle producing one event with a rate proportional to flux. A lot of what a test crew sees during a heavy ion or proton run is not that. NAND flash blocks that start throwing errors after the third ion, DRAM and small geometry SRAM cells that will not hold a value and then recover a day later, silicon carbide transistors whose leakage creeps up run after run: these are damage accumulating with fluence, dressed up as events by the way the tester counts them. Put them into a cross section and integrate against a flux and the on orbit prediction is wrong in both directions at once, too many soft errors and no accounting for the permanent ones. This guide is about telling the two apart in the beam room, and about where each belongs afterward.
1. Why the distinction changes the answer
An event has a cross section: events per unit fluence, independent of how much fluence came before, cleared by the next write or reset, and it turns into an on orbit rate by integration against the flux. Damage has a dose or a fluence dependence: it depends on everything the part has already seen, it does not clear on rewrite, it may anneal with time and temperature, and it turns into an on orbit prediction by integration against the mission's accumulated exposure, which is a different integral with a different answer. The two look alike on a test log because both scale with fluence inside a run. They stop looking alike as soon as you ask about history.
The beam deposits dose, and not a little. Every ion leaves its LET's worth of energy along the track; averaged over the die, a run of 1e7 ions per square centimeter at an LET of 40 MeV cm2/mg is about 6.4 krad(Si) (dose in rad is 1.6e-5 times LET in MeV cm2/mg times fluence in ions per square centimeter; with LET in MeV cm2/g the constant is 1.6e-8). At LET 80 the same fluence is 13 krad. A campaign that walks a part up an LET ladder with several runs per ion deposits tens of krad on the same die, and heavy ions also deposit displacement damage at a rate per particle far above protons. A proton campaign to 1e11 protons per square centimeter at 200 MeV is about 5 krad(Si) and a displacement damage dose that matters for bipolar and optoelectronic parts. Commercial NAND controllers, DRAM and analog parts can begin to shift at exactly these doses. If the cross section on the last ion of the day is higher than on the first, the beam may be measuring what it did earlier that day.
2. NAND flash: three things that all look like bit errors
A heavy ion through a floating gate array can remove charge from the gates it crosses, and the cells read as upset. That is a per strike effect, prompt, proportional to fluence within a run, and cleared by erase and reprogram; it belongs in the SEE column, with the multi level cells the most sensitive because their threshold windows are narrowest. The public literature on NAND under heavy ions treats it as the array's upset cross section [1], [2].
Two other things happen in the same run and get logged in the same error counter. The dose the beam deposits shifts the threshold distributions of every cell on the die, irradiated by that run or not, and the raw bit error rate climbs with accumulated dose across the whole campaign; at the same time the periphery, the charge pumps and the state machine that do the program and erase, is ordinary CMOS and fails at ordinary CMOS doses, which for commercial NAND is typically in the tens of krad and can be lower [1], [3]. When the pump degrades, program and erase take longer, then fail, and the tester logs pages of errors that have nothing to do with the ion that happened to be on at the time. Worse, the two interact: dose accumulated earlier raises the heavy ion upset cross section measured later, by more than an order of magnitude at low LET in published work, because the shifted thresholds sit closer to the read reference [4]. A cross section taken at 30 krad is not the cross section of a fresh part.
How to tell. Errors that appear during a run, in blocks the beam was on, and vanish after erase and reprogram are upsets. Errors that keep growing between runs, that appear in blocks the beam was not on, that show up as program or erase failures or as slow programming, or that fall away after days at room temperature are dose. Keep a dose log per device: fluence times LET for every run, summed. Erase and reprogram between runs and count only what a run produced. Reserve fresh devices for the ions whose numbers matter most, and check retention and program erase timing before and after each session. If a part also has to survive a total dose requirement, run the total dose test on sibling parts with a gamma source and do not try to infer it from what the ion beam did; the dose rate and the depth profile are wrong for that purpose.
Where it goes. The per strike upsets are an SEU row in the analysis, against the controller's error correction and refresh policy, and the EDAC tool takes the per bit rate. The dose effects belong in the total dose budget with everything else on the board: a raw bit error rate that rises with dose eats correction margin over the mission, and the periphery's failure dose is a part level dose limit like any other. Neither is a rate.
3. DRAM and highly scaled SRAM: stuck bits are damage with a cross section
A single heavy ion can leave one memory cell unable to hold a state. In DRAM the mechanism is a leaky cell: the ion's local dose in the access transistor or the trench raises the leakage so the stored charge drains before the next refresh, and the cell reads wrong at the refresh interval the test is using [5], [6]. In SRAM one transistor of the cell takes a threshold shift from the ion's local dose in its gate oxide, or in the smallest geometries the gate oxide breaks down outright, and the cell is biased to one state [7], [8], [9]. The literature calls these single hard errors, stuck bits, or microdose effects; microdose is the physics, a whole total dose failure delivered to one transistor by one track [10].
Why they get counted as upsets: the count grows in proportion to fluence within a run, so they have a cross section, and a tester that only compares reads against expected values reports them in the same column as everything else. Why they are not upsets: rewriting does not clear them, the same addresses fail again on the next pass, many partially recover over hours or days at room temperature and faster with heat, some flicker between good and bad as the trapped charge moves (the intermittent stuck bits studied in synchronous DRAM [6]), and in DRAM the count depends on refresh interval and temperature because a leaky cell only fails if the refresh is too slow to save it. They appear preferentially with high LET ions and their cross section curve has its own threshold, separate from the upset curve [11].
How to tell. Log addresses, not just counts. After each run, rewrite and reread: what clears was an upset, what fails again is stuck. Reread the stuck addresses an hour later, a day later, and after a bake if the part can take it, and record the recovery. Vary the refresh interval on DRAM and watch the stuck count move. Report an upset cross section and a stuck bit cross section as separate curves against LET, and say what refresh interval and temperature the stuck curve was taken at. Do not fold the two into one number.
Where it goes. On orbit, stuck bits accumulate over the mission's heavy ion fluence above the stuck bit threshold, slowly but permanently, and each one consumes correction capacity in its word until the word is retired. The EDAC tool carries a stuck bit rate and a retirement option for exactly this; the SEE analysis workbook carries them as a hard error row against the mission fluence. They are not part of the upset rate and they should not raise it.
4. Single event leakage current in power FETs and diodes
Silicon carbide MOSFETs and Schottky diodes under heavy ions show, below the bias at which they burn out, a permanent step increase in reverse or drain leakage with each ion that strikes above a bias threshold. The steps add up: leakage grows with fluence, does not recover, and the degradation rate per unit fluence scales with the ion's LET [12], [13], [14]. The threshold bias for the onset of degradation depends on the material, the LET and the bias during the strike, and not on the part's voltage rating; published work on 4H-SiC Schottky diodes from 600 V to 1700 V puts the onset on one curve, with damage beginning at biases as low as 20 percent of rating and an operating limit near 180 V if degradation from ions below the iron knee is to be avoided entirely [14]. Choosing a higher voltage rated part buys nothing against it. Gallium nitride transistors show the same family of leakage degradation under ions [15], [16], and silicon Schottky diodes and power MOSFETs have their own versions, the latter as latent gate damage that only shows in a post irradiation gate stress [17].
Why it is conflated with burnout. A burnout test is run as a survival test: bias the part, expose to fluence, check whether it survived. A part that survived with its leakage up by a factor of a thousand passes that test and is reported as "no SEB to the fluence", and a part whose leakage climbed until the supply hit its compliance limit is reported as a burnout. Neither report describes what happened. The mechanism is also debated in the literature, localized heating in the ion's plasma shunt versus an ion induced energy pulse versus extended defect formation [13], [18], but every account agrees on the engineering facts: it is per strike, permanent, cumulative, and bias and LET dependent.
How to tell. Take a full reverse or drain current voltage sweep before and after every run and monitor the leakage during the run; a strip chart of leakage against time shows the discrete steps. Keep the fluence per run small enough, 1e4 to 1e5 per square centimeter, to resolve the steps and the bias at which they start. Report two results, the onset bias for leakage degradation and the onset bias for burnout, as separate curves against LET, and say which gate bias and temperature each was taken at. A survival test with only a pass or fail column has thrown away the result that matters for a SiC part.
Where it goes. Degradation is a derating question and a budget: the applied bias has to sit below the degradation onset for the ions the mission will see, or the leakage growth over the mission fluence above the onset has to be budgeted against the circuit's tolerance. The power device derating advisor gives the survival and derating side; the leakage budget is an integral of the step size times the flux above the onset LET at the applied bias over the mission, which is a small number in the galactic background and a large one in a storm.
5. Telling an event from damage: the questions to ask
- Within a run, is the count proportional to fluence? Both are. This test separates nothing.
- Across runs, does the count per unit fluence depend on what the device has already seen? An event's does not. Damage accelerates with history, and so does an event cross section measured on a damaged part.
- Does a rewrite, an erase, a reset or a power cycle clear it? An event clears. Damage comes back at the same address.
- Does it anneal? Wait an hour, a day, then bake if you can. Damage often recovers in part; an event that has been cleared has nothing to recover.
- Does it depend on temperature or refresh interval during the read? A leaky cell does; an upset does not.
- Does it depend on bias during the strike in a way that has a threshold voltage? Leakage degradation and burnout do; upsets do not, beyond the usual supply voltage dependence.
- Does it appear in parts of the device the beam was not on? Then it is dose or a periphery effect, not a strike in the array.
- Does the LET dependence look like the device's upset curve or like something with its own higher threshold? Stuck bits and leakage steps have their own curves.
6. What to add to the test plan
- A dose log per device: fluence times LET per run, summed, in krad(Si), with the same arithmetic for protons. Put the accumulated dose next to every cross section point in the report.
- Ion order and device rotation: low LET first, fresh devices for the ions whose numbers decide the analysis, and a spare device that sees no beam for reference measurements.
- Pre and post characterization that matches the mechanism: retention and program erase timing for flash, refresh margin and stuck address maps for DRAM, current voltage sweeps for power devices, threshold and leakage for anything with a gate oxide.
- Rewrite and reread after every run, and a scheduled reread the next day.
- Separate columns in the log, from the first run: upsets, functional interrupts, stuck addresses, leakage steps, program erase failures, with the criterion for each written down before the beam comes on.
- A gamma total dose test on sibling parts when the part has a dose requirement, rather than an inference from the beam.
- In the report, two curves where two mechanisms exist, and a plain statement of which column each point came from.
7. Where each mechanism belongs in the analysis
The single event analysis takes rates: upsets, transients, functional interrupts, latchup, burnout thresholds. The dose analysis takes doses: part failure levels, parametric drift, correction margin eroded by rising raw error rates. The displacement damage analysis takes fluences: gain, dark current, retention. Stuck bits sit between, a hard error rate over the mission's heavy ion fluence that consumes correction capacity, which is why the EDAC tool takes them as a separate input. Leakage degradation in power devices is a derating limit first and a fluence budget second. A test report that has kept its columns separate makes all of this routine; one that has not forces the analyst to guess, and the guess is usually to call everything an SEE, which overstates the soft error rate and leaves the permanent damage out of the reliability model entirely.
Frequently asked questions
Should we subtract the dose contribution from the upset counts?
Not after the fact. Separate them in the beam room by rewriting and rereading between runs and by keeping addresses. If the data are already mixed, report the cross section as an upper bound for upsets, state the accumulated dose at each point, and flag that the stuck and dose contributions were not resolved.
Our SRAM vendor says stuck bits are an upset mode. Are they wrong?
They are a single particle effect, so the label is defensible, but they are not soft and they do not clear, and treating them as upsets in a rate calculation misses the point that they accumulate. Call them hard errors, give them their own cross section, and carry them as capacity consumed over the mission.
Does leakage degradation in SiC matter in the galactic background, or only in storms?
Both, differently. The background flux above the onset LET at a given bias is small, so the mission leakage growth from it is small unless the bias is high; a storm puts the same fluence through the part in days. The derating question is decided by the highest LET the mission will see at the applied bias; the budget question by the fluence above it.
Can we use the accumulated dose from the ion beam as a total dose test?
No. The dose rate is orders of magnitude off, the depth profile is that of stopping ions rather than a gamma field, and the dose is not uniform over the die. It will tell you that the part is or is not sensitive at those doses, which is worth knowing, and nothing you can put in a dose margin.
Related tools and pages
- EDAC and Scrubbing: takes a stuck bit rate and a word retirement policy alongside the upset rate.
- Power Device Derating Advisor: survival voltages and derating for burnout; the leakage onset is the second limit to apply.
- SEE Analysis Workbook: hard error rows and the destructive branch, kept apart from the upset rows.
- TID Priors and TID Lot Acceptance: where the dose the beam deposits, and the dose the mission deposits, are judged.
- Heavy Ion SEE Test Planning: the rest of the test plan.
- Single Event Effects Explained: the effects that are events.
- Total Dose, Displacement Damage and SEE Compared: the three mechanisms side by side.
References
More guides: COTS Parts in Space · Heavy Ion SEE Test Planning · Radiation Hardness Assurance for Commercial Space · How to Run a Single Event Effects Analysis · How to Calculate a Single Event Effect Rate from Heavy Ion Test Data · Latchup or High-Current SEFI? · Single Event Effects Explained · Total Dose, Displacement Damage and Single Event Effects Compared · Glossary · All guides
Questions, corrections or a case you would like written up: the community forum or contact.