Pith. sign in

REVIEW 4 major objections 4 minor 34 references

Flexible Vector Integration in Embedded RISC-V SoCs for End to End CNN Inference Acceleration

T0 review · 4 major / 4 minor · reviewed 2026-08-06 · deepseek-v4-flash

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

Pith's one-line read A vector coprocessor can absorb the CPU fallback work that dominates DLA-based CNN inference, cutting image pre-processing by up to 9x and YOLOv3 fallback-layer execution by up to 3x versus a scalar CPU.

desk verdict A legitimate simulation study of a vector fallback unit for NVDLA is mismarked as RVV 1.0 validation; the engineering result survives, the central claim does not. read the letter →

arxiv 2507.17771 v1 pith:ZVGQ3HZT submitted 2025-07-19 cs.DC eess.IV

Dmitri Lyalikov This is my paper
classification cs.DCeess.IV
keywords RISC-VvectorextensionRVV1.0CNNinferenceaccelerationdeeplearningacceleratorYOLOv3embeddedSoCCPUfallback
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

This paper argues that the RISC-V Vector 1.0 extension gives accelerator-rich embedded SoCs a low-power way to handle the parts of CNN inference that deep-learning accelerators do not support. The authors profile YOLOv3 running on a RISC-V system built around an NVDLA deep-learning accelerator and find that CPU fallback operations and image pre-processing, not the accelerator itself, make up a large share of end-to-end latency. They integrate a tightly coupled vector coprocessor into the SoC, hand-vectorize those fallback kernels, and report up to 9x speedup for image pre-processing and up to 3x for YOLOv3 fallback-layer execution compared to a scalar CPU, with memory-system prefetching contributing about 3x on its own. The intended takeaway is that a stable vector programming model such as RVV 1.0 can deliver balanced computation and memory footprint across the whole CNN dataflow while staying within embedded power budgets.

What carries the argument

The mechanism is a vector coprocessor attached as a tightly coupled accelerator with direct access to the L2 cache, using a vector-fetch programming model: the scalar core invokes a procedure on the coprocessor with a single instruction, and the coprocessor streams data in and out of vector registers while the core waits at a fence. The coprocessor has a 2048-bit maximum vector length, and the paper's kernels use a single vector register plus a predicate, with line and surface strides hoisted out of the inner loop and prefetch instructions inserted around the streaming loads to keep the cache from idling. This tightly coupled placement is what lets the vector unit absorb the small, data-rearrangement-heavy fallback operations that a loosely coupled DLA cannot efficiently run, and it is the concrete stand-in for the RVV 1.0 programming model the paper argues for.

What would settle it

Re-run the same converter and image pre-processing kernels on a real RISC-V V 1.0 core in the same simulated SoC with the same cache geometry and measure the speedups; if the 3x to 9x results do not reproduce, the paper's claim that RVV 1.0 delivers these gains is refuted.

Watch

Extended reading notes

Core claim

The central discovery is that in a DLA-centered CNN inference system the performance bottleneck is outside the accelerator: the unsupported layers and pre/post-processing routines that run on the scalar CPU dominate the latency budget. The paper shows this by mapping every YOLOv3 layer to either the NVDLA accelerator or the CPU, then re-implementing the CPU-side tensor conversions and image pre-processing as vector kernels executed on a custom vector-fetch coprocessor attached tightly to the core. In a cycle-accurate, memory-accurate simulation of the integrated SoC, the vectorized converter reaches up to almost 10x speedup, the full image pre-processing pipeline reaches up to 9x, and the YOLOv3 fallback-layer execution is up to 3x faster than the CPU baseline. The paper takes these results as evidence that the ratified RISC-V Vector 1.0 extension is a flexible and stable target for the fallback work that DLAs leave behind, and it packages the kernels as an open-source vector library of common fallback operations.

Load-bearing premise

The speedups were measured on a custom vector coprocessor with its own instruction set, not on an actual RISC-V V 1.0 core, and the paper assumes without test that the same benefits will appear on a true RVV 1.0 implementation.

Editorial extensions

If this is right

  • The same SoC can keep its DLA for convolution-heavy layers and use a vector unit for format conversions, resizing, and other unsupported operations, covering more of the CNN dataflow without adding a GPU.
  • Because the fallback kernels are simple nested loops with little memory reuse, software prefetching and cache-geometry tuning are as important as the vector instructions themselves; the paper measured roughly 3x from prefetching alone.
  • A stable vector ISA gives deep-learning compilers one portable fallback target to lower unsupported layers onto, instead of scattering them across CPU-specific or DLA-specific code paths.
  • The reported preprocessing speedups directly improve effective frame rate, which matters for embedded markets such as ADAS and drones where end-to-end latency, not just accelerator throughput, determines usability.

Reading between the lines

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

  • A consequence the paper leaves implicit is that on the baseline data (66 ms of CPU fallback out of 133 ms inference), vectorizing just the fallback layers could roughly double the throughput of the DLA pipeline even before any change to the accelerator itself.
  • The natural next experiment is to recompile the same kernels for a true RISC-V V 1.0 core rather than the custom vector-fetch coprocessor used here; until that is measured, the speedups should be treated as evidence about vector-style execution generally rather than about RVV 1.0 specifically.
  • Because the fallback operations are generic tensor rearrangements, the same vector-fallback pattern should transfer to other DLA and NPU SoCs whose compilers leave unsupported layers on a scalar CPU.
  • The paper's expectation that auto-vectorization will ease adoption points to a testable extension: evaluating whether compiler auto-vectorization can recover most of the hand-written kernel speedups on an actual RVV 1.0 core.
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

4 major / 4 minor

Summary. The paper presents a system-level integration study of a vector coprocessor into a RISC-V SoC containing an NVDLA deep learning accelerator, using YOLOv3 inference as the workload. It identifies CPU fallback operations and image preprocessing as bottlenecks, maps selected kernels to a Hwacha vector coprocessor attached via the Rocket Custom Coprocessor Interface, tunes cache behavior with prefetching, and reports speedups in simulation. The abstract and conclusion claim that the results demonstrate the RISC-V Vector 1.0 (RVV 1.0) extension as a flexible target for CNN fallback and preprocessing, with up to 9x speedup for preprocessing and up to 3x for fallback-layer execution at lower power.

Significance. If the central claim were supported, the paper would provide a useful data point for using a vector unit to fill the fallback gap of domain-specific CNN accelerators in embedded SoCs, with a concrete open-source library (VecBoost) and cycle-accurate FireSim evaluation. The manuscript is strongest where it reports concrete measurements of kernel-level and pipeline-level speedups in a reproducible simulation environment, and where it documents the memory-system effects of bulk vector accesses. However, the significance is substantially undercut because the experiments use Hwacha, a pre-RVV vector-fetch coprocessor with its own ISA, while the advertised contribution is an RVV 1.0 demonstration. The power claim in the abstract is likewise not backed by any measurement in the paper. These are not merely presentational issues; they concern the validity of the paper's principal conclusion.

major comments (4)
  1. [§6, §6.2, abstract, §8] The central claim that the experiments 'demonstrate RVV-1.0' is unsupported. Section 6 attaches 'a 2048 Maximum Vector Length Hwacha' through the Rocket-Custom-Coprocessor Interface and passes 'custom xHwacha RISC-V extension instructions'; Listing 1 shows Hwacha mnemonics such as setvcfg, vmca, lat0, and vf0, plus a fence, none of which are RVV 1.0 instructions. RVV 1.0 uses vsetvli/vle/vse, vector mask registers, and does not use the Hwacha vector-fetch model in which the core sets a coprocessor program counter and issues a vector fetch. No transferability argument is given for why speedups measured on Hwacha would hold on an RVV 1.0 core with different vector-length handling, register file, and memory instructions. Since the abstract and conclusion attribute the results to RVV 1.0, the headline contribution is not established by the presented evidence.
  2. [§6.4, Table 4, abstract] The speedup headline conflates a kernel-level result with the pipeline-level result. Table 4 reports 9.934x for the Converter kernel at large image size, but the corresponding Total row is 3.668x. The abstract states 'up to a 9x speedup of image pre-processing,' which presents the single-kernel number as if it characterized the preprocessing pipeline. In addition, §6.4 says speedups were 'between 3-72x compared to scalar, single threaded CPU implementation,' but no workload or configuration corresponding to 72x is given, and Table 4's measured range is 2.260x to 9.934x. The baseline also shifts: the table and text compare against a scalar, single-threaded CPU, whereas earlier sections describe a quad-core Rocket/OpenMP implementation; the claim 'compared to CPU' therefore overstates the gain over the actual deployment baseline.
  3. [abstract, §8] The abstract and conclusion assert that the approach consumes 'less power than traditional parallel execution platforms,' but no power measurement appears anywhere in the manuscript. Section 7 cites prior work on vector low-power design, which does not measure this design's power. This claim should be removed or replaced by actual power numbers from the FireSim/implementation flow; as written, it is an unquantified assertion presented as a result.
  4. [§6.4, Table 4] The composition of the 'Total' rows in Table 4 is not defined. It is unclear whether 'Total' includes only the vector-mapped preprocessing and converter operations, or the entire end-to-end YOLOv3 pipeline including NVDLA execution and CPU-only operations such as NMS. Without a precise statement of what is included, the 3.668x total cannot be interpreted as an end-to-end system speedup, which is how the abstract's phrasing can be read.
minor comments (4)
  1. [abstract, §1] The abstract and the first paragraph of the introduction repeat the same sentences nearly verbatim, including the duplicated sentence 'There is a critical need for proper system integration and an efficient compilation/execution model for balanced execution in these heterogeneous architectures.'
  2. [§6] There is a typo on the line introducing the Hwacha interface: 'custum xHwacha RISC-V extension instructions' should be 'custom.'
  3. [Table 3] The vector-processor row lists 'Ultra-low' power without a citation or a measured quantity, and the paper does not later substantiate this value; the row should be marked as an estimate rather than a reported result.
  4. [Listing 1] Listing 1 would benefit from a short legend stating which instructions are Hwacha-specific and which, if any, correspond to RVV 1.0 functionality, since the listing currently mixes C code with xHwacha assembly mnemonics that a reader may mistake for standard RISC-V vector instructions.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the speedup results come from cycle-accurate simulation measurements, not from fitting or derivation; the RVV 1.0 attribution gap is an external-validity concern, not a circular loop.

full rationale

The paper's quantitative claims are simulation measurements: image preprocessing and fallback-layer timings are taken from FireSim cycle-accurate simulation, and the reported speedups compare vector-mapped implementations against scalar CPU implementations. There is no fitted parameter that is later renamed as a prediction, no definition that presupposes the target result, and no load-bearing self-citation chain. The central concern raised by the reader is that the abstract and conclusion attribute the results to the ratified RISC-V Vector 1.0 extension, while the experiments actually use Hwacha, a custom vector-fetch coprocessor with its own xHwacha instruction interface. That is an unsupported equivalence between Hwacha and RVV 1.0, and it is a correctness or overclaim issue about transferability of results, not a circularity issue: the measured speedups do not reduce by construction to the claim that RVV 1.0 is a flexible target. No equation in the paper equates Hwacha behavior with RVV 1.0 semantics, and no result is assumed in order to derive itself. Therefore the circularity score is 0, with the RVV 1.0 attribution flagged outside the circularity category as a validity gap.

Assumptions & free parameters 2 free parameters · 3 assumptions · 0 invented entities

The paper's central claim rests on an unestablished equivalence between Hwacha and RISC-V V 1.0, on FireSim simulation fidelity, and on generalizing from a single benchmark. The experimental knobs (L2 block size, prefetch placement) are tuned without exact values, but the results are measurements, not fitted derivations.

free parameters (2)
  • L2 cache block size
    Section 8 says increasing L2 cache block sizes improved performance, but exact sizes are not reported.
  • Prefetch injection distance
    Section 6.3 describes manually injected prefetch instructions; the exact timing and distance are not specified.
assumptions (3)
  • ad hoc to paper Hwacha vector coprocessor is treated as a representative RISC-V Vector 1.0 implementation.
    Abstract and Section 8 attribute results to RVV 1.0, but Section 6 describes Hwacha, an older vector-fetch ISA accessed via RoCC; no equivalence is established.
  • domain assumption FireSim simulation accurately reflects real hardware performance and power.
    All speedups are measured in FireSim at 100MHz; no power measurements are reported. Section 6.2.
  • domain assumption YOLOv3 on NVDLA is representative of modern CNN workloads on accelerator-rich SoCs.
    The paper generalizes from a single benchmark to 'modern deep-learning dataflows' in the abstract and conclusion.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Flexible Vector Integration in Embedded RISC-V SoCs for End to End CNN Inference Acceleration." pith.science (2026). https://pith.science/paper/ZVGQ3HZT

@misc{pith2026250717771,
  author       = {Pith},
  title        = {Pith review of: Flexible Vector Integration in Embedded RISC-V SoCs for End to End CNN Inference Acceleration},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/ZVGQ3HZT}},
  note         = {Machine review of arXiv:2507.17771}
}
read the original abstract

The emergence of heterogeneity and domain-specific architectures targeting deep learning inference show great potential for enabling the deployment of modern CNNs on resource-constrained embedded platforms. A significant development is the diversification of custom hardware solely targeting the most expensive parts of CNNs. DLAs (deep learning accelerators) and NPUs (neural processing units), among others, can overcome the approaching limits of traditional silicon scaling and provide a solution to the power/performance tradeoff within embedded SoCs. Efficient DSA utilization requires proper system integration and a compilation/execution model for balanced execution in these heterogeneous architectures. There is a critical need for proper system integration and an efficient compilation/execution model for balanced execution in these heterogeneous architectures. This work highlights the hardware integration challenges for efficiently placing these units within the memory hierarchy and correct proximity to other execution blocks. We experimentally verify performance bottlenecks in CNN execution and pre/post-processing at runtime, where previous attention has generally been given to accelerator speedup alone. This work takes advantage of the ratification of the RISC-V Vector 1.0 extension and demonstrates its potential as a flexible target within a well-suited cache hierarchy scheme to reduce pre-processing bottlenecks and CPU fallback processes. Our results show up to a 9x speedup of image pre-processing and YOLOv3 fallback layer execution by up to 3x compared to CPU. We demonstrate RVV-1.0 in exposing a flexible programming model that can enable a balanced computation and memory footprint on accelerator-rich embedded SoCs supporting modern deep-learning dataflows while consuming less power than traditional parallel execution platforms.

Figures

Figures reproduced from arXiv: 2507.17771 by the authors.

Figure 1
Figure 1. Streaming DLA Architecture Configurable deep learning accelerators are programmable devices that emphasize efficiency on the most expensive operations within CNNs: convolution, pooling, matrix multiplication, and activation functions. Some examples include [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Neural Processor DLA Architecture 3 CNN SOC INTEGRATION CHALLENGES This section elaborates the challenges of deploying CNN models into efficient execution models on specialized, domain specific architectures [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. TCA and LCA Architecture 4 DESIGN AND IMPLEMENTATION In order to perform a design space exploration for accelerator rich SoC, the Chipyard [2] framework was used. Chipyard provides a set of open-source parameterizable hardware generators and simulation infrastructure exposed through the Chisel HDL [6]. It provides a collection of reusable components, design methodologies, and infrastructure for designing and impleme… view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: DarkNet Image Pre-Processing Pipeline see much worse. For this reason, we evaluated the entire process in from image (.JPG in this case) to feeding into the first layer of YOLOv3. Many of these operations, written in C and built on the popular STB-I image processing li…
Figure 5
Figure 5. Figure 5: Hwacha Integration into Rocket-NVDLA System [PITH_FULL_IMAGE:figures/full_fig_p013_5.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

34 extracted references · 20 canonical work pages

  1. [1]

    Syed Asad Alam, Andrew Anderson, Barbara Barabasz, and David Gregg. 2022. Winograd Convolution for Deep Neural Networks: Efficient Point Selection. CoRR abs/2201.10369 (2022). arXiv:2201.10369 https://arxiv.org/abs/2201.10369

    work page Pith review arXiv 2022

  2. [2]

    Alon Amid, David Biancolin, Abraham Gonzalez, Daniel Grubb, Sagar Karandikar, Harrison Liew, Albert Magyar, Howard Mao, Albert Ou, Nathan Pemberton, Paul Rigge, Colin Schmidt, John Wright, Jerry Zhao, Yakun Sophia Shao, Krste Asanović, and Borivoje Nikolić. 2020. Chipyard: Integrated Design, Simulation, and Implementation Framework for Custom SoCs. IEEE M...

    arXiv 2020

  3. [3]

    Patterson, Brian Richards, Colin Schmidt, Stephen Twigg, Huy Vo, and Andrew Waterman

    Krste Asanović, Rimas Avizienis, Jonathan Bachrach, Scott Beamer, David Biancolin, Christopher Celio, Henry Cook, Daniel Dabbelt, John Hauser, Adam Izraelevitz, Sagar Karandikar, Ben Keller, Donggyu Kim, John Koenig, Yunsup Lee, Eric Love, Martin Maas, Albert Magyar, Howard Mao, Miquel Moreto, Albert Ou, David A. Patterson, Brian Richards, Colin Schmidt, ...

    work page 2016

  4. [4]

    Imad Al Assir, Mohamad El Iskandarani, Hadi Rayan Al Sandid, and Mazen A. R. Saghir. 2021. Arrow: A RISC-V Vector Accelerator for Machine Learning Inference. CoRR abs/2107.07169 (2021). arXiv:2107.07169 https://arxiv.org/abs/2107.07169

    work page Pith review arXiv 2021

  5. [5]

    Zahra Azad, Marcia Sahaya Louis, Leila Delshadtehrani, Anthony Ducimo, Suyog Gupta, Pete Warden, Vijay Janapa Reddi, and Ajay Joshi

    work page

  6. [6]

    Jonathan Bachrach, Huy Vo, Brian Richards, Yunsup Lee, Andrew Waterman, Rimas Avižienis, John Wawrzynek, and Krste Asanović. 2012. Chisel: Constructing hardware in a Scala embedded language. In DAC Design Automation Conference 2012. 1212–1221. https://doi.org/10.1145/2228360. 2228584

    doi:10.1145/2228360 2012

  7. [7]

    Lukas Baischer, Matthias Wess, and Nima Taherinejad. 2021. Learning on Hardware: A Tutorial on Neural Network Accelerators and Co-Processors. CoRR abs/2104.09252 (2021). arXiv:2104.09252 https://arxiv.org/abs/2104.09252

    work page Pith review arXiv 2021

  8. [8]

    Colby R. Banbury, Vijay Janapa Reddi, Peter Torelli, Jeremy Holleman, Nat Jeffries, Csaba Király, Pietro Montino, David Kanter, Sebastian Ahmed, Danilo Pau, Urmish Thakker, Antonio Torrini, Pete Warden, Jay Cordaro, Giuseppe Di Guglielmo, Javier M. Duarte, Stephen Gibellini, Videet 18 Lyalikov, et al. Parekh, Honson Tran, Nhan Tran, Wenxu Niu, and Xuesong...

    arXiv 2021

Show all 34 references
  1. [9]

    Yan, Leyuan Wang, Yuwei Hu, Luis Ceze, Carlos Guestrin, and Arvind Krishnamurthy

    Tianqi Chen, Thierry Moreau, Ziheng Jiang, Haichen Shen, Eddie Q. Yan, Leyuan Wang, Yuwei Hu, Luis Ceze, Carlos Guestrin, and Arvind Krishnamurthy. 2018. TVM: End-to-End Optimization Stack for Deep Learning. CoRR abs/1802.04799 (2018). arXiv:1802.04799 http://arxiv.org/abs/ 1802.04799

    2018 arXiv

  2. [11]

    Yiran Chen, Yuan Xie, Linghao Song, Fan Chen, and Tianqi Tang. 2020. A Survey of Accelerator Architectures for Deep Neural Networks.Engineering 6, 3 (2020), 264–274. https://doi.org/10.1016/j.eng.2020.01.007

    2020 doi

  3. [12]

    Cota, Paolo Mantovani, Giuseppe Di Guglielmo, and Luca P

    Emilio G. Cota, Paolo Mantovani, Giuseppe Di Guglielmo, and Luca P. Carloni. 2015. An analysis of accelerator coupling in heterogeneous architectures. In 2015 52nd ACM/EDAC/IEEE Design Automation Conference (DAC). 1–6. https://doi.org/10.1145/2744769.2744794

    2015

  4. [13]

    Shail Dave, Youngbin Kim, Sasikanth Avancha, Kyoungwoo Lee, and Aviral Shrivastava. 2019. DMazeRunner: Executing Perfectly Nested Loops on Dataflow Accelerators. ACM Trans. Embed. Comput. Syst. 18, 5s, Article 70 (oct 2019), 27 pages. https://doi.org/10.1145/3358198

    2019 doi

  5. [14]

    Farzad Farshchi, Qijing Huang, and Heechul Yun. 2019. Integrating NVIDIA Deep Learning Accelerator (NVDLA) with RISC-V SoC on FireSim. CoRR abs/1903.06495 (2019). arXiv:1903.06495 http://arxiv.org/abs/1903.06495

    2019 arXiv

  6. [15]

    Jianlong Fu and Yong Rui. 2017. Advances in deep learning approaches for image tagging. APSIPA Transactions on Signal and Information Processing 6 (10 2017). https://doi.org/10.1017/ATSIP.2017.12

    2017 doi

  7. [16]

    Hasan Genc, Seah Kim, Alon Amid, Ameer Haj-Ali, Vighnesh Iyer, Pranav Prakash, Jerry Zhao, Daniel Grubb, Harrison Liew, Howard Mao, Albert Ou, Colin Schmidt, Samuel Steffl, John Wright, Ion Stoica, Jonathan Ragan-Kelley, Krste Asanovic, Borivoje Nikolic, and Yakun Sophia Shao....

    2021

  8. [17]

    Jan Gray. 2016. GRVI Phalanx: A Massively Parallel RISC-V FPGA Accelerator Accelerator. In 24th IEEE International Symposium on Field- Programmable Custom Computing Machines (FCCM 2016)

    2016

  9. [18]

    Vladimir Herdt, Daniel Große, Sören Tempel, and Rolf Drechsler. 2021. Adaptive simulation with Virtual Prototypes in an open-source RISC-V evaluation platform. Journal of Systems Architecture 116 (2021), 102135. https://doi.org/10.1016/j.sysarc.2021.102135

    2021

  10. [19]

    Will Jones. 2021. The AI Vector Accelerator: Accelerating RISC-V for AI/ML Applications. https://www.embecosm.com/2021/04/07/the-ai-vector- accelerator-accelerating-risc-v-for-ai-ml-applications/

    2021

  11. [20]

    Endri Kaja, Nicolas Ojeda Leon, Michael Werner, Bogdan Andrei-Tabacaru, Keerthikumara Devarajegowda, and Wolfgang Ecker. 2021. Extending Verilator to Enable Fault Simulation. In MBMV 2021; 24th Workshop. 1–6

    2021

  12. [21]

    Sagar Karandikar, Howard Mao, Donggyu Kim, David Biancolin, Alon Amid, Dayeol Lee, Nathan Pemberton, Emmanuel Amaro, Colin Schmidt, Aditya Chopra, Qijing Huang, Kyle Kovacs, Borivoje Nikolic, Randy Katz, Jonathan Bachrach, and Krste Asanović. 2018. FireSim: FPGA-accelerated Cy...

    2018

  13. [22]

    Hyoukjun Kwon, Liangzhen Lai, Michael Pellauer, Tushar Krishna, Yu-Hsin Chen, and Vikas Chandra. 2021. Heterogeneous Dataflow Accelerators for Multi-DNN Workloads. In 2021 IEEE International Symposium on High-Performance Computer Architecture (HPCA) . 71–83. https://doi.org/10...

    2021

  14. [23]

    Yunsup Lee, Albert Ou, Colin Schmidt, Sagar Karandikar, Howard Mao, and Krste Asanović. 2015. The Hwacha Microarchitecture Manual, Version 3.8.1. Technical Report UCB/EECS-2015-263. EECS Department, University of California, Berkeley. http://www2.eecs.berkeley.edu/Pubs/TechRpt...

    2015

  15. [24]

    Yunsup Lee, Andrew Waterman, Rimas Avizienis, Henry Cook, Chen Sun, Vladimir Stojanovic, and Krste Asanovic. 2014. A 45nm 1.3GHz 16.7 double-precision GFLOPS/W RISC-V processor with vector accelerators. European Solid-State Circuits Conference , 199–202. https://doi.org/10.110...

    2014

  16. [25]

    Mingzhen Li, Yi Liu, Xiaoyan Liu, Qingxiao Sun, Xin You, Hailong Yang, Zhongzhi Luan, Lin Gan, Guangwen Yang, and Depei Qian. 2021. The Deep Learning Compiler: A Comprehensive Survey. IEEE Transactions on Parallel and Distributed Systems 32, 3 (2021), 708–727. https: //doi.org...

    2021

  17. [26]

    Mingzhen Li, Yi Liu, Xiaoyan Liu, Qingxiao Sun, Xin You, Hailong Yang, Zhongzhi Luan, and Depei Qian. 2020. The Deep Learning Compiler: A Comprehensive Survey. CoRR abs/2002.03794 (2020). arXiv:2002.03794 https://arxiv.org/abs/2002.03794

    2020 arXiv

  18. [27]

    Cota, Michele Petracca, Christian Pilato, and Luca P

    Paolo Mantovani, Davide Giri, Giuseppe Di Guglielmo, Luca Piccolboni, Joseph Zuckerman, Emilio G. Cota, Michele Petracca, Christian Pilato, and Luca P. Carloni. 2020. Agile SoC development with open ESP. In Proceedings of the 39th International Conference on Computer-Aided Des...

    2020

  19. [28]

    Zhang Menghan, Li Zitian, and Song Yuncheng. 2020. Optimization and Comparative Analysis of YOLOV3 Target Detection Method Based on Lightweight Network Structure. In 2020 IEEE International Conference on Artificial Intelligence and Computer Applications (ICAICA) . 20–24. https...

    2020

  20. [29]

    Anouar Nechi, Lukas Groth, Saleh Mulhem, Farhad Merchant, Rainer Buchty, and Mladen Berekovic. 2023. FPGA-Based Deep Learning Inference Accelerators: Where Are We Standing?ACM Trans. Reconfigurable Technol. Syst.16, 4, Article 60 (oct 2023), 32 pages. https://doi.org/10.1145/3...

    2023 doi

  21. [30]

    Tan Nguyen, Samuel Williams, Marco Siracusa, Colin MacLean, Douglas Doerfler, and Nicholas J. Wright. 2020. The Performance and Energy Efficiency Potential of FPGAs in Scientific Computing. In 2020 IEEE/ACM Performance Modeling, Benchmarking and Simulation of High Performance ...

    2020

  22. [31]

    Murad Qasaimeh, Kristof Denolf, Jack Lo, Kees Vissers, Joseph Zambreno, and Phillip H. Jones. 2019. Comparing Energy Efficiency of CPU, GPU and FPGA Implementations for Vision Kernels. In 2019 IEEE International Conference on Embedded Software and Systems (ICESS) . 1–8. https:...

    2019

  23. [32]

    2013–2016

    Joseph Redmon. 2013–2016. Darknet: Open Source Neural Networks in C. http://pjreddie.com/darknet/

    2013

  24. [33]

    Joseph Redmon and Ali Farhadi. 2018. YOLOv3: An Incremental Improvement. arXiv:1804.02767 [cs.CV]

    2018 arXiv

  25. [34]

    vmca va0 , %0

    Weijie Zhou, Yue Zhao, Guoqiang Zhang, and Xipeng Shen. 2020. HARP: Holistic Analysis for Refactoring Python-Based Analytics Programs. In Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering (Seoul, South Korea) (ICSE ’20). Association for Computin...

    2020

  26. [2020]

    In Boston Area Architecture (BARC) Workshop

    An end-to-end RISC-V solution for ML on the edge using in-pipeline support. In Boston Area Architecture (BARC) Workshop . http: //people.bu.edu/joshi/files/rvmlpu-barc-2020.pdf

    2020

Pith tools

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