A clocked system sweeps its entire array every tick, whether or not anything happened. Neuromorphic systems do the opposite: when a neuron fires, it puts its address on a shared bus, and that is the whole message — the timing is implicit in when it arrives. This is Address-Event Representation, and it changes both how you simulate a network and how you route its spikes between chips. It pays off precisely when activity is sparse — and this page shows exactly where that line is.
A clock-driven simulator updates every neuron on every timestep — $O(N)$ work per step even if nothing spikes. An event-driven one keeps a priority queue of pending spike events and only touches the neurons that actually receive input, so its cost is $O(K\log N)$ per spike, where $K$ is the average fan-out. When only a small fraction of neurons are active per step, that is a large constant-factor win; the sparser the network, the more it compounds.
The toolkit's event-driven simulator uses exactly this priority-queue scheduling, and carries spike events as stochastic-bitstream fragments rather than float currents. The broader result it builds on — SparseProp (NeurIPS 2023) — reports very large speedups on million-neuron sparse networks; the figure depends entirely on how sparse the network is, so it is cited as context, not as a number this page reproduces.
To carry spikes between FPGA boards, SC-NeuroCore packs address-events into UDP packets. Each event is eight bytes; up to 186 of them ride in one Ethernet frame under a small header. That framing is the catch: an event here is 64 bits, while a dense clocked bus spends only one bit per neuron per tick. So AER-over-UDP is not universally cheaper — it wins under sparsity and loses when activity is high. The demo makes the crossover concrete.
Below the crossover activity, the address-event stream carries less than a dense frame — only the neurons that fired are transmitted. Above it, the eight-byte-per-event overhead loses to one-bit-per-neuron, and a frame is cheaper. With this UDP framing the crossover sits near a low single-digit percent, which is why it targets genuinely sparse, inter-board traffic. An on-chip AER bus carries just the address — a dozen-odd bits, not 64 — so its crossover sits far higher; the UDP timestamp and payload are the price of a routable, open protocol.
Address-events are the connective tissue of the event-driven stack. The same representation an event camera emits, and a spiking network consumes, is the one this bus routes between chips — so a multi-FPGA system can stay event-driven across board boundaries instead of falling back to dense frames at every hop. It is also, deliberately, an open protocol: there is no widely-shared open standard for multi-FPGA spike routing, so the format above is documented in full.
Evidence boundary: the demo computes the exact AER-over-UDP framing (8-byte header, 8-byte events, 186 per MTU) against a dense one-bit-per-neuron frame in your browser. The event-driven complexity $O(K\log N)$ per spike is the simulator's; the SparseProp speedup is cited as context and depends on network sparsity. No wall-clock throughput is quoted.