Stochastic & Neuromorphic Computing  /  Explore  /  Event vision

Event-camera vision
a pixel that only speaks when it changes

A conventional camera sends a full frame on a fixed clock, whether or not anything moved. A dynamic-vision sensor does the opposite: each pixel fires an asynchronous event the instant its brightness changes — microsecond latency, huge dynamic range, and almost no data when the scene is still. It is spiking vision at the sensor, and it maps straight onto a spiking network. SC-NeuroCore compiles the whole path — sensor to silicon.

The event model

A DVS pixel at $(x,y)$ emits an event the moment its log-intensity moves past a contrast threshold $C$. The event is four numbers — where, when, and which direction — not a pixel value, so a still scene is silent and a moving edge is a sparse stream of micro-timestamped events.

$$e_i = (x_i, y_i, t_i, p_i) \;\;\text{when}\;\; \big|\log I(x,y,t) - \log I(x,y,t_{\text{prev}})\big| \ge C, \qquad p_i\in\{0,1\}$$

The average event rate follows the scene: $R_{\text{events}} = N_{\text{pixels}}\cdot f_{\text{contrast}}\cdot \bar v_{\text{motion}}$ — near zero for a static view, and bursting into the millions or billions per second for fast motion. Handling those bursts without dropping events is the core hardware problem, which the calculator below makes concrete.

Live — will the input FIFO overflow?
required depth entriesaddress width bits · + 32-bit µs timestamp
01  Why events beat frames

Frames waste effort: they re-send unchanged pixels thousands of times a second and blur or miss anything faster than the shutter. Events carry only change, at the moment it happens — so a DVS gives microsecond latency, over 120 dB of dynamic range, and a data rate that collapses to near zero on a static scene. That is exactly the sparse, event-driven regime a spiking network wants.

Deeper: two paradigms, one representation
A DVS event and a neural spike are the same kind of object — an address and a timestamp — so there is no impedance mismatch between the sensor and a spiking network: the camera's ON/OFF events become excitatory/inhibitory inputs directly. This is why event vision is the natural front-end for neuromorphic processing, and why the whole pipeline can stay event-driven from photon to decision, doing work only when the world changes.
02  The pipeline — DVS → AER → neuron

SC-NeuroCore generates the bridge that turns a sensor's Address-Event Representation stream into inputs for a compiled spiking network: an input interface for the sensor's protocol, an event FIFO, an address decoder that maps a pixel to a neuron, and the AER router feeding the network core — all as synthesisable Verilog on the same hardware path as the rest of the toolkit.

DVS sensor
MIPI / SPI
Event FIFO
burst buffer
Address decode
pixel → neuron
AER router
Spiking network
on FPGA
03  FIFO sizing & overflow

Events arrive in bursts far above the average rate, and a dropped event is lost forever. The input FIFO must be deep enough to absorb the worst burst while the pipeline drains it — a one-line design rule that the calculator above evaluates live.

$$D_{\text{FIFO}} \ge R_{\text{burst}}\cdot T_{\text{process}}, \qquad \text{e.g. } 10^{7}\,\tfrac{\text{ev}}{\text{s}} \times 5\,\mu\text{s} = 50 \text{ entries}$$
Deeper: throughput and back-pressure
A single-cycle-per-event decoder at a typical fabric clock sustains on the order of tens of millions of events per second (≈50M ev/s), so the very high peak rates of an HD sensor are handled by burst-buffering to the average, not by processing every peak instantaneously. When a burst would exceed the FIFO, the design either widens the buffer, parallelises the decode, or applies principled back-pressure — and the point of the sizing rule is to make that a deliberate, quantified choice rather than a silent overflow.
04  Addresses & timestamps

Each event carries a pixel address and a microsecond timestamp. The address width is set by the sensor's pixel count — a bit budget the generator picks automatically — and the timestamp is a 32-bit microsecond counter, enough range and resolution for event-vision timing.

ResolutionPixelsAddress widthExample
346×26089,96017 bitsDAVIS 346
640×480307,20019 bitsVGA
1280×720921,60020 bitsHD (Prophesee / Sony)
05  Supported sensors
SensorResolutionMax events/sInterfacePolarity
Prophesee EVK41280×7201.2 GMIPI CSI-2ON/OFF
Sony IMX6361280×720100 MSPI / MIPION/OFF
Samsung DVS-Gen4640×480300 MMIPION/OFF
iniVation DAVIS 346346×26012 MUSB3 / SPION/OFF
CelePixel CeleX-V1280×800500 MMIPION only
Where it fits

Sensor specifications are from published datasheets; the FIFO calculator applies the design rule above and is illustrative of sizing, not a substitute for timing closure. Trademarks belong to their respective owners.