Working definition
Event-driven computation represents and processes changes as asynchronous messages. Potential efficiency comes from sparsity and locality, but only when event generation, routing, synchronization, idle power, host processing, and data movement are included in the accounting. Event-driven operation is an architectural property, not an automatic proof of low energy or low latency.
Mechanism
- Detect or generate a state-changing event.
- Route it to subscribed processing elements.
- Update only affected state under timing guarantees.
Measurements
- Event rate
- End-to-end latency
- Active and idle energy
Reproducibility controls
- Version hardware, software, firmware, and analysis code.
- Declare dataset, preprocessing, random seeds, and measurement boundary.
- Report repeated runs, variation, exclusions, and failed trials.
Limits and failure modes
- Dense workloads can erase sparsity benefits.
- Host and interface costs may dominate.
Mathematical connection
Formal structure without substrate erasure
Event-routing graph
Model processing elements and asynchronous communication as typed nodes and edges.
Inputs
- Processing nodes
- Routing edges
- Event traffic
Outputs
- Reachability
- Congestion estimates
- Failure paths
Limit: Graph structure omits physical timing, power, queue behavior, and implementation overhead unless those are separately measured.
Technical and governance sources
- [1]Taking Neuromorphic Computing to the Next Level with Loihi 2 · Intel Labs
Establishes: An official description of the Loihi 2 research chip, its programmable neuron models, event-based communication, on-chip learning support, and the Lava software framework used to construct neuromorphic applications.
Boundary: This is a vendor technical brief about a research platform. Performance and efficiency results remain workload-, configuration-, measurement-boundary-, and comparison-dependent and do not establish equivalence to biological intelligence.
- [2]SpiNNaker2 Developer Portal and Hardware Documentation · SpiNNcloud Systems and SpiNNaker2 community
Establishes: Maintained technical documentation for a many-core, event-based neuromorphic platform, including chip topology, processing elements, communication, software interfaces, and supported computational workloads.
Boundary: Architecture documentation establishes available mechanisms, not universal speed, energy, learning, biological plausibility, or production readiness. Claims require a named board, software version, workload, and system boundary.
- [3]NeuroBench: Advancing Neuromorphic Computing Through Collaborative, Fair and Representative Benchmarking · National Institute of Standards and Technology
Establishes: A community framework separating algorithm and system tracks and defining task, correctness, efficiency, and reporting procedures intended to make neuromorphic results more comparable and reproducible.
Boundary: A benchmark ranks submitted systems on declared tasks and metrics. It does not prove general intelligence, biological equivalence, safety, usefulness outside the benchmark, or superiority under unreported host and data costs.