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.
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.
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.
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.
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.
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.
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.
| Resolution | Pixels | Address width | Example |
|---|---|---|---|
| 346×260 | 89,960 | 17 bits | DAVIS 346 |
| 640×480 | 307,200 | 19 bits | VGA |
| 1280×720 | 921,600 | 20 bits | HD (Prophesee / Sony) |
| Sensor | Resolution | Max events/s | Interface | Polarity |
|---|---|---|---|---|
| Prophesee EVK4 | 1280×720 | 1.2 G | MIPI CSI-2 | ON/OFF |
| Sony IMX636 | 1280×720 | 100 M | SPI / MIPI | ON/OFF |
| Samsung DVS-Gen4 | 640×480 | 300 M | MIPI | ON/OFF |
| iniVation DAVIS 346 | 346×260 | 12 M | USB3 / SPI | ON/OFF |
| CelePixel CeleX-V | 1280×800 | 500 M | MIPI | ON only |
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.