A conventional camera captures the world the same way, tens of times a second: it reads out every single pixel, whether that pixel changed or not. Point it at a static scene and it will still dutifully re-transmit millions of identical values, frame after frame. For most everyday photography that’s fine. For a system that has to react to motion in microseconds; a robot arm, an autonomous vehicle, an industrial inspection line, it’s an enormous amount of wasted bandwidth and wasted latency.

Event-based vision starts from a different question: instead of asking “what does the whole scene look like right now?”, it asks “which pixels just changed?” That shift in perspective is what neuromorphic sensors are built around, and it turns out to pair naturally with a very specific kind of compute fabric: the FPGA.

What Event-Based Vision Actually is

A Dynamic Vision Sensor (DVS), the class of sensor behind cameras like Prophesee’s EVK4, doesn’t expose fixed frames at all. Every pixel operates independently and asynchronously: it only fires when it detects a brightness change above a threshold, emitting a compact “event” (pixel address, polarity, timestamp) rather than a full-frame readout. No motion, no output.

The practical datasheet numbers are striking. The EVK4 (built on the Sony IMX636 sensor, which we have used previously) delivers sub-100µs pixel-level latency, a dynamic range beyond 86dB standard (over 120dB in low-light-optimized mode, functioning down to roughly 0.08 lux), and an equivalent temporal resolution north of 10,000 fps; all while transmitting only the pixels that actually changed. That combination of speed, dynamic range and inherent data-sparsity is why event-based sensors keep showing up wherever frame-based cameras hit a wall: high-speed tracking, low-light operation, and scenes with extreme contrast.

Why This Maps Onto Neuromorphic Computing

Event-based data isn’t just sparse, it’s ‘inherently spike-like’: a stream of discrete, timestamped, asynchronous signals. That’s precisely the input format a Spiking Neural Network (SNN) was designed for. Where a conventional neural network processes dense tensors on a clock tick, a spiking neuron accumulates input over time and only fires, only does work, when it crosses a threshold. Feed an SNN with frame-based, densely-sampled data and you’re fighting its nature. Feed it directly with a native event stream, and the two paradigms line up almost perfectly: no data where nothing happened, no computation where nothing happened.

Why FPGA, and not GPU

This is the part that’s easy to underestimate until you’ve actually tried to build it: GPUs are extraordinarily good at dense, batched, frame-oriented workloads, and structurally mismatched with sparse, asynchronous, per-event processing. Batching events to make a GPU efficient reintroduces the very latency the sensor was designed to eliminate.

An FPGA doesn’t have that conflict. It gives you deterministic, clock-accurate timing, massive fine-grained parallelism, and critically the freedom to build a custom dataflow pipeline shaped exactly around the event stream instead of around a general-purpose instruction set. This is also an active research direction outside of RunX: recent work on FPGA-based spiking neural network accelerators explores exactly this, asynchronous, event-triggered SNN inference directly in programmable logic. The architecture argument isn’t just a RunX opinion; it’s where the field is heading.

Where this shows up in the real world

Robotics and drones that need to react to obstacles in microseconds, not milliseconds. High-speed industrial inspection, where a defect passes the sensor for a fraction of a frame’s worth of time. Automotive perception in extreme lighting transitions, tunnel exits, oncoming headlights at night. AR/VR systems tracking fast head or hand motion without motion blur. In every one of these, the bottleneck isn’t the ML model, it’s getting the right data to it fast enough, without paying for the 99% of the frame that didn’t change.

How we approached this in one of RunX’s projects

In one of RunX’s projects, we built exactly this pipeline end to end: a high-speed event stream from an event-based camera, ingested and processed on a Xilinx ZCU102 (Zynq UltraScale+ MPSoC), feeding a spiking neural network implemented as a hardware IP core in the programmable logic.

Event data came in on the Processing System (PS) side and was moved via AXI DMA into the Programmable Logic (PL), where the SNN IP core ran inference directly on the incoming event stream. The camera streamed up to 10,000 events per second, all of which had to be processed sequentially without dropping data, exactly the kind of per-sample, timing-critical workload that belongs in the PL rather than on the ARM cores. From there, results were pushed out over a 10G UDP design and 10G Ethernet IP, while the PS handled a separate 1G Ethernet path for control and monitoring.

Not every RunX FPGA project routes sensor data through the PS first, some designs feed the sensor directly into the PL instead, depending on the interface and the timing budget. What carries over between projects is less a fixed architecture and more a rule of thumb: if a task needs a timing guarantee or has to run on a per-sample basis, it belongs in the PL; if it makes decisions or talks to the outside world, it stays on the PS and the PS and PL talk to each other over the same kind of AXI-based communication pattern regardless of which side the data starts on.

Continue the Series

If you want to go further into how we design the PS/PL data path for high-bandwidth sensor pipelines; the AXI interface choices, DMA design, why Linux runs on the PS side, we’ve already written about that in detail: PS/PL Architecture in FPGA SoC Devices. And if you’re weighing hardware options for your own edge AI deployment, our piece on Edge AI on FPGAs: Hardware Selection and Deployment Strategies is a good next stop.

If you’re working on an event-based sensing or neuromorphic computing problem and want to talk through the architecture, we’d love to hear from you.

Talk to us: info@run-x.com | [www.run-x.com]