arXiv paper· radiation effects on computing systems (hardware reliability for space)· empirical study

Proton Irradiation Characterization of an Open-Source ML Accelerator on a Zynq UltraScale+ MPSoC

Saad Memon, Rafal Graczyk, Jan Swakoń, Leszek Grzanka, Sebastian Kusyk, Mike Papadakis

cs.AR · cs.ET · cs.LG

Quick verdict

Proton-beam baseline for an open Tensil accelerator on Zynq: rigorous, candid study, but nine event onsets make the cross sections statistically fragile.

Summary

This paper reports a system-level proton-irradiation characterization of an unmitigated, open-source Tensil neural-network accelerator executing ResNet-20 CIFAR-10 inference under PYNQ Linux on a Zynq UltraScale+ SoC (Ultra96-V2), tested at 20, 40, and 58 MeV at IFJ PAN with 4.29×10^10 p/cm² delivered inside monitored operational windows. The workload ran in blocks of 100 inferences with scheduled bitstream reloads at block boundaries; monitors covered process liveness, output cadence, kernel log, network reachability, sampled power rails, and a 10-MB userspace memory test, while a top-1 oracle retained predicted classes for only 62 of 92 launched blocks. Nine primary event onsets were recorded: seven Linux-level interruptions (recovery spanning process restart to power cycle) and two silent output-corruption events. The central observation is a stuck-class episode—after 61 correct predictions, 39 consecutive outputs returned 'bird', a class absent from the ten-image pool—at the normal 23–24 ms cadence with every availability monitor nominal; observation ended at the scheduled reload (right-censored). All onsets fell under the wider 4-cm field and none under the 2-cm SoC-centered field, but field was confounded with run order and dose, so no component (e.g., LPDDR4) is attributed. Main limitations: very few events, 30 unverified blocks, and a single USB observation link.

Review complete

Assessment at a glance

radiation effects on computing systems (hardware reliability for space)

3

risk flags identified

● high 0

● medium 2

● low 1

Reproducibility readinesslow
Code & data availablenot stated
Review confidencehigh
AI text signal0/20 passages flagged
Deep research viable

5 strengths · 5 weaknesses · 5 author questions

AI text signal = Binoculars zero-shot detector score over 20 sampled passages (Fast-DetectGPT co-reported) — absence does not prove human authorship, and a flag does not imply misconduct.

Levels reflect verification complexity — not a quality score. Evolve never rates your paper.

Key claims under review

  • An unmitigated open-source Tensil accelerator on a Linux-managed Zynq UltraScale+ stack exhibits two distinct proton-induced failure modes: seven availability-loss Linux-SEFIs and two silent output-corruption events.
  • Corrupted accelerator state can persist invisibly across many inputs: 39 consecutive outputs of a class absent from the input pool occurred at nominal cadence while every availability monitor reported normal.
  • All nine event onsets occurred under the wider 4-cm beam and none under the 2-cm SoC-centered field, but the authors do not attribute a cause because field size was confounded with run order and dose.
  • Availability monitors (liveness, cadence, kernel log, memory test, power) cannot detect content corruption, so Linux-managed accelerators need end-to-end content checks and recovery that reaches the state where corruption can persist.
  • Radiation campaigns should count events by onset, match each denominator to the monitor that observes its endpoint, and report recovery actions without inferring fault origin.

Strengths

  • Unusually honest confounding handling

    The paper repeatedly refuses LPDDR4 attribution despite the tempting pattern that all nine onsets fell under the 4-cm field (Abstract, Sec. V-C), explicitly stating field was confounded with run order and dose, and Table X quantifies the field-contrast p-value across defensible record readings (0.016–0.46).

  • Genuinely novel observable with a complete monitor record

    The run-5 block-10 stuck-class episode (Figs. 1, 4; Table III) — 61 correct predictions then 39 consecutive outputs of 'bird' (class index 2), absent from the ten-image pool, at normal 23–24 ms cadence with all availability monitors nominal — is documented with tight exclusion logic: index 2 differs from the last correct class (dog, 5) and from the argmax of an all-equal score vector (0), ruling out a frozen buffer and a zeroed output vector.

  • Methodologically disciplined event counting

  • Exemplary sensitivity analysis for small counts

  • First beam baseline for an open, instrumentable accelerator

Weaknesses

  • Headline field contrast rests on three events and one reading

  • Output ascertainment is thinnest exactly where events occurred

  • Single observation path conflates link and service loss

  • Persistence beyond one block is unobservable by protocol

  • Custom Linux-SEFI definition impedes cross-study comparison

Full Review Report

$1.99 · one-time

Unlock the complete preliminary analysis Evolve produced for this paper.

Report preview

Scope & Claims

The paper reports a system-level proton-irradiation campaign on an unmitigated, open-source Tensil TCU in the programmable logic of an Avnet Ultra96-V2 (XCZU3EG Zynq UltraScale+, 16 nm) with 2 GB ECC-less LPDDR4, running PYNQ Linux and ResNet-20 CIFAR-10 inference over a fixed ten-image pool (test indices 10–19). At IFJ PAN's AIC-144 cyclotron, six monitored runs at nominal 20, 40, and 58 MeV delivered 6.19×10¹⁰ p/cm², of which 4.29×10¹⁰ fell within operational windows (Table I). The stated aims (Q1/Q2, Sec. I) are to characterize persistent corrupted state — duration, termination, and the monitor record — and to test whether wider beam fields change Linux-level interruption rates. The authors explicitly disclaim mechanism identification and mitigation evaluation; the deliverables are two failure-mode taxonomies, condition-specific cross sections (Tables VIII–IX), and three reporting practices. This scoping discipline is a strength: the abstract and Sec. V-C refuse LPDDR4 attribution despite the tempting all-onsets-wide-field pattern.

The remaining sections cover Methodology Assessment, Statistical Evidence, Results & Reproducibility, Limitations & Risks, and Verdict & Recommendations.

  • All 5 strengths & 5 weaknesses, analyzed in detail
  • 3 risk flags with severity, section & reviewer questions
  • Methods & statistical evidence assessment
  • 5 questions a peer reviewer would ask
  • Full six-dimension evaluation report & recommendations

One-time purchase · this paper only

One-time purchase, this paper only. AI-generated preliminary analysis — not peer review.

Frequently asked questions

What is a 'Linux-SEFI' in this paper?

The authors' term for a radiation-associated event that stops the prescribed Linux workload and requires at least a process restart to recover — spanning process termination, kernel oops or hang, and reboot/reset/power-cycle tiers. It is a symptom-based upper bound (it cannot exclude non-radiation or link-loss causes) and is deliberately broader than the JEDEC SEFI definition.

Why don't the authors blame the LPDDR4 memory, since all events happened under the wide beam that covered it?

Because beam field size was confounded with run order and accumulated dose: every wide-field run took place after both small-field runs. The pattern supports an association with exposure of circuitry beyond the SoC footprint, but system-level observations cannot identify which component (SoC, LPDDR4, traces, power circuitry) contained the initiating disturbance.

What was the stuck-at-bird event?

In one 100-inference block at 58 MeV, the first 61 predictions were correct, then all remaining 39 outputs returned the class 'bird' — a class absent from the ten-image input pool — at the normal 23–24 ms cadence, while the process stayed alive, the kernel log stayed silent, the memory test had passed, and power samples were in range. A scheduled bitstream reload ended the observation, so the episode's true duration is right-censored at 39 outputs (about 0.9 s).

Can the results be reproduced from the paper?

Not independently: they require a proton beam facility (IFJ PAN AIC-144), the specific Ultra96-V2 board, and a fixed PYNQ/Vivado stack. The Tensil accelerator RTL is public, but the campaign's logs, tooling, and bitstream are not stated as released, and the input sampling used no fixed seed, so the realized inference order cannot be regenerated.

About this review

This is an AI-generated preliminary review by Evolve.Pub, produced from the openly available text of the paper. It is not peer review and does not represent the authors' views. The canonical record of the paper is at the publisher link above.

  • Figures are present only as captions in the extracted text (Fig. 2 photograph, Fig. 5 console photos, timeline of Fig. 3); their visual content was not assessed. All extracted table numbers were cross-checked and are internally consistent, and the text ends cleanly at reference [27] with no signs of truncation.

Go deeper on this paper

Reproduce ResultsNot feasible for this paper — the core results cannot be re-derived by sandboxed code simulation.

Wrote a paper? Stress-test it before reviewers do.

Upload your manuscript for the same structured scrutiny — reasoning, statistics, evidence, figures, and reproducibility.

Scan your paper
Proton Irradiation Characterization of an Open-Source ML Accelerator on a Zynq UltraScale+ MPSoC | Evolve.Pub