SpiNNaker

Overview

SpiNNaker is a massively parallel computer built from a very large number of small, low-power processor cores. Its purpose is to simulate spiking neural networks in real time, with each core handling a slice of the network and a fast packet network carrying spikes between cores. The name comes from Spiking Neural Network Architecture. It was designed at a university in the United Kingdom as part of a long research effort to understand and model the brain.

Unlike chips that hard-wire a neuron model into circuits, SpiNNaker runs neuron models as ordinary software on general-purpose cores. That makes it flexible: new neuron types, learning rules and network shapes can be tried without building new silicon. The price is lower energy efficiency than a fixed circuit would give. For tabular work, SpiNNaker matters as a research platform for sparse, event-driven computation, and as a design that shows how to scale communication, not as a place to run tabular foundation models. See spiking neural networks for the model class that it simulates.

What it is

SpiNNaker is a family of many-core machines. The first generation put several processor cores on each chip. Chips were placed on boards, boards in frames, and frames in cabinets, until a machine held about a million cores. A second generation redesigned the chip with more cores, newer processors and hardware accelerators.

The first-generation chip

Each chip includes:

• A group of small ARM processor cores, eighteen in the first generation. One is reserved for monitoring, and the rest run neuron code.
• A memory shared across the chip, used to store synaptic data.
• A small local memory per core for code and neuron state.
• A multicast router that sends spike packets to the right places.
• Links to six neighboring chips, forming a mesh.

Analogy: a huge post office with a million clerks. Each clerk has a small desk and handles the mail for a few neurons. A smart sorting machine copies each letter and sends it to every clerk who needs it, without involving the sender.

The machine

The million-core machine was completed in 2018 at the host university, and it has been offered to researchers through an online service. Smaller boards exist for teaching and for labs that want a desktop system.

What it is not

• It is not a fixed-function neuron chip. It runs software for neurons.
• It is not analog. Everything is digital.
• It is not guaranteed to be bit-exact against a standard simulator, since packet delivery and timing differ in detail.
• It is not designed for dense matrix training of deep networks.

Where it came from

The project grew out of a long interest in computer architecture inspired by the brain. The key architectural idea was that the brain is a vast network of simple units that communicate by small events, so a computer for brain simulation should be built for cheap, fast, broadcast-style messages and not for heavy arithmetic.

Milestones in the story:

• Early design work in the 2000s proposed a chip with many low-power cores and a packet router tuned for spikes.
• Prototype chips were fabricated and tested, then assembled into boards of increasing size.
• The project became a core platform of a large European brain research initiative, which funded its scaling up and its software.
• The million-core machine was switched on in 2018.
• A second-generation chip, SpiNNaker2, was developed in collaboration with a German university. It uses a newer manufacturing process, many more processor cores per chip and dedicated hardware blocks for common operations.

On the software side, the platform adopted PyNN, a common Python interface for describing spiking networks that works across simulators and hardware. The SpiNNaker implementation of this interface is called sPyNNaker. It lets a researcher write a network once and run it on a laptop simulator or on the machine.

Related efforts include IBM TrueNorth, Intel Loihi and BrainScaleS. For the broader research view, see /model/research.

How it works

Step 1: describe the network

The user writes a network in Python through a PyNN-style interface. The description lists populations of neurons, the neuron model for each, the projections (groups of synapses) between populations and the input sources.

Analogy: a seating plan for a wedding. It says who sits where and who talks to whom, but not yet which waiter serves which table.

Step 2: split and place

A mapping tool divides each population into chunks small enough for one core, typically a few hundred neurons or fewer. It assigns the chunks to cores across the machine and tries to keep strongly connected chunks near each other.

Step 3: build routing tables

The tool computes, for each source chunk, the set of target chunks, and writes routing entries into the routers. Because the router uses multicast, one spike from a source is copied at branching points in the mesh and delivered to all targets. The sender only emits one packet.

Step 4: load and run

Data and code are loaded to the cores. Each core runs a simple loop based on a timer interrupt. A common setting is a time step of one millisecond to keep the simulation in step with real time.

In every time step, a core:

1. Receives spike packets that arrived since the last step. Each packet carries a key that identifies the source neuron.
2. Looks up the key to find the matching row of synaptic data in memory.
3. Fetches that row and adds the synaptic weights to the inputs of the target neurons.
4. Updates the state of each of its neurons using the chosen neuron model.
5. Sends a packet for each neuron that fired.

The fetch step is the heavy one. Spike rates are low in most models, so a core only needs to fetch a few rows per step, which is why general-purpose cores can keep up.

Step 5: record and read results

Spikes and variables are recorded in memory and read by the host after or during the run. For interactive use, spikes can be streamed to the host or to a connected device in real time.

Communication details

Spikes are sent as short packets in an address-event style. The packet holds the identity of the firing neuron and little else. The router checks the identity against a table and decides which of the six links, and which local cores, should receive a copy. The design favors speed and low cost over strict guarantees. If a link is congested, a packet may be dropped. Spiking networks are generally tolerant of an occasional lost spike, similar to how a crowd keeps its meaning if a few words are missed.

Why a software approach

• New neuron models only need new code.
• Plasticity rules, such as spike-timing-dependent learning, can be added as code too.
• Experimenting is fast, since there is no new silicon.
• The same hardware can run other event-based algorithms, not only neurons.

Memory layout in more detail

Memory is the scarce resource on a small core. A typical split looks like this:

• Instruction memory: the neuron code and the runtime, small and fixed.
• Data memory: the state of each neuron, such as voltage and input current, plus buffers for incoming spikes.
• Shared memory: the large store of synaptic rows. Cores fetch rows from it only when a matching spike arrives.

Analogy: a clerk keeps a small notebook on the desk with the current mood of each customer, and walks to a big shared filing room only when a letter arrives that needs a customer file. The walk is the expensive part, so the design tries to do it rarely and in large, efficient steps.

Delays and buffers

Synapses can have delays of a few milliseconds. The core keeps a ring buffer for each neuron, with one slot per delay value. An arriving weight is added to the slot that matches its delay, and each time step the core reads the current slot and moves on. A longer maximum delay needs a bigger buffer, so it reduces the number of neurons that fit on a core.

The monitor processor and the host

One core on each chip acts as a monitor. It handles loading, error reports and communication with the host through Ethernet-connected chips. The host is a normal computer. It builds the mapping, loads the machine, starts the run, and reads back recordings. Think of the host as the project manager and the machine as the factory floor.

Typical applications

• Cortical microcircuit models that reproduce firing statistics seen in the brain.
• Closed-loop control of robots using spike-based vision sensors.
• Cognitive models such as associative memory or simple decision networks.
• Large-scale models with millions of neurons that run at biological speed.
• Teaching, where small boards let students watch spiking networks run.
• Exploration of new learning rules, since the rule is only code.

Key concepts and terms

A worked example

We will build a small network in the PyNN style: a population of source neurons that fires at a steady rate, connected to a population of leaky integrate-and-fire neurons. Then we will work out by hand what one core does in one time step. The code is a sketch that follows the common PyNN pattern. Module names differ between releases, so check the current documentation before running anything.

Network description

import pyNN.spiNNaker as sim

sim.setup(timestep=1.0)

# 100 Poisson sources firing at about 20 spikes per second
sources = sim.Population(100, sim.SpikeSourcePoisson(rate=20.0), label="input")

# 50 leaky integrate-and-fire neurons
neurons = sim.Population(50, sim.IF_curr_exp(), label="cells")
neurons.record(["spikes", "v"])

# each source connects to each neuron with probability 0.2
conn = sim.FixedProbabilityConnector(p_connect=0.2)
sim.Projection(sources, neurons, conn,
               synapse_type=sim.StaticSynapse(weight=0.5, delay=1.0))

sim.run(1000)   # one second of model time
data = neurons.get_data()
sim.end()

If you replace the first import with the module for a software simulator, the same description runs on a laptop. This is one of the main strengths of the PyNN approach.

What a core does in one step

Assume one core holds 50 target neurons, and 100 sources are each connected to about 20 percent of them. That means each source has about 10 targets on this core.

• Source rate: 20 spikes per second per source. With 100 sources, the expected input is 2,000 spikes per second, or 2 spikes per millisecond.
• In one 1 ms step, the core receives about 2 packets on average.
• For each packet, it fetches a synaptic row of about 10 weights and adds them to 10 neuron inputs.
• That is roughly 20 additions per step for the whole input, plus 50 neuron updates.

The amount of work is tiny, and a small core handles it easily. Scale the same pattern to a million neurons spread across thousands of cores and the per-core work remains small, which is why the architecture scales.

Checking real-time headroom

A useful rule is to compute how many synaptic events a core must process per step at the worst case. If a core receives 200 packets with 100 targets each in one step, it must do 20,000 additions plus neuron updates inside the 1 ms budget. If that exceeds what the core can do, the options are to reduce neurons per core, to spread the network across more cores, or to slow down the simulation clock so that the machine runs slower than real time. Many users accept a slowdown when exploring large models.

A tiny plasticity idea

With a spike-timing rule, each synapse changes by a small amount depending on the time difference between pre- and post-synaptic spikes. In code form, for one synapse:

def stdp_update(w, dt, a_plus=0.01, a_minus=0.012, tau=20.0, w_max=1.0):
    # dt = t_post - t_pre in ms
    import math
    if dt > 0:
        w += a_plus * math.exp(-dt / tau)    # pre before post: strengthen
    else:
        w -= a_minus * math.exp(dt / tau)    # post before pre: weaken
    return min(max(w, 0.0), w_max)

print(stdp_update(0.5, 5.0))     # slightly above 0.5
print(stdp_update(0.5, -5.0))    # slightly below 0.5

On SpiNNaker, the equivalent runs as software on the cores, with the timing information stored next to the synaptic rows.

Worked arithmetic: how many cores?

A quick estimate helps before you submit a job.

Suppose a model has 200,000 neurons and each neuron has about 100 incoming synapses.

1. Choose 250 neurons per core to leave time headroom.
2. Cores needed: 200,000 divided by 250 equals 800 cores.
3. Synapses: 200,000 times 100 equals 20 million, stored in shared memory. At a few bytes per synapse, that is tens of megabytes, which spreads over the chips that hold those 800 cores.
4. One chip has a few dozen worker cores, so about 40 to 50 chips are needed.
5. A single board of dozens of chips is close, and the job might need two boards.

If the firing rate is 10 spikes per second, each core receives a stream of spikes from the sources of its neurons. With 100 inputs per neuron at 10 spikes per second, one neuron receives 1,000 input events per second, which is 1 per millisecond. A core with 250 neurons processes about 250 synaptic events per step. That is comfortable. At 100 spikes per second, it becomes 2,500 events per step, and the core may overrun.

Slowing the clock

If a model is too heavy for real time, the simulation can run with a time scale factor. A factor of 10 means one millisecond of model time takes ten milliseconds of wall time. The results are the same, but the run is slower than real time. For offline research this is fine. For robots in the loop, it is not.

Strengths and limitations

Strengths

• Flexible: any neuron model or learning rule that can be written as code can be tried.
• Real-time simulation of large spiking networks, up to the scale of a million cores.
• Scalable communication through multicast routing and a mesh of links.
• Standard Python interface via PyNN, which eases moving between simulators and hardware.
• Lower power than a conventional cluster for the same spiking simulation.
• Good for closed-loop experiments with robots or sensors, since it runs in real time.
• Open research service that gives remote access to a large machine.

Limitations

• Less energy-efficient than fixed-circuit neuromorphic chips, since general-purpose cores carry overhead.
• Packet loss and timing effects mean results may differ slightly from an ideal simulator.
• Memory per core is limited, which restricts synaptic data and neuron count per core.
• Not suited to dense deep learning training.
• The first-generation chip uses an older manufacturing process, and the machine has a large physical footprint.
• Mapping large networks needs care to avoid hot spots in the routing network.
• Some model features in PyNN may be missing or restricted.

Performance rules of thumb

• Fewer neurons per core gives more headroom per time step.
• High firing rates and dense connectivity make the fetch step the bottleneck.
• Keeping connected populations close in the mesh reduces traffic.
• Long synaptic delays use extra memory buffers.

Second generation in brief

The second-generation chip keeps the idea of many small cores and a fast packet network but changes the details.

• More processor cores per chip, with modern low-power designs.
• A newer manufacturing process that reduces power per operation.
• Hardware accelerators for neuron math, random number generation and multiply-accumulate operations.
• Dynamic voltage and frequency control per core, so idle cores save power.
• A network-on-chip with more bandwidth and a path to bigger systems.

These changes make it easier to run both spiking and non-spiking workloads, such as small conventional neural networks, on the same hardware. That mix is useful for hybrid pipelines that combine event-driven and dense stages.

How it compares with alternatives

When to choose SpiNNaker

• You want to test new neuron or plasticity models quickly.
• You need real-time operation with a robot or sensor.
• You simulate large networks with sparse activity.
• You value a common interface to move between laptop and machine.

When to choose something else

• For fixed, very low power inference, a fixed-circuit chip fits better.
• For dense training, use a GPU and a library such as PyTorch with a spiking extension like snnTorch or SpikingJelly.
• For accelerated emulation that runs faster than biological time, analog systems such as BrainScaleS are the specialists.

Role in tabular foundation models

Tabular foundation models learn from raw tables with rows, columns, mixed types and missing cells. They are pre-trained on large collections of synthetic or real tables and then used with in-context learning, where the training rows of a new table are supplied as context and the model predicts without weight updates. See /model/architecture, TabPFN and TabICL.

SpiNNaker does not run these models. Attention over rows and columns is a dense computation, and SpiNNaker is built for sparse spike traffic. The honest link is through shared ideas and through research on sparse, event-driven systems.

Shared ideas

• Sparsity: tables with many zeros and missing cells are sparse. SpiNNaker's design shows how to exploit sparsity by moving only the events that matter.
• Multicast communication: in-context prediction compares a query row with many stored rows. A multicast network is a natural way to broadcast a query to many memories at once. This is a conceptual parallel only.
• Many small workers: SpiNNaker splits a problem across many tiny cores. Tabular systems also split work across rows, columns and ensemble members. See data parallelism and tensor parallelism for the dense counterpart.
• Software-defined flexibility: a software neuron model is similar in spirit to a model whose behavior is set by its context, as in a foundation model that reads training rows at run time.

Possible uses with table-like data

• Streaming simulation of sensor tables: SpiNNaker can run a real-time spiking model over event streams derived from machine telemetry.
• Anomaly detection research: spiking networks that learn normal patterns and flag deviations can be explored at scale. This relates to anomaly detection methods such as isolation forest and reconstruction-based detectors.
• Continual learning: because plasticity is software, experiments on forgetting and stability are easy to set up. This complements dense methods like elastic weight consolidation and experience replay.
• Imputation research: a recurrent spiking network can complete partial patterns, the way an associative memory fills in missing parts. This is a research direction and relates conceptually to imputation networks.

Encoding a table for a spiking simulator

Because SpiNNaker simulates in real time, a long table must be presented over time. A thousand rows at a 100 ms presentation window take 100 seconds. That cost is acceptable for demonstrations and slow for batch scoring, which is another reason this platform is not a scoring engine for tables.

A hybrid pipeline idea

A realistic way to combine the two worlds is a split pipeline:

1. A dense tabular model, run on a GPU, produces compact features or scores for each batch of rows.
2. The scores are converted into events for a spiking network on an event-driven platform.
3. The spiking network tracks them over time, detects bursts or drifts, and raises alerts.
4. Alerts and selected rows are sent back to the dense model for a deeper look.

This keeps each part where it works best. The dense model handles in-context prediction over rows and columns. The event-driven part handles long, quiet streams cheaply. It is a design sketch for research, not an established product pattern.

Questions to ask before trying it

• Is the data stream long, sparse and continuous?
• Does the alert need to be fast, and does it need to run on a small power budget?
• Can the key signal be summarized in a few numbers per row?
• Is there a clear baseline, such as a simple threshold rule, to compare against?

If the baseline is already good, the extra platform may not be worth it.

Pre-training, synthetic tables and semantic tasks

Pre-training a tabular foundation model on synthetic tables is a large dense-compute job. SpiNNaker is not a fit for it. Sector or semantic classification of tables needs language-capable components that are far larger than what the platform is designed for. A spiking research system could be tested on small, derived features, but this is exploratory.

Honest summary of the link

• SpiNNaker and tabular foundation models differ in workload, scale and purpose.
• The common thread is the value of sparse, event-based computation and flexible software control.
• Direct claims of running tabular foundation models on this hardware should be treated with caution.

See /model/benchmarks for how tabular models are measured on typical tasks.

Practical guidance and best practices

Start on a laptop

• Build and debug the network with a software simulator using the same PyNN description.
• Check that firing rates look reasonable before porting.
• Keep network sizes small at first.

Respect the time budget

• Estimate synaptic events per step for the busiest core.
• Reduce neurons per core if the step overruns.
• Consider a time scale factor that slows the run, if real time is not needed.

Plan the data

• Normalize numeric inputs before turning them into rates.
• Reserve an input group for missing flags.
• Keep presentation windows long enough for rates to be meaningful, but short enough for the run to finish.

Handle recording carefully

• Recording many variables fills memory and slows the run.
• Record spikes for most neurons, and record voltages only for a few.
• Read results in chunks for long runs.

Validate against a reference

• Compare spike counts and rates with a software simulator.
• Expect small differences, and decide what level of difference is acceptable.
• Test with several seeds.

Use the right scale

• Use the small boards for development and the large machine for scale runs.
• Check how many chips you need from the network size and the connectivity.

Document everything

• Save the network description, the seed, the mapping options and the software version with the results.
• Record the real-time status of the run, so that readers know if timing was met.

Troubleshooting guide

A short checklist before a large run

1. The same network works on a software simulator.
2. Rates look plausible, and the network is neither silent nor saturated.
3. The number of neurons per core is set with headroom.
4. Recordings are limited to what is needed.
5. The software version, seed and mapping options are saved.
6. A smaller version has already run on a small board.

Common mistakes

• Expecting dense deep learning performance from a spike simulator.
• Leaving too many neurons on each core and missing the time step.
• Recording every variable of every neuron.
• Assuming spikes are always delivered, and not checking for dropped packets.
• Skipping normalization of inputs.
• Treating silence as a zero for missing data.
• Forgetting that real-time operation means a long table takes long to present.
• Mapping everything without considering network locality, which creates routing hot spots.
• Comparing energy with a GPU without matching task and accuracy.
• Using features of PyNN that the hardware backend does not support, without checking.

Frequently asked questions

What is SpiNNaker?

SpiNNaker is a many-core computer designed to simulate spiking neural networks in real time. It uses a large number of small, low-power processor cores connected by a fast packet network that handles spike messages. It was developed at a university in the United Kingdom as a platform for brain research.

What does the name SpiNNaker stand for?

It stands for Spiking Neural Network Architecture. The name describes the aim of the project, which is to build a computer architecture suited to simulating networks of spiking neurons.

How many cores does SpiNNaker have?

The largest first-generation machine has about a million cores. Each chip holds eighteen small ARM cores, and the machine groups chips into boards, frames and cabinets. The second-generation chip packs many more cores per chip, so future machines can be larger or smaller for the same capacity.

How is SpiNNaker programmed?

Users usually describe a network in Python with the PyNN interface, through the SpiNNaker implementation called sPyNNaker. The tools then split the network into chunks, place them on cores, and build routing tables. The same description can often run on a software simulator.

Is SpiNNaker faster than a normal computer?

It is not faster at general computing. It is designed to run large spiking networks in real time with low power per core, which would need a bigger and hungrier cluster to match. For dense math or training deep networks, a GPU is far better.

What is multicast routing?

Multicast routing means that a single packet from a sender is copied by the network and delivered to many receivers. In SpiNNaker, a spike packet leaves one core, and the routers copy it where needed. This saves traffic and makes the system scale to many connections.

What is SpiNNaker2?

SpiNNaker2 is the second-generation chip and system. It uses a newer manufacturing process, many more processor cores per chip and hardware accelerators for common operations such as exponentials, random numbers and multiply-accumulate. It aims at better energy efficiency and also at supporting mixed workloads that combine spiking and conventional neural networks.

Can SpiNNaker handle tabular data?

It can process table-like data if rows or sensor streams are converted into spikes, for example with rates or events. It is a research platform for sparse, event-driven models, not a scoring engine for tabular foundation models, which use dense attention.

How does SpiNNaker differ from Loihi and TrueNorth?

SpiNNaker implements neurons in software on general-purpose cores, which gives flexibility. Loihi and TrueNorth implement neurons in digital circuits, which gives better energy efficiency but less freedom. Loihi adds on-chip learning, and TrueNorth is inference-only.

Is access to SpiNNaker open?

The large machine has been made available to researchers through an online service for projects approved by the host team, and smaller boards have been sold or loaned for research and teaching. Check the current terms from the project before planning work.

Glossary

• Address-event representation: A scheme that communicates events by sending the address of the source.
• ARM core: A small, low-power processor design used in each SpiNNaker core.
• Dropped packet: A spike packet lost because of congestion.
• Many-core: A processor design with a large number of small cores.
• Multicast: Delivering one message to many recipients through network-level copying.
• Neuron model: The equation or code that updates a neuron state.
• Plasticity: Change of synaptic strength through activity.
• Population: A group of neurons that share a model and parameters.
• Projection: A set of synapses connecting two populations.
• PyNN: A Python interface for describing spiking network models.
• Real time: Running a simulation at the same speed as the system it models.
• Router: The hardware that forwards spike packets.
• Spike: A short event sent from a neuron to others.
• sPyNNaker: The software that maps PyNN descriptions to SpiNNaker hardware.
• Synaptic row: The stored list of weights for connections leaving one source neuron.
• Time step: One cycle of neuron updates, often one millisecond.

Summary

SpiNNaker is a many-core, packet-switched computer for simulating spiking neural networks in real time. It trades some energy efficiency for great flexibility by running neuron models as software, and it scales through multicast routing across a mesh of chips. It offers a PyNN-based workflow that moves between laptop simulation and large hardware.

For tabular foundation models, it is a research cousin rather than a deployment target. Tables can be converted into spikes for streaming, anomaly and plasticity experiments, but dense attention over rows and columns belongs on GPU-class hardware. Continue with Intel Loihi, IBM TrueNorth, BrainScaleS and /model/architecture.

Related

It belongs to Neuromorphic in my stack, under AI and machine learning. Others in the same group: