Software Register

Software Product

Axon

A circuit workbench grown from Modified Nodal Analysis

Fig. 1 · Product ViewPublished
Axon

Product Record

Status
Experimental
Last Updated
Jul 2026

Specification

Product Overview

Axon, a Circuit Workbench in Rust

Where It Started

Axon began with a question I kept returning to while working in power electronics: what would a circuit simulator look like if its foundations were laid today?

SPICE remains one of the most useful pieces of engineering software ever written, but decades of history show through its interfaces and internal assumptions. I wanted a smaller place to experiment with circuit simulation, use Rust’s type system to make the boundaries explicit, and leave room for the electrical model to meet mechanical and control systems later.

The first version was little more than Modified Nodal Analysis and a long roadmap. It could prove that the equations worked, but not yet that the product around them made sense. Axon has since grown into a workbench: simulation core, schematic document, execution runtime, plugins, file format, and several ways to drive the same model.

The Numerical Core

At the center is Modified Nodal Analysis, the method used by SPICE and many of its descendants. Devices stamp their contribution into a linear system of the form 𝐴𝑥=𝑧. The solver finds node voltages and the extra branch currents introduced by voltage-defined elements.

That machinery supports the analyses Axon is being built around:

  • operating-point analysis, including Newton iteration for nonlinear devices
  • transient analysis with implicit integration
  • AC small-signal analysis around an operating point

The simple cases come first. A resistor network, an RC step, or the impedance of a small filter is not glamorous, but each gives a result that can be checked by hand. Simulators become dangerous when a polished plot makes a wrong answer look convincing.

One Model, Several Front Ends

The repository is a Rust workspace with deliberately narrow layers:

  • axon-core owns devices, assembly, analyses, and solvers
  • axon-schematic owns the circuit document, symbols, geometry, and editing operations
  • axon-api presents a synchronous, UI-free way to load projects and run studies
  • axon-runtime owns asynchronous executions, journal facts, waveform series, and plugin grants
  • the CLI, desktop workbench, HTTP server, and Python bindings sit on top of those layers

The goal is that a circuit opened in the desktop editor is the same circuit inspected from the CLI or used from Python. The frontend should change the way a person works with the model, not quietly invent a second model of its own.

Projects are stored in a single .axon container. It carries an explicit format version and keeps the circuit, studies, and related artifacts together. A project should be a durable engineering document, not a directory full of files that only one application knows how to reassemble.

Extensions without Owning the Core

Device models and engineering workflows grow faster than one simulator can absorb them. Axon therefore has a plugin contract that is separate from the runtime itself, with guest-side and sidecar authoring kits.

This is still early work. The useful constraint is already clear, though: a plugin receives an explicit capability and data surface. It does not get to reach through the application and depend on whatever internal type happened to be convenient that week.

Why Axon?

In biology, an axon carries electrical signals away from a neuron. The name also fits a netlist, which is ultimately a chain of electrical connections between nodes.

There is a third reason I like it: axon comes from the Greek word for axis. A short name with electrical, structural, and classical baggage was always going to win over something assembled from “volt”, “sim”, and a missing vowel.

Current State

Axon is experimental. The implemented vertical slices are useful for testing the architecture, but it is not yet a replacement for a mature simulator. Nonlinear device coverage, sparse solvers, event handling, electromechanical models, runtime persistence, and the plugin distribution path all need more work.

That unfinished state is the point of the project for now. Axon is where I can take the pieces I use in real engineering work, pull them apart, and find out how I would put them together myself. Sometimes the answer survives. Sometimes a branch gets deleted. Both are progress.