A proton beam found silent corruption in a Zynq neural accelerator

What the work claims

This is a primary experimental result, not a proposal or a model. The authors ran a system-level proton-irradiation campaign on an Avnet Ultra96-V2 board: a Zynq UltraScale+ XCZU3EG (16-nm FinFET) with 2 GB of LPDDR4, running PYNQ Linux and the open-source Tensil Tensor Compute Unit in the programmable logic, executing a ResNet-20 classifier on CIFAR-10¹. They delivered 4.29 x 10^10 protons per square centimetre in monitored operational windows out of 6.19 x 10^10 p/cm2 delivered in monitored runs, at nominal 20, 40, and 58 MeV from a 60-MeV cyclotron.

The headline finding is a single-event functional failure with no functional signature. In one block of 100 inferences, the first 61 predictions were correct; predictions 62 to 100 were all "bird", a class absent from the ten-image input pool, delivered at the normal 23 to 24 ms cadence. Every availability indicator stayed nominal: the notebook process stayed alive, the kernel log stayed silent, the userspace memory test passed, and sampled power rails were in range. Only the top-1 content oracle, added for the experiment, caught it. Alongside that, seven Linux-level workload interruptions required recovery escalating from process restart (two events) through reboot or board reset (four) to a full power-cycle sequence (one)¹.

How it works

The experiment is best understood as an instrumented audit of a monitoring stack, and that is its real contribution. The Tensil accelerator is a 16 by 16 systolic array running at 100 MHz with 16-bit fixed-point arithmetic end to end. Weights, inputs, and outputs move between the compute fabric and external LPDDR4 over 128-bit AXI4 buses; each inference therefore exercises a chain of PS software, PS-PL interfaces, external DRAM, DMA and interconnect logic, configuration state, and accelerator-local memory. The LPDDR4 has no error-correcting code, because the single x32 device cannot provide it¹.

The authors defined two endpoints and counted onsets, not outputs: a single corrupted state producing 39 wrong answers is one event. The taxonomy separates output corruption (F3/F4) from Linux-level single-event functional interrupts (F8/F9), and matches each event to the recovery tier that cleared it (R5 process restart, R6/R7 reboot or reset, R8 power cycle). All nine primary onsets (seven interrupts plus two output events) began under the wider beam field that covered the LPDDR4 package; a matched-energy comparison gives an exploratory one-sided p-value of about 1.6 x 10^-2, which the authors state is evidence of association, not attribution, because field size was confounded with run order and dose¹.

The corrupted episode ended only because the protocol scheduled a programmable-logic reload at the block boundary, which rewrote the configuration and reloaded the model. The observation was right-censored at 39 predictions; the underlying abnormal state may have persisted into the next block, which failed to complete. The protocol, not any monitor, terminated the error¹.

Where a skeptic should push

Start with sample size: one board, one campaign, and the device lot and date codes were not recorded. Cross sections of roughly 1.3 x 10^-10 to 6.9 x 10^-10 cm2 per system are upper bounds on a radiation-induced rate, and the Linux-SEFI definition deliberately sweeps in interruptions of any origin. That is honest reporting, but the absolute numbers should not be quoted as device characterisation.

The most load-bearing assumption is that the retained records tell the whole story, and here the data is thinnest exactly where it matters. Output verification was worst at 40 and 58 MeV, the energies where the output events occurred: class records were retained for 42 of 43 launched blocks at 20 MeV, but only 11 of 28 at 40 MeV and 9 of 21 at 58 MeV. In run 5, the eight completed blocks without class records were also the eight blocks with corrected-OCM reports, and the authors state plainly they do not know why those records were lost. If record loss correlates with abnormal blocks, the output-event cross sections are underestimated. A second output event survives only as a block summary: three incorrect predictions whose order was not retained, so the record supports anywhere from one to three onsets; the primary analysis uses one¹.

Three more constraints deserve weight. The checker kept only the winning class, so numerical corruption that preserves the argmax is invisible by construction. The LPDDR4 attribution is unproven: all onsets fell under the wider field, but field was confounded with run order and dose. And the matched-energy p-values were not preregistered, so they are exploratory, not confirmatory. The paper models the right epistemic posture: report monitor blind spots with the events, and refuse causal stories the design cannot support.

Beam upsets and the MEA compute chain

Why does a space-radiation study belong on a microelectrode array site? Because the instrument at the bench is the same machine. The Zynq-class MPSoC, a processing system plus FPGA fabric with DRAM on a compact board, is the default compute layer of modern MEA acquisition: it sits after the headstage digitizers, hosts the real-time spike-sorting and burst-detection pipelines, and issues the closed-loop stimulation triggers that connect living tissue to silicon. The first calibration is scale. A proton beam delivers rates no electrophysiology lab will ever see; at terrestrial neutron and alpha fluxes these events are rare, and nobody should budget their rig around this campaign. That said, MEA work does happen beside accelerators and cyclotrons in radiobiology and proton-therapy environments, where the flux argument weakens considerably.

The transferable result is not the rate but the taxonomy, and the taxonomy is uncomfortable. The authors show, with a complete monitor record, that a watchdog assembled from the standard signals an MEA rig already logs (process alive, kernel quiet, rails in range, memory test passing) would not have detected 39 consecutive wrong inferences arriving at full cadence. Apply that to a closed-loop organoid experiment: a burst classifier driving optogenetic or electrical stimulation, silently stuck on one output class, does not trip a heartbeat check. It emits confidently wrong stimulation decisions, and because the corrupted state was input-independent, it keeps making them across every input it sees. In a 0.9 s episode that is 39 wrong decisions, not one glitch, and the study shows reboots may not clear the underlying state; recovery has to reach the layer where the corruption lives, which here meant reconfiguring the logic fabric and reloading the model.

The opportunity is equally specific. The reason this campaign could name its blind spots at all is that the accelerator is open-source RTL; the authors could instrument every layer of the PS-PL-DMA-DRAM path and add a content oracle for the price of a logging change. A closed commercial DSP pipeline, of the kind several MEA vendors ship inside their acquisition boxes, cannot be audited the same way from outside. The paper is, almost accidentally, a procurement argument: if the compute layer of your acquisition chain runs closed firmware, you cannot know whether your monitor stack has the same hole this one had, because you cannot add the oracle. A practical minimum follows directly: retain per-event inference outputs as a content log, run a golden-vector check across the inference path after any restart, and treat fabric reconfiguration plus model reload as designed recovery actions rather than a scheduled convenience¹.

The threat beyond corruption is subtler: silent wrongness poisons the archive. Event logs alone could not reconstruct which inferences in the affected block were wrong; only the retained per-inference class records could. Longitudinal organoid studies are exactly the experiments where a contaminated half-hour of undetected closed-loop data becomes a permanent fixture of a dataset. A rig that stops is a nuisance; a rig that is confidently wrong and keeps logging is a reproducibility hazard.

The bottom line

Established, and well supported by the campaign record: a Linux-managed FPGA-SoC inference stack can emit silently wrong outputs at normal speed with every availability monitor nominal; corrupted state can persist across many inferences and survive until protocol-level reconfiguration; and availability loss at these exposure levels is dominated by escalating Linux-level interruptions, not graceful accelerator errors. Asserted but unresolved: where the physical fault occurred, what the rates are at scale, and which mitigations work, since the campaign added none. For the MEA field the actionable claim is architectural: put a content oracle on the inference path of any closed-loop rig, keep the compute layer observable, and treat post-restart state as untrusted until revalidated end to end.