Lava

Overview

Lava is an open-source software framework for building neuromorphic applications. It lets you describe a program as a set of small, independent processes that talk to each other by sending messages. The same program can run on an ordinary CPU for development and, with the right backend, on neuromorphic chips such as Loihi. The core idea is that you write the logic once and choose the hardware later.

Lava matters because neuromorphic hardware does not work like a normal computer. It has no global clock stepping through one long instruction list. Many small units hold state, wait for events and react only when something arrives. Lava gives developers a Python-first way to think in that style. It sits beside deep learning libraries such as PyTorch and spiking libraries such as snnTorch, but it solves a different problem: how to structure, simulate and deploy event-based programs, not only how to train a network.

What it is

Lava is a layered software stack. At its heart is a small core library that defines a few building blocks. Around it sit optional libraries for deep learning, optimization and neural fields.

The core abstractions

A Lava program is built from four ideas.

• Process. The basic unit. A process has internal variables, input ports and output ports. It does not say how it computes. It only says what state it holds and how it connects.
• ProcessModel. The code that gives a process its behavior. One process can have several models, for example one written in Python for a CPU and another for a specific chip.
• Port. A channel for passing messages. Output ports connect to input ports, and the messages are events, not continuous streams.
• Runtime. The engine that compiles a set of connected processes, picks a model for each, and runs them for a number of time steps.

Think of a process as a worker at a desk. The desk has a notebook for private notes (variables), an inbox (input ports) and an outbox (output ports). The job description (ProcessModel) tells the worker what to do when mail arrives. The Runtime is the office manager who hires workers, picks which job description each one follows and keeps the office on schedule.

The wider family

Lava is a framework with companions.

• Lava core for processes, models, ports and the runtime.
• Lava-DL for training deep spiking networks and exporting them to run in Lava.
• Lava-Optimization for solving constraint and optimization problems with spiking dynamics.
• Lava-DNF for dynamic neural fields, a way to model attention and memory.

You can use the core alone. Most users add Lava-DL when they want to train a model with gradients and then deploy it as event-based processes.

Where it came from

Neuromorphic computing is an old idea. In the late 1980s researchers proposed building electronics that mimic the way neurons and synapses work. For decades most work stayed in labs, with custom chips and one-off software. Each chip came with its own tools, and code written for one platform rarely moved to another.

By the late 2010s, several research chips had appeared. Loihi was one of them. It was designed to run spiking neural networks with very low power. The hardware created a software problem. Researchers needed a common language to describe event-based programs so that work could be shared and reused.

Lava was released as an open-source answer around 2021. Its goal was to be platform-agnostic. A developer could write processes, test them on a laptop CPU, and later map them to neuromorphic hardware without rewriting the algorithm. Over time the project added libraries for deep learning and optimization and encouraged community contributions.

The wider research background includes spiking neural network theory, the leaky integrate-and-fire neuron model, and surrogate gradient training. Those topics are covered in Spiking Neural Networks. For the research context of this site see /model/research.

How it works

This section walks through a Lava program from idea to run.

Step 1: Define a process

You declare a process class. It lists variables and ports but contains no computation. This is like writing the interface of a class before you write its body.

A neuron process, for example, might declare a membrane voltage variable, a current variable, an input port for spikes and an output port for spikes.

Step 2: Provide a process model

Next you write a model that says what the process does at each time step. A Python model might add incoming spikes to a current, decay the voltage, compare it to a threshold and send a spike if the threshold is crossed.

Analogy: the process is the shape of a vending machine, with a coin slot and a snack tray. The model is the mechanism inside. You can swap the mechanism without changing the outside.

Step 3: Connect processes

You connect output ports to input ports. A spike source can feed a dense layer of connections, which feeds a layer of neurons. The wiring is explicit and clear. Connections are made with a simple operator that links ports of compatible shape.

Step 4: Compile and run

You call a run method with a run condition, such as a number of time steps, and a run configuration that says which models to use. The runtime compiles the graph, allocates resources, and starts the processes.

Step 5: Exchange messages

Processes run in parallel and exchange messages. Lava uses a communicating sequential processes style. A process blocks until the messages it needs arrive, then it computes and sends its own messages. This makes the program naturally asynchronous and easy to spread across many cores or chips.

Step 6: Read results

When the run finishes you read variable values, or you attach monitor processes that record spikes and voltages over time. Then you stop the runtime to free resources.

A note on time

Lava runs in discrete time steps, but work inside a step is event-driven. Nothing happens in a process that receives no events. This is why neuromorphic hardware can use so little power: idle units do almost nothing.

Messages and synchronization in more detail

Lava processes do not share memory. They only exchange messages through ports.

This rule removes a whole class of bugs.

• No process can change another process's variables directly.
• There are no hidden locks to forget.
• Order of work is set by who waits for whom.

A process computes when its needed inputs are ready.

If an input is not ready, the process waits.

This is the same logic as a kitchen where the cook waits for the vegetables before cutting them.

The result is a program that can be split across many cores without changing its meaning.

Hierarchical processes

A larger structure can be built by grouping processes.

A hierarchical process contains sub-processes and wires them together.

From outside it looks like one block with ports.

From inside it is a small network.

This is like a car engine.

You talk to the engine as one part, yet it holds pistons, valves and a crankshaft.

Hierarchy helps you reuse blocks such as a convolution layer or a recurrent loop.

Process models and numeric types

A model can work in floating point for study or in fixed point for hardware.

A floating point model is easy to read and compare with a reference.

A fixed point model mirrors the integer math of a chip.

Writing both for the same process lets you see how much accuracy quantization costs.

Common model types include:

• A Python model for CPU simulation.
• A fixed point model that bit-matches hardware behavior.
• A hardware specific model that maps to chip resources.

Probes and monitors

Observing a neuromorphic program is harder than printing a value.

Variables live inside processes that may run on different cores.

Monitors are processes that listen to a variable or a port and write values to a buffer.

After the run you read the buffer and plot spikes or voltages.

Good habits:

• Record only what you need, because monitors cost memory.
• Use short runs for debugging.
• Plot a raster of spikes to see patterns by eye.

Common neuron and synapse building blocks

Spike timing and learning rules

Some neuromorphic work uses local learning.

A well known idea is spike-timing-dependent plasticity.

If a presynaptic spike comes just before a postsynaptic spike, the link is strengthened.

If it comes just after, the link is weakened.

The rule needs only information available at the synapse.

That is why it suits hardware with limited memory.

Lava lets a developer write such a rule as part of a process model.

Learning can then happen during the run, without a separate training machine.

Step size and time resolution

Each time step in Lava is a unit of simulated time.

A coarse step is fast but may hide fine timing.

A fine step is accurate but needs more steps for the same period.

Pick the step to match the fastest event you care about.

For a sensor sampled at 1 kHz, one step per millisecond is a natural start.

Mapping to hardware resources

On real chips, neurons live on cores with limited memory.

Each core holds a few thousand neurons and a limited number of synapses.

The compiler assigns processes to cores and routes messages between them.

Large layers are split across cores.

Connections that span cores cost more time and energy than those inside a core.

So the shape of your network affects speed and power, not just accuracy.

Key concepts and terms

A worked example

The following sketch shows the style of a small Lava network that wires a spike source, a dense connection and a layer of LIF neurons. Names follow the public API in spirit, and details such as exact import paths may differ by version, so check the current documentation before running it.

import numpy as np
from lava.proc.lif.process import LIF
from lava.proc.dense.process import Dense
from lava.proc.io.source import RingBuffer as SpikeSource
from lava.magma.core.run_conditions import RunSteps
from lava.magma.core.run_configs import Loihi1SimCfg

num_steps = 50
n_in, n_out = 8, 4

# A random spike pattern: rows are inputs, columns are time steps.
rng = np.random.default_rng(0)
spikes = (rng.random((n_in, num_steps)) < 0.2).astype(float)

source = SpikeSource(data=spikes)
weights = rng.normal(0.0, 20.0, size=(n_out, n_in))
dense = Dense(weights=weights)
neurons = LIF(shape=(n_out,), du=0.2, dv=0.1, vth=50)

source.s_out.connect(dense.s_in)
dense.a_out.connect(neurons.a_in)

neurons.run(condition=RunSteps(num_steps=num_steps),
            run_cfg=Loihi1SimCfg())
voltages = neurons.v.get()
neurons.stop()
print(voltages)

Reading the example

• The source plays back a fixed spike train, like a tape recorder.
• The dense process multiplies spikes by weights, like turning the volume knobs.
• The LIF process integrates the current. If its voltage crosses the threshold it fires and resets.
• The run configuration picks a simulation of the chip behavior on a CPU.
• After the run, we read the final voltage values from the neuron process.

A numeric walk-through of one neuron

Take a single LIF neuron with threshold 1.0, leak factor 0.9 and no input except two spikes.

1. Time 0: voltage 0.0. A spike arrives with weight 0.6. Voltage becomes 0.6.
2. Time 1: leak multiplies voltage by 0.9. Voltage is 0.54. No input.
3. Time 2: leak gives 0.486. A spike arrives with weight 0.6. Voltage becomes 1.086.
4. The voltage is above 1.0. The neuron fires and the voltage resets to 0.

The neuron only fired because two spikes came close enough in time that the leak had not erased the first one. This sensitivity to timing is a central feature of spiking models. Lava processes carry out exactly this kind of update, in parallel, for every neuron in a layer.

Training and then deploying

A typical workflow with Lava-DL is:

1. Define a spiking network with a training-friendly layer library.
2. Train it with surrogate gradients on a standard machine using PyTorch.
3. Export the trained weights and neuron parameters into a Lava network description.
4. Run that network as Lava processes in simulation.
5. Switch the run configuration to target neuromorphic hardware when available.

Typical application areas

Is it faster or cheaper?

Claims about energy savings depend on the task, the encoding and the hardware.

Event-based systems win when data is sparse and when work can be skipped.

They lose when data is dense and every unit must be active.

Always compare against a well tuned conventional baseline on the same task.

Treat any single efficiency number with care.

Ask what was measured, on what data, and at what accuracy.

Strengths and limitations

Strengths

• Platform-agnostic design. The same process graph can run in simulation or on supported hardware.
• Clear separation of structure and behavior. Processes describe interfaces. Models describe computation.
• Natural parallelism. Message passing between independent processes maps well to many-core and multi-chip systems.
• Python-first. Researchers can start with familiar tools and NumPy-style data.
• Open source. Code can be inspected, extended and shared.
• Not limited to neural networks. Any event-driven algorithm can be written as processes, including optimization and control.

Limitations

• Young ecosystem. Compared with mainstream deep learning stacks, there are fewer tutorials, pretrained models and community answers.
• Hardware access. Full benefits need neuromorphic hardware, which is not widely available. On a CPU, simulation can be slower than a dense tensor library.
• Learning curve. The process and message model is different from tensor programming. Debugging asynchronous programs takes practice.
• Training is separate. Gradient training is done in companion libraries, and conversions between training and deployment can lose accuracy.
• Version drift. APIs have changed over releases, so older examples may need edits.
• Narrow fit for dense data. Event-based computing shines on sparse, temporal signals. It gives little advantage on dense, static tables.

How it compares with alternatives

A fair summary: the PyTorch-based spiking libraries are easier for training and experiments. Lava is more useful when the target is a deployed, event-driven system, especially on neuromorphic hardware.

Role in tabular foundation models

Tabular foundation models learn from raw tables. A table has rows and columns, mixed types such as numbers, categories and dates, missing values, and sometimes no useful column names. Models of this kind are often pre-trained on large numbers of synthetic or real tables and then applied to a new table through in-context learning. See TabPFN and FT-Transformer for related ideas, and /model/architecture for how such a model is organized.

Lava is not a tabular model and does not claim to be one. Its relationship to tabular work is indirect, and it is better to be honest about that.

Where the connection is real

• Event streams from tables. Many real tables are logs of events with timestamps: sensor readings, transactions, machine states. A table row can be seen as an event. Lava processes are built to react to events, so an event-driven pipeline could pre-process or filter such streams close to the source.
• Anomaly detection. Spiking networks respond to unusual changes in a signal, and low-power event-based hardware is attractive for always-on monitoring at the edge. A detector that runs on neuromorphic hardware could flag unusual rows or windows before they are stored in a table. See Anomaly Detection.
• Continual learning. Neuromorphic research often studies local learning rules that update a network step by step without storing the full history. This is related in spirit to continual learning in tabular models, where new data arrives over time and old knowledge should not vanish.
• Efficient inference at the edge. A small model that scores rows on a device with strict power limits could be a spiking model deployed through Lava. The scores could then be uploaded to a larger tabular system.

Where the connection is weak

• Mixed types and missing values. Lava has no built-in notion of columns, categories or imputation. Spiking networks need numbers encoded as spikes, and that encoding step is the hard part for tabular data.
• In-context learning. The pre-train-then-predict-without-gradients pattern used by tabular foundation models is not a Lava feature. It lives in transformer style models.
• Semantic and sector classification. Understanding column meaning or classifying a table by sector needs text and context. That is not what event-based hardware excels at.

A practical view

If you work with tabular foundation models, the likely role of a framework like Lava is at the edges of the pipeline: sensing, filtering, early anomaly flags and low-power scoring. The heavy lifting of learning from many tables stays in dense transformer-style models running on GPUs. For the benchmark view of tabular models see /model/benchmarks.

Practical guidance and best practices

Start small

• Build one process with one model and test it in isolation.
• Add a monitor to record variables and compare them to hand calculations.
• Grow to layers only after the single neuron behaves as expected.

Keep structure and behavior apart

• Put ports and variables in the process class.
• Put computation in models.
• Keep several models per process so you can switch between a Python reference and a hardware version.

Choose encodings with care

Real-valued data must become spikes. Common choices are rate coding (more spikes for larger values), latency coding (earlier spikes for larger values) and delta coding (spikes only on changes). Pick the code that matches the signal. Delta coding is a natural fit for sparse, slowly changing sensor streams.

Validate against a reference

Run a floating-point reference in PyTorch or NumPy and compare outputs to the Lava simulation. Expect small differences from quantization of weights and states.

Mind quantization

Neuromorphic hardware uses limited precision for weights and state. Train with this in mind, or use tools that include quantization-aware steps, so that deployment does not cause a large accuracy drop.

Pin versions

Because the project evolves, pin the version of Lava and its companion libraries in a requirements file. Record the run configuration used for each experiment.

# example experiment record
experiment: lava-lif-baseline
lava_version: pinned-in-requirements
run_config: simulation-cpu
encoding: delta
time_steps: 200
notes: compare voltages with float reference

Measure what matters

On a CPU, speed is not the point. Measure spike counts, activity sparsity and the accuracy of the task. On hardware, measure energy per inference and latency.

A simple debugging checklist

1. Does a single neuron fire when you expect it to, using hand-made input?
2. Do the port shapes match on both ends of every connection?
3. Are weights in the range the neuron model expects?
4. Is the threshold high enough that the neuron does not fire on noise?
5. Does the float reference produce the same spike counts within a small margin?
6. Are you running enough time steps for the signal to pass through all layers?
7. Did you stop the runtime after the last run?

A project layout that scales

project/
  processes/      # process definitions
  models/         # process models for each backend
  encoders/       # data to spike conversion
  configs/        # run configurations and parameters
  experiments/    # scripts that wire and run graphs
  tests/          # small unit tests with known outputs

Keep tests small and numeric.

A test can feed three spikes to a neuron and assert the exact voltage.

This catches silent changes after a library update.

Documenting results

For each experiment record:

• the data and encoding,
• the network shape and parameters,
• the run configuration,
• the metric and how it was computed,
• the number of spikes per sample.

The spike count is a good proxy for energy on event-based hardware.

Common mistakes

• Treating Lava like a tensor library. Writing large dense loops defeats the purpose. Think in events and processes.
• Ignoring encoding. A model fed poorly encoded data will fail no matter how well wired.
• Skipping the reference check. Without a float baseline you cannot tell if a drop in accuracy comes from the model or from the port.
• Forgetting to stop the runtime. Leaving runtimes active can hold resources and block later runs.
• Mixing up shapes on ports. Connections need compatible shapes. Shape errors are the most common first failure.
• Expecting speedups on a laptop. Simulation is for correctness. Gains appear on real event-driven hardware.
• Over-fitting to one chip. Writing hardware specific code too early reduces portability.

• Using it for dense static tables. If the job is plain tabular prediction, a method such as XGBoost or TabPFN is a better tool.

• Using too many time steps. Long runs add cost without gain once activity has died out.

• Choosing thresholds by guesswork. Calibrate thresholds on a sample so that layers fire at sensible rates.
• Dead layers. If no neuron in a layer ever fires, nothing downstream learns. Check spike rates per layer.
• Saturated layers. If every neuron fires every step, no information remains. Lower weights or raise thresholds.
• Comparing unequal baselines. Compare against a model of similar size and accuracy, not a weak straw baseline.

Frequently asked questions

What is Lava used for?

Lava is used to write, simulate and deploy event-based programs, especially spiking neural networks and other algorithms designed for neuromorphic hardware. Researchers use it to test ideas on a CPU and then map them to supported chips. It is also used to explore low-power computing for sensing, control and optimization.

Do I need neuromorphic hardware to use Lava?

No. Lava includes simulation models that run on an ordinary computer, so you can learn the framework, test networks and compare results without special hardware. Hardware access matters when you want to measure real energy use and latency, but it is not required for development.

How is Lava different from snnTorch or Norse?

snnTorch and Norse are PyTorch libraries focused on building and training spiking networks with gradient methods. Lava is a broader framework for structuring event-based programs as communicating processes and for targeting different backends. Many projects train in a PyTorch library or in Lava-DL and then deploy through Lava.

Can Lava train a network?

The core library is mainly about describing and running processes. Training with gradients is handled by the companion library Lava-DL, which supports surrogate gradient methods for spiking layers. Local learning rules can also be written as processes, which suits research on on-chip learning.

Is Lava only for neural networks?

No. A process can hold any state and any event-driven logic. The project includes support for optimization problems and dynamic neural fields, and developers can write processes for filtering, routing or control that have nothing to do with neural networks.

Does Lava work with tabular data?

Lava has no native concept of tables, columns or categories. You can feed it tabular data by encoding numbers as spikes, but dense, static tables are rarely a good match for event-based hardware. It is more natural for time-stamped event streams, such as sensor logs, that happen to be stored as tables later.

Is Lava related to tabular foundation models?

Only indirectly. Tabular foundation models are pre-trained on many tables and use in-context learning to predict on new ones. Lava could help at the edge of such a pipeline, for example with low-power anomaly flags or filtering of event streams, but it does not replace transformer-style table models.

Which language does Lava use?

Lava is written in Python and is meant to be used from Python. Process models for specific hardware may use other low-level tools behind the scenes, but the developer-facing interface is Python.

Is the code open source?

Yes. Lava is released under permissive open-source terms, which allows use, modification and sharing. Check the license text in the repository for the exact conditions that apply to your project.

What should I learn first?

Start with leaky integrate-and-fire neurons and spike encoding, then learn the process, model and port abstractions. Work through a single-layer example, add a monitor, and compare it to a hand calculation. After that, try Lava-DL to train a small network and export it.

Glossary

• Asynchronous: not tied to a single global clock; units run when events arrive.
• Backend: the simulator or hardware that executes a process model.
• Event-based computing: computing that reacts to discrete events rather than continuous data streams.
• Leaky integrate-and-fire (LIF): a neuron model that accumulates input, leaks over time and fires at a threshold.
• Neuromorphic computing: hardware and software inspired by the structure of biological nervous systems.
• Port: a connection point for sending or receiving messages.
• Process: a unit with state and ports that does not define its own behavior.
• ProcessModel: the implementation of a process for a given backend.
• Quantization: reducing numeric precision, such as using small integers for weights.
• Rate coding: representing a value by how many spikes occur in a time window.
• Runtime: the component that compiles and executes a graph of processes.
• Sparsity: having mostly zeros, or here, few active events at any time.
• Spike: a short discrete event emitted by a neuron.
• Surrogate gradient: a smooth stand-in for the non-differentiable spike function, used for training.
• Synapse: a weighted link between two neurons.

Summary

Lava is an open-source Python framework that structures event-based programs as processes with ports, state and swappable models, and runs them in simulation or on neuromorphic hardware such as Loihi. It is best seen as a deployment and structuring layer, with Lava-DL for training and companion libraries for optimization and neural fields.

For tabular foundation models its role is at the edges: event streams, low-power anomaly flags and efficient edge scoring, not in-context learning on mixed-type tables. Use it when you target event-driven hardware or want portable neuromorphic code. For training experiments use snnTorch, Norse or SpikingJelly, and for general table prediction use methods such as TabPFN. To learn the theory behind it, read Spiking Neural Networks and the notes at /model/research.

Related

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