VLSI KoreaLEO Memory Reliability: Budgeting ECC, Scrubbing and Checkpoint Recovery
A source-backed engineering reference connecting scrub deadlines, protection maps and checkpoint validity through explicit, reproducible assumptions.
Memory reliability in a LEO computer depends on bounded repair time and a trustworthy recovery state, not simply on whether ECC is present. ECC protects codewords, scrubbing limits accumulated errors, and checkpointing rolls computation back. Listing all three features does not establish a working recovery system.
VLSI Korea view: Budget data repair, fault containment and valid-state recovery separately. Verify the worst-case revisit time and shared recovery failure points before optimizing the average scrub interval.
This reference serves designers allocating memory bandwidth and verification engineers building fault-injection tests. It does not estimate an orbital error rate. Instead, it calculates how design choices change under explicitly assumed inputs.
Three responsibilities remain after adding ECC
ECC uses the relationship between stored data and check bits to detect or correct errors. Its protection depends on the selected code. Even SECDED does not mean that every multiple-bit error will be handled safely.
Correcting the value returned by a read also differs from writing the corrected value back into the memory cells. An error at an unused address can persist until the next access. A scrubber traverses addresses, reads and checks words, and performs the required repair writes to limit that exposure.
As the JPL evaluation of error-correcting codes distinguishes, permanent defects differ from correctable soft errors. Repeated writes cannot remove a physical cell defect. Isolation, spare capacity and retirement for repeatedly failing locations therefore require separate design decisions.
Control state is another responsibility. A fault in FPGA configuration memory can change the logic through which data travels, rather than just a stored value. Healthy RAM ECC does not prevent a faulty address generator, voter, reset controller or bus state from routing corrected data incorrectly.
The final responsibility is recovery. The claim that a machine can restart implicitly assumes that boot code, saved state, the recovery controller and power remain usable. Separating these budgets is not an organizational exercise. It prevents one successful test from being treated as proof of several different guarantees.
Calculate sweep completion, not just the scrub timer
Assume a 1 GiB payload, with 64 data bits and 8 ECC bits in each 72-bit codeword. The number of codewords N is 134,217,728. Assume a per-bit event rate λ of 1e-10 /s. This is not a measurement of a particular memory or orbit.
Let independent bit events follow a Poisson process, with every codeword inspected exactly once every T seconds. The expected events per codeword in an interval are μ = 72 × λ × T. The probability of at least two events in that interval is 1 − exp(−μ) × (1 + μ).
Multiplying that probability by N × 86400 / T gives the expected number of multiple-event exposure windows per day. It is not a SECDED failure rate: repeated flips of the same bit can cancel, and the model excludes correlated bursts and permanent faults.
For T of 60, 600 and 3600 seconds, the expected windows per day are 0.018, 0.180 and 1.082. These are comparison values from an assumed probability model, not a prediction that the corresponding number of incidents must occur. In the small-μ regime, shortening the interval approximately reduces accumulation exposure in proportion.
The minimum bandwidth required merely to read the payload is 17.067, 1.707 and 0.284 MiB/s, respectively. ECC transfers, commands, turnaround and corrective writeback add traffic on a real bus. A small average bandwidth number does not prove that the scrubber can always make progress using spare cycles.
The difficult case is contention. A timer can issue requests on schedule while DMA and CPU accesses repeatedly delay their completion. Record the request interval, full sweep completion time and maximum time before any codeword is revisited as separate measurements. A single average can hide the most exposed address.
If different addresses do not share the same T, the uniform-interval calculation cannot be applied unchanged. Measure the revisit distribution and maximum for each address or region first. Replacing a long arbitration tail with a simple average can overstate the protection actually delivered.
A smaller scrub region needs a lifetime contract
Concentrating on live regions instead of all RAM can reduce read traffic. The DFT 2025 application-profiled RAM scrubbing study connects application memory-use information to scrubber register configuration. Its evidence includes FPGA synthesis and simulation/fault injection; it must not be relabelled as an actual LEO irradiation result.
The additional design question is how long that map remains valid. The study's startup-allocation assumption does not establish arbitrary runtime reallocation. A growing heap, deeper stack or transferred DMA-buffer ownership requires separate verification that every protected live address remains registered.
VLSI Korea proposes a simple lifetime contract: a new live region enters the protection map before use, and removal of a released region must not conflict with outstanding accesses. If that mechanism cannot be implemented, constrain the workload or consider covering the whole memory range.
Stacks and allocator metadata may occupy relatively few bytes without having proportionally small failure consequences. Protection priorities should follow the path from a corrupted object into control flow, as well as its size. This is an engineering review criterion, not a measured result from the paper.
Verification should therefore extend beyond replaying a normal execution trace. Exercise maximum stack paths, buffer replacement, initialization after restart and map updates during workload transitions. Without a test that deliberately creates an uncovered address, a strong coverage number may simply omit everything outside the map.
Checkpoint timing is calculable; validity needs separate proof
A checkpoint preserves enough state to resume execution and limits lost computation after a failure. Assume a write time C = 0.05 seconds, restore time R = 2 seconds and 1 recoverable system event per day. This event rate r is separate from the earlier bit-event rate. Not every bit error becomes a system restart.
For rare fail-stop events detected immediately, valid recovery state and a uniform failure phase, the lost-time fraction can be approximated by C/T + r × (T/2 + R). The first term is checkpoint cost; the second represents average recomputation and restoration. Differentiation gives the interior minimum T = sqrt(2C/r).
With these assumptions, the result is 92.95 seconds. At T of 30, 92.95 and 600 seconds, lost time is approximately 0.186%, 0.110% and 0.358%. That minimum is not a flight-software configuration recommendation: delayed detection, interrupted checkpoint writes, external I/O and shared-controller failures are absent from the calculation.
If an error remains undetected for some time, a newly saved snapshot can already be contaminated. Selecting the newest state differs from selecting the safest state. A matching checksum does not establish semantic correctness if the system faithfully stored an incorrect computational result.
Theorem 1 in On the Integrity of Lightweight Checkpoints requires the minimum locking interval to be strictly greater than the maximum detection latency, under protected stable-memory and bounded-fault assumptions. The paper dates to 2008. This is not a general solution for simultaneous corruption of storage and the operating system.
VLSI Korea view: First define which state remains safe to restore. Without that answer, 92.95 seconds is an optimum inside an unmet set of assumptions, not an optimum recovery interval.
A practical design needs distinguishable transitions for candidate capture, validation waiting and commit. Specify how long to retain the previously valid state, what to select after reset interrupts a metadata update, and whether replay can issue an external command twice. The diagram explains these review obligations; it does not reproduce a particular paper's implementation.
Splitting controllers does not remove every shared failure
The CERN/PSI HydRA work provides a concrete ground-accelerator comparison. Its figures show separate instruction- and data-memory scrubbers, plus management and application CPUs. DRAM here labels data RAM; it does not identify a dynamic-DRAM product.
Both CPUs occupy the same FPGA and connect through shared memory. The paper describes separate restart and restrictions on modifying running application code. Neither establishes physical recovery independence or a checkpoint commit protocol. Read the figure as role separation alongside shared resources.
If the recovery controller shares a clock, power supply, configuration or metadata with the failing workload, include those resources in fault injection. Different RTL module names do not define physical fault domains. A claim of independence needs design evidence and testing that identify which faults cannot affect both sides simultaneously.
The 2025 configuration-memory study likewise addresses the vulnerability of voters and processor tiles to configuration faults. Use it to decide which control functions belong in the fault model, without converting its particular injection conditions into orbital reliability.
Correction, reset and rollback also need separate observation points. An incrementing ECC counter is not the same event as recovery of correct application output. Repairing configuration may not retract an incorrect output already sent elsewhere. Output-valid signaling, resynchronization and receiver behavior after an error belong in the end-to-end test.
For Korean design teams, request a recovery trace
A team designing an onboard computer or integrating memory, FPGA and IP can request a workload-specific maximum sweep time and the first valid output after restart alongside the supplier's ECC feature description. This is a proposed design-to-verification acceptance contract, not a claim about a Korean company's adoption plans.
Compare useful throughput rather than stopping at nominal compute performance. Track bus time for scrub reads and repair writes, checkpoint stalls, restoration, recomputation and the development effort required for injection and irradiation testing. The purpose is to establish comparable cost categories for the same workload and success criteria, without inventing sales volumes or returns.
The strongest counterargument is that independent events may not describe the dominant real failure mechanism. If correlated multiple-bit bursts or permanent defects dominate, code selection, interleaving, region isolation or component replacement may matter more than faster scrubbing. A shorter checkpoint period also does not fix shared exposure of recovery storage.
The thesis therefore has explicit breakers. Rebuild the budget if measured correlated errors dominate the independent accumulation term, a single fault damages both recovery control and saved state, or an application change places live memory outside the scrub map. A small overhead estimate cannot compensate for one of those failures.
A verification plan can record three review dates: 2027-03-07 for worst-case sweep bounds under maximum load, 2027-06-07 for allocation transitions and interrupted checkpoints, and 2027-09-07 for selected-component radiation evidence and recovery traces. These are VLSI Korea's proposed observation dates, not announced vendor milestones.
The final acceptance question is: following a specified fault, by what deadline, from which state, and starting with which output can the machine be trusted again? Reproducing that answer in a trace makes bandwidth, power and memory-capacity tradeoffs meaningfully comparable.
Primary sources and related references
Evidence is current as of 2026-09-07. Older documents support still-relevant ECC, scrubbing and checkpoint boundaries, not current orbital error rates. The memory-mitigation and safe-context guidance in ECSS-E-HB-20-40A, 2023-10-11 also informs the analysis.
- Evaluation of Error-Correcting Codes for Radiation-Tolerant Memory (2010)
- ECSS-E-HB-20-40A (2023-10-11)
- Single-event upset simulation and detection in configuration memory (2025)
- Application-profiled RAM scrubbing, DFT 2025
- On the Integrity of Lightweight Checkpoints (2008)
- HydRA, JACoW ICALEPCS2023, DOI 10.18429/JACoW-ICALEPCS2023-MO4AO02
For broader system constraints, see VLSI Korea's orbital data-center technical report (Korean). For a different error-induction mechanism, see the Rowhammer reference (Korean). Their environments and threat models must not be mixed with this article's independent-event assumptions.
AI assisted public-source research, article organization and original diagram production. Calculations were recomputed from saved inputs and code, and an independent factual reviewer checked both editions and the visual assets. Every calculated example uses assumed inputs and makes no claim about actual mission performance or equipment adoption.
