Spiking vs. Classical NN on RISC-V

On a small RISC-V core, a spiking network loses on a whole heartbeat but wins over 100× when the ECG arrives one sample at a time.

Three heartbeats from an unseen patient classified by a classical and a spiking neural network. Grey updates every unit on every sample; orange lights up only when the beat looks unusual. The bars show the latency measured on the FPGA board.

30× / 107×
SNN faster on a streamed ECG
software / matched hardware
4.2× / 1.7×
ANN wins on dense input
MNIST image / whole heartbeat
0 mismatches
every board output
bit-exact

Sep–Oct 2026 · Code and full technical report on GitHub →

Why

An ANN neuron multiplies every input by its weight; a spiking neuron adds a weight only when an input spike arrives, leaks, and fires at a threshold
An ANN neuron multiplies every input, every time. A spiking neuron only adds a weight when a spike arrives.

A wearable ECG monitor has a small processor and a battery, and most of what it sees is uneventful: one normal heartbeat looks like the last.

A conventional neural network (ANN) ignores that and does the full computation for every input. A spiking neural network only works when something changes, and then it adds instead of multiplying.

That promise is usually shown on dedicated neuromorphic chips [1]. I wanted to know whether it holds on the kind of small RISC-V core an edge device actually has.

How

Comparison matrix: snapshot and stream input, each in software only and with custom instructions
Two variables, changed one at a time: how the input arrives, and hardware support.

My hypothesis: dense vs. sparse input decides which network wins.

Dense input is new everywhere, like a handwritten MNIST digit [2] or a whole heartbeat handed over at once: the spiking network has to repeat its work over several time steps.

Sparse input is the ECG fed one sample at a time: a normal heartbeat barely differs from the last, so it triggers only a handful of spikes.

So I compared both networks on dense input, and a GRU (a recurrent ANN) against a recurrent spiking network on the streamed ECG, all on the same core. Then, keeping their budgets comparable, I gave each side its own custom instructions.

What

Zynq-7020 system: ARM host in the processing system, PicoRV32 RISC-V core with BRAM and the SNN and MAC custom-instruction units in the programmable logic
The ARM side loads models and reads results; the RISC-V core in the FPGA runs the networks.

Both networks run on a PicoRV32 [3] RISC-V core at 100 MHz in the FPGA of a PYNQ-Z2. Each network gets its own custom instructions: a neuron unit for the spiking network (889 lookup tables) and a multiply-accumulate unit for the ANN (758), each under 2% of the FPGA’s 53,200 lookup tables. The ARM processor on the same chip only loads the models and collects the results. All timing is counted in clock cycles on the RISC-V core itself.

I trained an ANN and a spiking network [4] on MNIST and on the MIT-BIH arrhythmia data [5], quantised both to 8-bit integers and ran them as C firmware on the board. Every output is checked bit for bit against the PC model, and latency is compared sample by sample.

Tools: PyTorch · C · Verilog · Vivado · Python

Workflow: train in PyTorch, quantise to int8, compile RISC-V firmware, run on the board, check every output against the PC model, compare
The loop behind every result: train, quantise, run on the board, check, compare.

Results

In software, the ANN wins on every single input, an MNIST digit or a whole heartbeat. On the sparse stream, the spiking network wins by 30×.

With matched hardware, a small custom unit for each network, the ANN keeps its lead on dense input and the stream result holds: 4.6 ms per heartbeat for the spiking network against 492 ms for the GRU, 107× faster on every beat. Accuracy is comparable within each pair.

A spiking network isn’t faster in general; it’s faster when the signal is quiet.

Latency per input in software (pale bars) and with each network's own custom unit (solid bars): the ANN wins on MNIST images and heartbeats, the recurrent SNN wins on the ECG stream, 30 times in software and 107 times with matched hardware
Pale: software. Solid: each network with its own custom unit. Dense input favours the ANN; stream favours the spiking network, by 30× to 107×.

What I learned

  • Pick the baseline before the winner. Against the muRISCV-NN library, the spiking network looked faster on 9,998 of 10,000 images. Against an equally optimised ANN, it lost on all of them.
  • Count cycles, not operations. 164× fewer operations became only 30× less time. The gap pointed straight at what the hardware had to fix.
  • Hardware can’t fix the workload. A matched multiply-accumulate unit made the GRU 2.2× faster, but it is still 107× slower per heartbeat than the spiking network.

Next steps

  • Event-driven ANN: a GRU that skips unchanged samples, as a stronger streaming baseline.
  • Measured power on the board instead of estimates from cycle counts.

All details, derivations and per-sample results are in the technical report on GitHub.

References

  1. M. Davies et al., “Loihi: A neuromorphic manycore processor with on-chip learning,” IEEE Micro, vol. 38, no. 1, pp. 82–99, 2018.
  2. Y. LeCun, C. Cortes and C. J. C. Burges, “The MNIST database of handwritten digits,” 1998.
  3. C. Wolf, PicoRV32: github.com/YosysHQ/picorv32
  4. J. K. Eshraghian et al., “Training spiking neural networks using lessons from deep learning,” Proceedings of the IEEE, vol. 111, no. 9, pp. 1016–1054, 2023.
  5. G. B. Moody and R. G. Mark, “The impact of the MIT-BIH Arrhythmia Database,” IEEE Engineering in Medicine and Biology Magazine, vol. 20, no. 3, pp. 45–50, 2001.