Computational models

Event-driven computation

Perform work when informative events occur rather than updating every component on a fixed global schedule.

digital siliconestablished research

Evidence status

Checked against 1 inspected source

One source was retrieved, identified and read, and the claims below are tied to specific passages at the scope those passages state. Each source also records what it cannot establish.

Rely on this page for

The specific claims that carry a cited passage, at the scope that passage states.

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

computational modelGraph theory →

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.

Related concepts

digital-silicon

Neuromorphic computing

mixed-signal-silicon

Neuromorphic sensors

hybrid

Hardware-software co-design

Direct answer

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 and method

Detect or generate a state-changing event.
Route it to subscribed processing elements.
Update only affected state under timing guarantees.

What is measured

Event rate
End-to-end latency
Active and idle energy

Limitations

Dense workloads can erase sparsity benefits.
Host and interface costs may dominate.

Boundaries declared by the cited sources

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. (boundary declared by Taking Neuromorphic Computing to the Next Level with Loihi 2)
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. (boundary declared by SpiNNaker2 Developer Portal and Hardware Documentation)
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. (boundary declared by NeuroBench: Advancing Neuromorphic Computing Through Collaborative, Fair and Representative Benchmarking)
A cross-platform benchmark study. It validates no vendor efficiency claim, declares no platform universally superior, and sets no absolute efficiency threshold, since its results depend on workload and configuration. It cannot support a general claim that neuromorphic hardware is more efficient than conventional hardware. (boundary declared by Benchmarking Neuromorphic Hardware and Its Energy Expenditure)

Bridge: Event-routing graph

Model processing elements and asynchronous communication as typed nodes and edges.
Input: Processing nodes
Input: Routing edges
Input: Event traffic
Output: Reachability
Output: Congestion estimates
Output: Failure paths
Limit: Graph structure omits physical timing, power, queue behavior, and implementation overhead unless those are separately measured.