Pith. sign in

REVIEW 3 major objections 5 minor 1 cited by

Neural Network Acceleration on MPSoC board: Integrating SLAC's SNL, Rogue Software and Auto-SNL

T0 review · 3 major / 5 minor · reviewed 2026-08-05 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read SNL, a high-level-synthesis FPGA inference framework, reports lower latency than hls4ml on three of four benchmarked networks, and Auto-SNL automates Python-to-bitfile conversion.

desk verdict Useful integration and first SNL-vs-hls4ml benchmark, but latency claims rest on C-synthesis without timing closure; on-chip validation needed. read the letter →

arxiv 2508.21739 v1 pith:ZJF5C5UB submitted 2025-08-29 cs.LG cs.AIcs.AR

Hamza Ezzaoui Rahali , Abhilasha Dave , Larry Ruckman , Mohammad Mehdi Rahimifar , Audrey C. Therrien , James J. Russel , Ryan T. Herbst This is my paper
classification cs.LGcs.AIcs.AR
keywords FPGAneuralnetworkinferencehigh-levelsynthesisruntimeweightupdateAuto-SNLhls4mlfixed-pointprecisionreal-timedatareduction
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper claims that SNL, a high-level-synthesis library for putting neural networks on FPGAs, delivers competitive or better inference latency than hls4ml in three of the four architectures benchmarked on a ZCU102 board, and that the latency gap grows as hls4ml is configured to reuse more arithmetic units. It also presents Auto-SNL, a Python converter that turns high-level models into SNL-compatible HLS code, lowering the skill barrier for FPGA deployment. The motivation is real-time data reduction at x-ray free-electron lasers, where detectors produce over 1 TB/s and inference must happen in microseconds. A distinctive property of SNL is that weights and biases can be rewritten at runtime without rebuilding the FPGA bitstream. The comparison is based on synthesis and implementation reports, not on-chip timing, and some model-precision combinations failed synthesis for each tool.

What carries the argument

The central mechanism is SNL's placement of entire networks in programmable logic with weights held in AXI-Lite-accessible registers, allowing runtime reload without resynthesis, plus streaming dataflow for inputs and outputs. Auto-SNL is the conversion bridge that maps Python-defined layers to this HLS structure. In the comparison, the decisive design difference is that hls4ml embeds weights at synthesis time and exposes a reuse factor that serializes arithmetic units, trading latency for resources; SNL effectively keeps a more parallel datapath, which explains both its lower latency and its higher BRAM and flip-flop cost.

What would settle it

Measure on-chip inference latency on a ZCU102 for the same four models built with both tools, using hardware timestamps at the streaming interface, and compare; if SNL is not faster in at least three of four architectures, the paper's headline claim is overturned. Resource claims can be checked from the post-implementation utilization reports for those same bitstreams.

Watch

Extended reading notes

Core claim

In a benchmark spanning a particle-physics jet classifier and three MLPerf Tiny models (anomaly detection, keyword spotting, and visual wake words), SNL had lower reported inference latency than hls4ml for the fully connected anomaly network and the convolutional keyword-spotting and visual-wake-word networks, while the lighter jet network was faster in hls4ml. SNL achieved these latency advantages while consuming more BRAM and generally more flip-flops; for the fully connected networks it used fewer LUTs, and at higher precisions fewer DSPs. hls4ml's latency grew sharply with its reuse factor, especially for convolutional layers, while SNL's single configuration stayed flat. The paper argue

Load-bearing premise

The central claim rests on trusting the synthesis and implementation reports: no bitstream was run on the board, so the reported latencies and resource counts are estimates of what the FPGA will do.

Editorial extensions

If this is right

  • High-rate x-ray facilities could place ML data reduction at the detector front end within microsecond latency budgets.
  • Models can be retrained and updated between runs without rebuilding the FPGA bitstream, shortening iteration cycles in experiments.
  • Domain scientists who do not write C++ or HLS can go from a trained Python model to a bitfile through Auto-SNL.
  • Where resource limits are tight, hls4ml still offers fine-grained strategy and reuse control that SNL currently lacks.
  • Synthesis failures at some precision and model combinations mean neither tool is a drop-in replacement for all network shapes.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • If the synthesis estimates carry over to silicon, SNL's latency advantage should be sharpest against resource-strategy hls4ml at high reuse factors; an on-chip A/B latency measurement on the keyword-spotting network would isolate this.
  • Auto-SNL's template-based design would likely support a user-facing parallelism or reuse knob; adding one would let SNL trade resources for latency and close its main functional gap with hls4ml.
  • Runtime weight reloading makes online retraining during deployment conceivable, but the paper does not show whether AXI-Lite writes are safe while streaming inference is active; that safety test is a natural next experiment.
  • Because power consumption is not measured, SNL's extra BRAM and flip-flop usage could cost more energy per inference; a power-per-inference comparison would tell whether its latency win survives at the system level.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper presents SNL (SLAC Neural Network Library), an HLS-based FPGA inference framework, together with Auto-SNL, a Python tool that converts high-level Keras/TensorFlow models into SNL HLS code, and describes the integration with SLAC's Rogue software on a ZCU102 MPSoC. The central contribution is a synthesis-level benchmark comparing SNL with hls4ml across four neural network architectures (Jet, Anomaly, KWS, VWW), three fixed-point precisions, and, for hls4ml, additional strategy/reuse-factor settings. The authors report resource utilization from post-implementation reports and latency from C-synthesis timing analysis. They conclude that SNL achieves competitive or superior latency in three of four architectures, often at the cost of higher BRAM/FF usage, and in some cases with LUT/DSP savings.

Significance. If the reported results hold, the paper would make a useful contribution to the scientific ML-on-FPGA deployment literature: it compares an in-house framework against a widely used external baseline (hls4ml) over a multi-model, multi-precision design space, and it describes a practical automation path (Auto-SNL) that could lower the barrier to FPGA use. The resource numbers being taken from post-implementation reports is a strength relative to a purely HLS-estimate study. However, the headline latency claim rests on C-synthesis timing at a nominal 10 ns clock with no timing-closure or on-chip verification, and several synthesis failures leave the comparison matrix incomplete. The paper also does not provide code or benchmark artifacts. The contribution is therefore plausible but not yet established at the level claimed in the abstract and conclusion.

major comments (3)
  1. [IV, VI, Fig. 6, VII] The central latency comparison is based on C-synthesis timing only. Section IV states: "Latency results are obtained from the C-synthesis timing analysis," and Figure 6 reports absolute latency in microseconds assuming the configured 10 ns clock. No Worst Negative Slack (WNS), achieved fmax, or timing-closure status is reported for any design. Since SNL designs show high BRAM/FF utilization and, for CNNs, higher LUT counts (Figure 5), they are at higher risk of failing to close timing at 100 MHz. If the achieved fmax is below 100 MHz, the reported microsecond latencies overstate SNL's advantage. The paper itself acknowledges in Section VII that running on actual hardware is future work. This is load-bearing: the abstract's claim of "competitive or superior latency in most tested architectures" is not yet supported as a realizable on-board result. Please report fmax/WNS per implemented de
  2. [V-VI, Figs. 5-6] The "three out of four architectures" claim is computed over an incomplete design matrix without a stated counting rule. Section V says missing groups indicate synthesis failures; Section VI then reports SNL failures for KWS-<32,16> and VWW-<8,3>, and hls4ml failures for Anomaly-<32,16>, Anomaly-<16,6>, and Jet-<32,16> at RF 1 and 2. Thus the comparison is possible only for a subset of configurations, and the subset differs per architecture. The paper should provide a per-configuration pass/fail table and explicitly define how "most tested architectures" is counted (e.g., by precision, by configuration, or by architecture-level majority). Without this, the headline comparison is ambiguous and potentially biased by which configurations happen to be absent from the plots.
  3. [IV-VI] The comparison is asymmetric: hls4ml is swept over seven (strategy, reuse-factor) configurations per precision, while SNL has exactly one configuration with no resource-latency control knobs. The observed "gap widening as RF increases" is therefore substantially a consequence of hls4ml's intentional resource-latency trade-off, not a property of SNL. To support the framework-level claim, the paper should include a matched comparison, e.g., SNL versus hls4ml with latency strategy at RF=1 for latency, and SNL versus hls4ml resource-optimized configurations for resource use; it should also report whether SNL itself offers any resource/latency trade-off. The conclusions should be rephrased as "SNL's single synthesized configuration is faster than the hls4ml configurations we swept" rather than "SNL achieves superior latency."
minor comments (5)
  1. [II, IV] The benchmark protocol does not state whether the SNL designs were generated by Auto-SNL or hand-written SNL. Since Auto-SNL is a central contribution of the paper, please clarify its role in the experiments and, if used, provide an end-to-end example or otherwise validate that the generated HLS code is representative of SNL's capabilities.
  2. [V] Figures 5 and 6 are dense: missing groups are not annotated in the plots, there are no numeric labels, and the log-scale latency plot obscures the magnitude of differences. Please consider per-model tables with numeric values or a supplementary data table, and annotate failed configurations directly in the figures.
  3. [General] No code, benchmark scripts, or repository links are provided. The SNL and hls4ml versions are not specified beyond "Vitis HLS and Vivado 2023.1." This limits reproducibility, which matters for a benchmark paper.
  4. [II, VII] The dynamic weight-reload feature and the Rogue software integration are described but not experimentally exercised in the benchmark; no measurement of reload time or data-path throughput is reported. Please state explicitly that these are workflow descriptions rather than validated results, or add supporting measurements.
  5. [Table III] The architecture diagrams in Table III are difficult to read; a conventional layer-by-layer table (layer type, output shape, parameters) would be clearer and would support the precision and resource discussions.

Circularity Check

0 steps flagged · score 2.0 of 10

No circular derivation: benchmark claims are grounded in external toolchain reports; self-citations are background only.

full rationale

The central claim is an empirical comparison between SNL/Auto-SNL and the external hls4ml toolchain. The paper defines a benchmark protocol (Section IV) with fixed model architectures from external sources (LHC Jet, MLPerf Tiny), identical precisions, clock period, and IO type (Stream), and reports latency from Vitis HLS C-synthesis and resources from Vivado post-implementation reports. These outputs are not constructed to equal the inputs: no parameter is fitted to the reported latencies, no prediction is a renamed fit, and no uniqueness theorem or ansatz is imported from the authors' prior work. The self-citations ([1], [4], [14]) describe the SNL framework's development and prior deployment context but are not used to derive the measured latency/resource numbers. The strongest caveat — that C-synthesis latency and post-implementation resources are proxies for on-chip performance, acknowledged by the authors in Section VII ('future work will also benefit from running the synthesized models on actual hardware') — is a validity/robustness concern, not a circularity: the comparison is still an external measurement pipeline applied symmetrically to both frameworks. No circular step can be exhibited; score 2 reflects only the presence of non-load-bearing self-citations, not any reduction of the result to its inputs.

Assumptions & free parameters 0 free parameters · 1 assumptions · 0 invented entities

The paper is an empirical tool benchmark rather than a derivation; it introduces no free parameters or invented entities. Its main implicit assumption is that the synthesis tool reports reflect real hardware performance, which the authors themselves flag as a limitation.

assumptions (1)
  • domain assumption Vitis HLS C-synthesis timing reports and Vivado post-implementation resource counts are accurate proxies for on-chip latency and resource usage.
    The central latency and resource comparisons in Section V and Figure 6 are taken from C-synthesis and post-implementation reports, not from measurements on the ZCU102 board. The authors defer on-chip validation to future work in Section VII, making this the main unverified premise.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Neural Network Acceleration on MPSoC board: Integrating SLAC's SNL, Rogue Software and Auto-SNL." pith.science (2026). https://pith.science/paper/ZJF5C5UB

@misc{pith2026250821739,
  author       = {Pith},
  title        = {Pith review of: Neural Network Acceleration on MPSoC board: Integrating SLAC's SNL, Rogue Software and Auto-SNL},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/ZJF5C5UB}},
  note         = {Machine review of arXiv:2508.21739}
}
read the original abstract

The LCLS-II Free Electron Laser (FEL) will generate X-ray pulses for beamline experiments at rates of up to 1~MHz, with detectors producing data throughputs exceeding 1 TB/s. Managing such massive data streams presents significant challenges, as transmission and storage infrastructures become prohibitively expensive. Machine learning (ML) offers a promising solution for real-time data reduction, but conventional implementations introduce excessive latency, making them unsuitable for high-speed experimental environments. To address these challenges, SLAC developed the SLAC Neural Network Library (SNL), a specialized framework designed to deploy real-time ML inference models on Field-Programmable Gate Arrays (FPGA). SNL's key feature is the ability to dynamically update model weights without requiring FPGA resynthesis, enhancing flexibility for adaptive learning applications. To further enhance usability and accessibility, we introduce Auto-SNL, a Python extension that streamlines the process of converting Python-based neural network models into SNL-compatible high-level synthesis code. This paper presents a benchmark comparison against hls4ml, the current state-of-the-art tool, across multiple neural network architectures, fixed-point precisions, and synthesis configurations targeting a Xilinx ZCU102 FPGA. The results showed that SNL achieves competitive or superior latency in most tested architectures, while in some cases also offering FPGA resource savings. This adaptation demonstrates SNL's versatility, opening new opportunities for researchers and academics in fields such as high-energy physics, medical imaging, robotics, and many more.

Figures

Figures reproduced from arXiv: 2508.21739 by the authors.

Figure 1
Figure 1. High-level view of SNL’s workflow [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Auto-SNL conversion and implementation workflow. [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 3
Figure 3. SNL’s workflow for NN Deployment on ZCU102: Hardware (PL) – Software (SNL) – Rogue design flow. [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Standard hls4ml workflow for a streaming-based NN deployment on a ZCU102 running a PYNQ image. [PITH_FULL_IMAGE:figures/full_fig_p004_4.png]
Figure 5
Figure 5. Figure 5: Resource utilization across models and the different synthesis parameters, comparing SNL (bars with shading) and hls4ml. Bars are grouped by model [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]
Figure 6
Figure 6. Figure 6: Absolute latency (µs) across models and the different synthesis parameters, comparing SNL (bars with shading) and hls4ml. Bars are grouped by model and precision ⟨X, Y ⟩; hls4ml variants sweep multiple reuse factors and two strategies: Latency (L) and Resource (R). cod…

Discussion (0). Sign in to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

  1. FPGA-Accelerated Real-Time Diagnostics at DIII-D Using the SLAC Neural Network Library for ML Inference

    physics.plasm-ph 2026-04 unverdicted novelty 5.0 of 10

    An FPGA-accelerated neural network using the SLAC library was deployed in the DIII-D real-time plasma control system to forecast and help suppress disruptive ELMs from BES signals.

Reference graph

Works this paper leans on

25 extracted references · 19 canonical work pages · cited by 1 Pith paper

  1. [1]

    Implementation of a framework for deploying ai inference engines in fpgas,

    R. Herbst, R. Coffee, N. Fronk, K. Kim, K. Kim, L. Ruckman, and J. Russell, “Implementation of a framework for deploying ai inference engines in fpgas,” Springer, pp. 120–134, 2022

    work page 2022

  2. [2]

    Fpga-accelerated machine learning inference as a service for particle physics computing,

    J. Duarte, P. Harris, S. Hauck, B. Holzman, S.-C. Hsu, S. Jindariani, S. Khan, B. Kreis, B. Lee, M. Liu, V . Lon ˇcar, J. Ngadiuba, K. Pedro, B. Perez, M. Pierini, D. Rankin, N. Tran, M. Trahms, A. Tsaris, C. Versteeg, T. W. Way, D. Werran, and Z. Wu, “Fpga-accelerated machine learning inference as a service for particle physics computing,” Computing and ...

    work page doi:10.1007/s41781-019-0027-2 2019

  3. [3]

    Exploring machine learning to hardware implementations for large data rate x-ray instrumentation,

    M. Rahimifar, Q. Wingering, B. Gouin-Ferland, H. Ezzaoui Rahali, C.- E. Granger, and A. Corbeil Therrien, “Exploring machine learning to hardware implementations for large data rate x-ray instrumentation,” Machine Learning: Science and Technology , vol. 4, 11 2023

    work page 2023

  4. [4]

    Fpga- accelerated specklenn with snl for real-time x-ray single-particle imag- ing,

    A. Dave, C. Wang, J. Russell, R. Herbst, and J. Thayer, “Fpga- accelerated specklenn with snl for real-time x-ray single-particle imag- ing,” Frontiers in High Performance Computing , vol. 3, p. 1520151, 2025

    work page 2025

  5. [5]

    Vitis-ai documentation,

    AMD, “Vitis-ai documentation,” 2023, Accessed: 14-Aug-2025. [Online]. Available: https://xilinx.github.io/Vitis-AI/3.5/html/index.html

    work page 2023

  6. [6]

    Intel openvino toolkit for computer vision: Object detection and semantic segmentation,

    V . V . Zunin, “Intel openvino toolkit for computer vision: Object detection and semantic segmentation,” in 2021 International Russian Automation Conference (RusAutoCon), 2021, pp. 847–851

    work page 2021

  7. [7]

    Finn-r: An end-to-end deep- learning framework for fast exploration of quantized neural networks,

    M. Blott, T. B. Preußer, N. J. Fraser, G. Gambardella, K. O’brien, Y . Umuroglu, M. Leeser, and K. Vissers, “Finn-r: An end-to-end deep- learning framework for fast exploration of quantized neural networks,” ACM Transactions on Reconfigurable Technology and Systems (TRETS), vol. 11, no. 3, pp. 1–23, 2018

    work page 2018

  8. [8]

    Eyeriss v2: A flexible accelerator for emerging deep neural networks on mobile devices,

    Y .-H. Chen, T.-J. Yang, J. Emer, and V . Sze, “Eyeriss v2: A flexible accelerator for emerging deep neural networks on mobile devices,” IEEE Journal on Emerging and Selected Topics in Circuits and Systems, vol. 9, no. 2, pp. 292–308, 2019

    2019

Show all 25 references
  1. [9]

    Edge- drnn: Recurrent neural network accelerator for edge inference,

    C. Gao, A. Rios-Navarro, X. Chen, S.-C. Liu, and T. Delbruck, “Edge- drnn: Recurrent neural network accelerator for edge inference,” IEEE Journal on Emerging and Selected Topics in Circuits and Systems , vol. 10, no. 4, pp. 419–432, 2020

    2020

  2. [10]

    Fast inference of deep neural networks in FPGAs for particle physics,

    J. Duarte et al., “Fast inference of deep neural networks in FPGAs for particle physics,” JINST, vol. 13, no. 07, p. P07027, 2018

    2018

  3. [11]

    Fast inference of boosted decision trees in fpgas for particle physics,

    S. Summers, G. Di Guglielmo, J. Duarte, P. Harris, D. Hoang, S. Jin- dariani, E. Kreinar, V . Loncar, J. Ngadiuba, M. Pierini et al. , “Fast inference of boosted decision trees in fpgas for particle physics,” Journal of Instrumentation, vol. 15, no. 05, p. P05026, 2020

    2020

  4. [12]

    Ultra-low latency recurrent neural network inference on fpgas for physics applications with hls4ml,

    E. E. Khoda, D. Rankin, R. T. de Lima, P. Harris, S. Hauck, S.-C. Hsu, M. Kagan, V . Loncar, C. Paikara, R. Rao et al., “Ultra-low latency recurrent neural network inference on fpgas for physics applications with hls4ml,” Machine Learning: Science and Technology , vol. 4, no. ...

    2023

  5. [13]

    Fast convolutional neural networks on FPGAs with hls4ml,

    T. Aarrestad et al., “Fast convolutional neural networks on FPGAs with hls4ml,” Mach. Learn. Sci. Tech. , vol. 2, no. 4, p. 045015, 2021

    2021

  6. [14]

    Analysis of hardware synthesis strategies for machine learning in collider trigger and data acquisition,

    H. Jia, A. Dave, J. Gonski, and R. Herbst, “Analysis of hardware synthesis strategies for machine learning in collider trigger and data acquisition,” arXiv preprint arXiv:2411.11678 , 2024. 8

    2024 arXiv

  7. [15]

    Zcu102 evaluation board product page,

    AMD Xilinx, “Zcu102 evaluation board product page,” 2024, Accessed: 08-Aug-2025. [Online]. Available: https://www.amd.com/en/products/ adaptive-socs-and-fpgas/evaluation-boards/ek-u1-zcu102-g.html

    2024

  8. [16]

    Rogue software library,

    S. N. A. Laboratory, “Rogue software library,” https://github.com/ slaclab/rogue, 2025, accessed: 2025-08-14

    2025

  9. [17]

    Pynq documentation,

    AMD, “Pynq documentation,” 2025, Accessed: 14-Aug-2025. [Online]. Available: https://pynq.readthedocs.io/en/latest

    2025

  10. [18]

    hls4ml: An open-source codesign workflow to empower scientific low-power machine learning devices,

    F. Fahim, B. Hawks, C. Herwig, J. Hirschauer, S. Jindariani, N. Tran, L. Carloni, G. Di Guglielmo, P. Harris, J. Krupa, D. Rankin, M. Blanco Valentin, J. Hester, Y . Luo, J. Mamish, S. Orgrenci-Memik, T. Aarestaad, H. Javed, V . Loncar, and Z. Wu, “hls4ml: An open-source codes...

    2021 arXiv

  11. [19]

    Mlperf tiny bench- mark,

    C. Banbury, V . J. Reddi, P. Torelli, J. Holleman, N. Jeffries, C. Kiraly, P. Montino, D. Kanter, S. Ahmed, D. Pau et al. , “Mlperf tiny bench- mark,” Proceedings of the Neural Information Processing Systems Track on Datasets and Benchmarks , 2021

    2021

  12. [20]

    hls4ml lhc jet dataset (150 particles),

    M. Pierini, J. M. Duarte, N. Tran, and M. Freytsis, “hls4ml lhc jet dataset (150 particles),” 2020, 10.5281/zenodo.3602260

    2020 doi

  13. [21]

    Toyad- mos: A dataset of miniature-machine operating sounds for anomalous sound detection,

    K. Yuma, S. Shoichiro, H. Noboru, U. Hisashi, and I. Keisuke, “Toyad- mos: A dataset of miniature-machine operating sounds for anomalous sound detection,” Proc of Workshop on Applications of Signal Processing to Audio and Acoustics (WASPAA) , 2019

    2019

  14. [22]

    Speech commands: A dataset for limited-vocabulary speech recognition,

    P. Warden, “Speech commands: A dataset for limited-vocabulary speech recognition,” arXiv preprint, 2018, arXiv:1804.03209

    2018 arXiv

  15. [23]

    Visual wake words dataset,

    C. Aakanksha, P. Warden, J. Shlens, A. Howard, and R. Rhodes, “Visual wake words dataset,” arXiv preprint, 2019, arXiv:1906.05721

    2019 arXiv

  16. [24]

    hls4ml documentation,

    Fast Machine Learning Lab, “hls4ml documentation,” 2025, Accessed: 13-Aug-2025. [Online]. Available: https://fastmachinelearning.org/ hls4ml/api/configuration.html#top-level-configuration

    2025

  17. [25]

    Vivado/Vitis Software 2023.1,

    AMD Xilinx, “Vivado/Vitis Software 2023.1,” 2023, Accessed: 08- Aug-2025. [Online]. Available: https://docs.amd.com/r/2023.1-English/ ug1393-vitis-application-acceleration/Getting-Started-with-Vitis

    2023

Pith tools

Reviewed August 5, 2026 · model on record in the stance chip above.