Design and Implementation of a RISC-V SoC with Custom DSP Accelerators for Edge Computing

Priyanshu Yadav

REVIEW 5 major objections 5 minor 9 references

Design and Implementation of a RISC-V SoC with Custom DSP Accelerators for Edge Computing

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

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

Pith's one-line read Attaching a memory-mapped 1D-convolution accelerator and a dot-product unit to an RV32I core gives a ~3.37x speedup for MAC-heavy edge workloads without modifying the instruction set.

desk verdict A clear but entirely unvalidated design write-up: the abstract claims simulation and power results that the body explicitly defers to future work, leaving the 3.37x speedup and 17% power claims unsupported. read the letter →

arxiv 2506.06693 v1 pith:2YOLRM3A submitted 2025-06-07 cs.AR cs.AIeess.SP

Priyanshu Yadav This is my paper

classification cs.ARcs.AIeess.SP

keywords RISC-V1DconvolutionacceleratorDSPdot-productedgecomputingAXI-LiteTinyMLopenhardware

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 a RISC-V edge SoC does not need a modified instruction set to accelerate the multiply-accumulate loops at the heart of DSP and small neural-network workloads. Instead, it designs a lightweight 1D-convolution accelerator and a companion dot-product unit that sit beside an RV32I core, share the data SRAM through a bus arbiter, and are controlled through memory-mapped AXI-Lite registers. The central quantitative claim is a cycle-count model: a software convolution tap costs about 10 cycles on an in-order RV32IM core, while the accelerator's pipelined MAC costs about 3 cycles, giving a ~3.37x speedup for a 1024-sample, 16-tap convolution and a ~3.3x speedup for large dot products. If those numbers hold, battery-powered edge nodes could run FIR filters, matched filters, and 1D CNN layers at higher sample rates with lower energy while the CPU handles control. The paper also reports a 17% power reduction compared with Cortex-M0 implementations in similar process nodes, based on comparative analysis rather than measured silicon.

What carries the argument

The central object is the DSP CONV1D accelerator, a memory-mapped FSM-driven engine that performs the sliding-window sum $y[i]=\sum_{j=0}^{K-1} x[i+j]\,h[j]$ without touching the CPU pipeline. Its internal states (IDLE, INIT OUT, KERNEL LOOP, OUT WRITE, DONE) issue two SRAM reads per tap, feed a $32\times32$ multiplier into a 64-bit accumulator, and write one output sample; the companion dot-product unit shares the same datapath and memory-master interface but with a single vector index. The argument rests on two cycle-count formulas: software costs $T_{\mathrm{SW}}(K)\approx 10K+5$ cycles per output sample (two 3-cycle loads, a 1-cycle multiply, a 1-cycle add, and roughly 2 cycles of loop overhead), while the accelerator costs $T_{\mathrm{DSP}}(K)\approx 3K+1$ (two single-cycle reads and a pipelined MAC). Their ratio for $K=16$, $165/49\approx3.37$, is the concrete payoff the paper uses to claim real-time FIR and 1D-CNN feasibility.

What would settle it

Count cycles on an RTL simulation or FPGA implementation of the described accelerator running the $N=1024$, $K=16$ case at 100 MHz: the paper's model predicts 49,451 cycles for hardware and 166,485 cycles for the RV32IM software loop, so a measured hardware count far from that range would falsify the claimed 3.37x speedup.

Watch

Extended reading notes

Core claim

The paper claims that a small, memory-mapped hardware unit can close most of the performance gap for MAC-heavy edge workloads without changing the RISC-V instruction set. The proposed DSP CONV1D engine uses a five-state FSM (IDLE, INIT OUT, KERNEL LOOP, OUT WRITE, DONE) to stream input and kernel words from the shared SRAM, feed them into a $32\times32$ multiplier with a 64-bit accumulator, and write each output sample back. Each tap takes about 3 cycles, one single-cycle SRAM read for $x$, one for $h$, and a pipelined multiply-accumulate, versus about 10 cycles for the software loop with two loads, a multiply, an add, and loop overhead. With $N=1024$ and $K=16$ the estimated totals are 166,485 cycles in software and 49,451 cycles on the accelerator, a ~3.37x speedup; the dot-product unit reaches a similar ratio for long vectors. The paper further claims that this offload, together with the shorter datapath, reduces convolution energy by roughly 3-5x and that the overall RISC-V implementation shows a 17% power reduction relative to Cortex-M0 implementations in similar process nodes.

Load-bearing premise

The speedup and energy conclusions depend on the per-tap timing model: software at about 10 cycles per tap and the accelerator at about 3 cycles, both assuming single-cycle SRAM and a pipelined MAC, and the paper does not validate these numbers by simulation, synthesis, or measurement.

Editorial extensions

If this is right

For $N=1024$, $K=16$, the accelerator completes the convolution in about 49,451 cycles (about 0.495 ms at 100 MHz), versus 166,485 cycles (about 1.665 ms) for the software loop.
Because both the software and hardware cycle counts grow linearly in $K$, the speedup stays near 3x for longer taps, so larger FIR filters gain roughly the same factor.
A 1D CNN layer with 131,072 MACs would drop from about 13.1 ms to about 3.93 ms at 100 MHz, roughly tripling inference throughput and enabling more inferences per second.
The dot-product accelerator gives about 3.3x speedup for long vectors, which extends the benefit to dense layers and attention-style inner products.
Offloading MAC loops to the accelerators frees the RISC-V core for control tasks, and the paper expects the shorter datapath to cut convolution energy by 3-5x for battery-powered edge devices.

Reading between the lines

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

Beyond the paper: if single-cycle SRAM access is optimistic and memory reads take two cycles, the per-tap hardware cost grows from 3 to 4-5 cycles, and the $N=1024$, $K=16$ speedup would fall toward 2.0-2.5x.
Beyond the paper: fusing the convolution and dot-product units into one multi-channel engine would let a single hardware pass compute a full 1D CNN layer, an architectural extension the paper only gestures at through repeated single-channel calls.
Beyond the paper: the stated 17% power advantage over Cortex-M0 is not tied to a measurement setup; a same-workload, same-process-node silicon or RTL power benchmark would turn it into a checkable claim.

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.

Desk Editor's Note

read the letter

Take this as an undergraduate project report rather than a research paper. The design narrative is coherent: a memory-mapped FSM-driven MAC accelerator for 1D convolution plus a dot-product unit, sharing a single-port SRAM through a priority arbiter, with AXI-Lite control registers. The register maps, FSM states, and bus arbitration are described in enough detail that someone could implement the thing from the text. That is real, and it is the paper's only real asset.

The problems are not subtle. The abstract claims cycle-accurate simulation results and a 17% power reduction versus ARM Cortex-M0. Neither appears anywhere in the body. Section VIII.A says FPGA prototyping and power measurement are future work. The speedup analysis is a back-of-envelope cycle count: 10 cycles per software MAC tap versus 3 for the DSP, giving 3.37x for N=1024, K=16. Those per-tap numbers are assumed, not measured. Worse, the stress-test note is right: the DSP issues two reads per tap from a single-port SRAM, and the FSM description has them in the same 3-cycle iteration. Two reads from one single-port memory cannot both complete in one cycle unless the memory is dual-port or the reads are serialized, which would push the cycle count up. So the 3-cycle model is optimistic on its face, and the 10-cycle software model is likewise asserted. No RTL, no simulation logs, no synthesis, no power numbers.

The introduction promises "orders-of-magnitude" cycle-count reductions, then the actual arithmetic delivers ~3x. That is an inconsistency in framing that should have been caught before submission.

What is genuinely good: the design is simple and sensible for what it is, the paper honestly states that validation is future work (just not in the abstract), and the related-work citations point to the right prior art (PULP, Shakti, Mi-V). There is no circularity; the cycle model is just unvalidated arithmetic.

Who is this for? A graduate student looking for a template of how to describe a memory-mapped accelerator might find it useful. As a paper, it does not deserve a serious referee. The right call is to send it back: remove the unsupported abstract claims, add actual implementation and measurements, or frame it explicitly as a design proposal without empirical claims. If the author ships RTL and measured data, a resubmission would be worth another look.

Referee Report

5 major / 5 minor

Summary. The paper describes a RISC-V system-on-chip design augmented with a 1D convolution accelerator and a dot-product accelerator for edge-computing workloads. It presents the system architecture, memory map, AXI-Lite register interfaces, finite-state machine designs, and an analytical performance model that predicts approximately 3.37x speedup over a software RISC-V convolution loop for N=1024, K=16, and it claims a 17% power reduction compared to ARM Cortex-M0 implementations. The body of the paper contains no RTL, testbench, simulation logs, synthesis results, or power measurements; the claimed speedup rests on assumed cycle counts, and the power-reduction claim is not derived anywhere in the manuscript. Section VIII.A lists FPGA prototyping and power measurement as future work.

Significance. If the quantitative claims were supported, the proposed design would be a modest but useful contribution for edge devices running FIR filtering or 1D CNN layers, and the register maps and FSM descriptions provide a clear blueprint that others could implement. The paper usefully frames the application context and outlines future extensions. However, the central numerical results are unsupported by any simulation or hardware evidence, and the abstract's claim of cycle-accurate simulation and a 17% power reduction is contradicted by the body, which explicitly defers validation to future work. As it stands, the manuscript is more a design proposal than a validated study, and its headline performance and efficiency numbers should not be taken as results.

major comments (5)

[VI.B, Table 4] The central speedup claim of approximately 3.37x depends entirely on the assumed per-tap costs of 10 cycles for software and 3 cycles for the accelerator. These values are asserted, not measured or simulated. No RTL, testbench, simulation output, or synthesis report is provided anywhere in the manuscript, so the model cannot be checked against even a single concrete execution. This is a load-bearing gap: if the true per-tap cost of the accelerator is 4 or 5 cycles, the speedup drops proportionally, and the qualitative conclusions about real-time suitability in Section VII no longer hold.
[IV.B, III.C] The 3-cycle-per-tap model for the accelerator appears inconsistent with the described memory system. The FSM in Section IV.B issues two separate read requests per kernel tap (one for x and one for h), but Section III.A and III.C describe a single-port data SRAM with a priority arbiter. Two reads from a single-port memory cannot both complete in one cycle; the model needs either a dual-port memory, an explicit two-cycle memory schedule, or an analysis of arbitration stalls. Without such a schedule, the 3-cycle-per-tap assumption is optimistic and the resulting 3.37x speedup is not established.
[Abstract, VIII.A] The abstract states that 'Through cycle-accurate simulation of a pipelined implementation, we evaluate performance metrics including CPI and power efficiency' and that 'Comparative analysis shows a 17% reduction in power consumption compared to ARM Cortex-M0 implementations.' Neither claim is supported in the body. There is no simulation methodology, no CPI results, no power model, and no comparison against Cortex-M0 data. Section VIII.A explicitly lists 'Power Measurements' as future work and says concrete benchmarks remain to be run. These statements should be corrected or removed, as they overstate what the paper actually demonstrates.
[VI.F, VIII.A] The energy-efficiency discussion in Section VI.F uses a generic reference (Horowitz, ISSCC 2014) and assumes a 3x-5x energy savings per tap without applying any concrete energy model or measurements to this design. This assumption is then used to claim total convolution energy reduction by a factor of 3x-5x. Because the power and energy numbers are never derived from the actual architecture or validated in hardware, the energy claims in the abstract and Section VI.F are not supported by the evidence presented.
[VII.B] The application-level throughput numbers, such as 'approximately 255 inferences/sec vs. approximately 76 inferences/sec' for a 1D CNN layer, are computed directly from the unvalidated 3-cycle/tap and 10-cycle/tap assumptions. The additional statement that the design can be 'scaled to 200-300 MHz' to meet a 16 kHz real-time requirement has no synthesis basis. These numbers inherit the weakness of the underlying cycle model and should be presented as projections contingent on the assumed costs, not as measured or simulated performance results.

minor comments (5)

[III.A] The block diagram is referenced as 'Figure ??' but no figure appears in the manuscript; either include the figure or remove the reference.
[Throughout] There are numerous typographical and formatting issues, including 'R V32I' instead of 'RV32I', 'DA T AMEM' instead of 'DATA MEM', 'W rite' and 'F ast F ourier T ransform' with stray spaces, and non-ASCII characters such as 'kern idx ¡ K' in Section IV.B. A careful proofreading pass is needed.
[II.C, VIII.E] The reference to the PULP platform is misattributed to GreenWave Systems; PULP is from ETH Zurich and the University of Bologna. This citation should be corrected to avoid misleading readers about the provenance of the referenced work.
[VI.A] The software cycle-count example lists each load as 2-3 cycles and each ALU operation as 1 cycle, then adopts 3 cycles per load without explaining the cache or memory hierarchy of the assumed RISC-V core. The cycle model would be easier to reproduce if the core's memory latency and pipeline details were specified explicitly.
[VIII.E, References] The reference to CMSIS-DSP is given only as a URL; if this is intended as a benchmark suite citation, a version or document identifier would be more appropriate. Several other references (e.g., [5], [6], [7]) lack the bibliographic detail typical of a journal submission.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation found: the speedup is a transparent ratio of assumed cycle counts and the power claim is unsupported rather than self-referential.

full rationale

The performance analysis in Section VI is an explicit analytic estimate, not a fitted or self-referential derivation. The software model assumes 10 cycles per tap (3-cycle loads, 1-cycle multiply, 1-cycle add, 2-cycle loop overhead) and the accelerator model assumes 3 cycles per tap plus 1 cycle per output write, so the reported speedup is simply the quotient (10K+5)/(3K+1) evaluated at N=1024, K=16. There are no fitted parameters, no equation defined in terms of the result it is meant to establish, and no load-bearing self-citation; the derivation would change if the assumptions changed, which means the conclusion is not forced by construction. The abstract's 17% power reduction claim versus ARM Cortex-M0 is not derived anywhere in the paper, and Section VIII.A explicitly lists power measurement and FPGA prototyping as future work; that is an unsupported assertion and a validation gap, not a circular step. Similarly, the phrase 'cycle-accurate simulation' in the abstract is not backed by simulation logs or results in the text, but absence of evidence is a reporting or correctness issue, not circularity. No pattern from the enumerated categories applies to the actual equations, so the honest finding is no significant circularity with score 0.

Assumptions & free parameters 4 free parameters · 4 assumptions · 2 invented entities

The performance and power conclusions rest on four hand-picked timing and energy assumptions: per-tap software cost of 10 cycles, per-tap accelerator cost of 3 cycles, a 10-cycle configuration overhead, and a 3-5x energy efficiency factor relative to software. None are measured, synthesized, or simulated in the paper; they are the free parameters of the analytic model. The two accelerators are invented entities with no independent evidence yet. No extraneous physical constants are introduced.

free parameters (4)

software cycles per MAC tap = 10
Assumed 3-cycle loads/stores, 1-cycle multiply/add, and 2-cycle loop overhead; not measured on any RISC-V core.
DSP cycles per MAC tap = 3
Assumed single-cycle SRAM reads, one-cycle multiply, and pipelined accumulate; not validated by RTL or simulation.
configuration overhead CCFG = 10 cycles
Chosen one-time overhead for writing accelerator control registers; appears in the cycle-count formula in Section VI.B.
energy savings factor = 3-5x
Putative energy-efficiency advantage of hardware MAC over a software loop, borrowed from Horowitz [8]; no measurement is made for this design.

assumptions (4)

domain assumption Each software load/store consumes 3 cycles and each ALU operation consumes 1 cycle on the in-order RISC-V core.
Used to derive TSW(K) = 10K + 5 in Section VI.A; no simulator or benchmark validates these latencies.
domain assumption Data memory is a single-cycle SRAM that can serve one read or write per cycle.
Used in Section VI.B to set the accelerator tap cost to about 3 cycles and the output write to 1 cycle.
domain assumption The MAC datapath is fully pipelined so multiply and accumulate each complete in one cycle.
Assumed in Section VI.B; no synthesis or timing report demonstrates this.
standard math Convolution is defined by y[i] = sum_j x[i+j] h[j] with output length N-K+1.
Equation (1) in Section II.B; this is the standard definition used throughout the analysis.

invented entities (2)

DSP CONV1D accelerator
purpose: Performs 1D convolution in hardware, offloading MAC loops from the RISC-V CPU.
Described only as a register map and FSM; no RTL, simulation, or silicon results are provided, so there is no independent falsifiable handle.
DSP DOT PRODUCT accelerator
purpose: Computes vector inner products in hardware for dense layers and matching operations.
Presented as a design with the same validation gap as the convolution unit; no measurements or implementation artifacts exist.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Design and Implementation of a RISC-V SoC with Custom DSP Accelerators for Edge Computing." pith.science (2026). https://pith.science/paper/2YOLRM3A

@misc{pith2026250606693,
  author       = {Pith},
  title        = {Pith review of: Design and Implementation of a RISC-V SoC with Custom DSP Accelerators for Edge Computing},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/2YOLRM3A}},
  note         = {Machine review of arXiv:2506.06693}
}

read the original abstract

This paper presents a comprehensive analysis of the RISC-V instruction set architecture, focusing on its modular design, implementation challenges, and performance characteristics. We examine the RV32I base instruction set with extensions for multiplication (M) and atomic operations (A). Through cycle-accurate simulation of a pipelined implementation, we evaluate performance metrics including CPI (cycles per instruction) and power efficiency. Our results demonstrate RISC-V's advantages in embedded systems and its scalability for custom accelerators. Comparative analysis shows a 17% reduction in power consumption compared to ARM Cortex-M0 implementations in similar process nodes. The open-standard nature of RISC-V provides significant flexibility for domain-specific optimizations.

Figures

Figures reproduced from arXiv: 2506.06693 by the authors.

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

9 extracted references · 9 canonical work pages

[1]

The RISC-V Instruction Set Manual, Volume I: User-Level ISA,

A. Waterman, K. Asanovi´ c, “The RISC-V Instruction Set Manual, Volume I: User-Level ISA,” RISC- V Foundation, 2014

work page 2014
[2]

Instruction Sets Should Be Free: The Case For RISC-V,

K. Asanovi´ c, D. Patterson, “Instruction Sets Should Be Free: The Case For RISC-V,” Proceedings of the 43rd International Symposium on Computer Architecture (ISCA), 2016

work page 2016
[3]

RISC-V Vector ISA Specification,

Y. Lee et al., “RISC-V Vector ISA Specification,” RISC-V Foundation, 2020

work page 2020
[4]

J. G. Proakis, D. G. Manolakis, Digital Signal Processing: Principles, Algorithms, and Applications, 4th ed., Prentice Hall, 2007. 11

work page 2007
[5]

Mi-V Ecosystem and DSP Modules,

Microsemi Corporation, “Mi-V Ecosystem and DSP Modules,” Whitepaper, 2020

work page 2020
[6]

Shakti Processor Project: Enabling Custom ISA Extensions,

IIT Madras, “Shakti Processor Project: Enabling Custom ISA Extensions,” Technical Report, 2019

work page 2019
[7]

PULP Platform for Ultra-Low-Power Deep Learning,

GreenWave Systems, “PULP Platform for Ultra-Low-Power Deep Learning,” Conference on Embed- ded Systems and Applications, 2021

work page 2021
[8]

1.1 Computing’s Energy Problem (and what we can do about it),

M. Horowitz, “1.1 Computing’s Energy Problem (and what we can do about it),” Proceedings of the IEEE International Solid-State Circuits Conference (ISSCC), 2014

work page 2014

Show all 9 references

[9]

CMSIS-DSP Software Library,

ARM, “CMSIS-DSP Software Library,” https://arm-software.github.io/CMSIS_5/DSP/html/, accessed May 2025. 12

2025

Pith tools

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

[1] [1]

The RISC-V Instruction Set Manual, Volume I: User-Level ISA,

A. Waterman, K. Asanovi´ c, “The RISC-V Instruction Set Manual, Volume I: User-Level ISA,” RISC- V Foundation, 2014

work page 2014

[2] [2]

Instruction Sets Should Be Free: The Case For RISC-V,

K. Asanovi´ c, D. Patterson, “Instruction Sets Should Be Free: The Case For RISC-V,” Proceedings of the 43rd International Symposium on Computer Architecture (ISCA), 2016

work page 2016

[3] [3]

RISC-V Vector ISA Specification,

Y. Lee et al., “RISC-V Vector ISA Specification,” RISC-V Foundation, 2020

work page 2020

[4] [4]

J. G. Proakis, D. G. Manolakis, Digital Signal Processing: Principles, Algorithms, and Applications, 4th ed., Prentice Hall, 2007. 11

work page 2007

[5] [5]

Mi-V Ecosystem and DSP Modules,

Microsemi Corporation, “Mi-V Ecosystem and DSP Modules,” Whitepaper, 2020

work page 2020

[6] [6]

Shakti Processor Project: Enabling Custom ISA Extensions,

IIT Madras, “Shakti Processor Project: Enabling Custom ISA Extensions,” Technical Report, 2019

work page 2019

[7] [7]

PULP Platform for Ultra-Low-Power Deep Learning,

GreenWave Systems, “PULP Platform for Ultra-Low-Power Deep Learning,” Conference on Embed- ded Systems and Applications, 2021

work page 2021

[8] [8]

1.1 Computing’s Energy Problem (and what we can do about it),

M. Horowitz, “1.1 Computing’s Energy Problem (and what we can do about it),” Proceedings of the IEEE International Solid-State Circuits Conference (ISSCC), 2014

work page 2014