Own product · In development · Rust · SPICE · AI

Circuit Forge: The AI-native SPICE simulator

A SPICE simulator with its own solver core in Rust, and a built-in assistant that works through the simulator’s tools and proposes circuits, values and requirements. Whether they hold is checked by a deterministic engine. In the default setting, nothing is applied until a person agrees.

In development. Not yet publicly available. For Windows, macOS and Linux.

Request early access How the AI works

Colour code on this page

Computed By the deterministic engine: same input, same result.
Proposed By the language model: a proposal that the engine checks.
Decided By a person: in the default setting, only what someone confirms is applied.

One request, once around the loop

Example

Proposal

The model proposes the circuit and its values. The drawing is the netlist.

Model’s proposal: linear regulator from U1 and M1, reference 1.25 V, feedback 18 kΩ on top and 11 kΩ below from the E24 series

V1 5 V VREF 1.25 V M1 U1 R1 18 kΩ R2 11 kΩ RL 33 Ω

in out fb

Netlist

V1 in 0 5
VREF ref 0 1.25
XU1 fb ref gate in 0 OPAMP
M1 out gate in in PMOS
R1 out fb 18k
R2 fb 0 11k
RL out 0 33
.dc V1 0 5 0.1

Simulation

Transfer curve over the supply, computed from the component values

0 V 3.3 V 0 V 5 V V1 →

V(out) = 3.295455 V at V1 = 5 V. Below that the regulator lacks headroom: the curve only enters the tolerance band from V1 = 3.421 V.

Checks

Eight deterministic checks

erc passed
isomorphism passed
static passed
analysis_binding passed
spec_binding passed
dynamic passed
spec passed
final_artifact passed

vout_3v3_accuracy [op]: actual 3.295455 V · target 3.300000 V ± 0.066 V · pass

3.234 V 3.366 V

3.2 V 3.4 V

verified

A person accepts the verified schematic.

An illustrative example, not a recorded run. The sequence is schematic, the curve is computed from the component values.

The run in three beats, shown on a linear regulator. First the language model proposes the circuit: the op-amp U1 compares the divided output with a 1.25 V reference and drives the P-channel MOSFET M1, with 18 kΩ on top and 11 kΩ below as feedback. Sweeping the supply shows the output inside the tolerance band from V1 = 3.421 V and regulating to 3.295455 V at 5 V. Then the engine runs 8 deterministic checks on the design, the last one against the target 3.3 V ± 0.066 V. All of them pass, and a person accepts the verified schematic.

Why it exists

Our own solver core in Rust

MNA, sparse LU factorisation and Newton with a six-stage convergence strategy, plus three integration methods with an adaptive step. Our own code forbids unsafe, with one justified exception: reading large waveform files through memory mapping.

AI with tools

The assistant does not compute anything itself. It calls the simulator through typed tools and reads the numbers that come back. Only the engine’s checks can award the verdict “verified”.

Schematic, simulation, analysis

All in one program. The drawing is the netlist: there is one parser and no second translation that could read the circuit differently along the way.

Reproducible to the byte

Results come as versioned JSON documents that scripts, CI and agents can compare. With the same build on the same platform, the same input gives byte-identical results.

The loop

From the first wire to the last measurement, with no export in between.

Schematic

Hierarchical schematics with a navigator
Rule checks while you draw, with 33 rules. Deliberate waivers are kept.
Voltage, current, power and operating region right on the canvas
The drawing is the netlist.
A schematic can also be generated from a netlist. It is only shown once it is proven to describe the same circuit and the rule check finds no error. Still experimental.

Simulation

13 analyses in one engine
Multi-axis .step sweeps, temperature and Monte-Carlo
Waveforms grow while the solver runs. Stop keeps what has already been computed.
Three integration methods with an adaptive step

Analysis

Four cursors, trace math and .meas
Spectrum with THD, SNR, SINAD, SFDR and ENOB
Bode plots and sweep families
Run comparison, export as CSV and SVG

Analyses

.op
.dc
.tran
.ac
.noise
.tf
.sens
.pz
.net
.disto
.four
.bode
.meas

46 bundled example circuits in 9 categories. Tests guard every one of them: clean in the rule check, translatable into a netlist and able to run in simulation.

As of September 2026

AI-native

The AI proposes. The engine checks. You decide.

AI-native means two things in Circuit Forge. Every machine-readable result is a versioned document that a program or an agent can read. And every change the AI makes is a proposal that deterministic checks assess before it is applied.

Why we build it this way: Determinism and AI

One request, step by step

Example · run of 23 September 2026

Person

Request

Design a resistive divider that makes 3.3 V from a 5 V supply within ±2%, using E24 resistor values.
Language model

Propose a contract

Before anything is built, the model uses the tool cf_propose_spec to propose a contract: what will be measured and which assumptions apply.
Requirement
Stated by you

vout_3v3_accuracy op V(out) = 3.3 V ± 2%
Assumptions
- The output is unloaded.
- The resistors take nominal values from the E24 series.
- Nominal values at the default temperature. The tolerance applies only to the simulated output with these nominal values.
Numbers supplied by the model: 0 of 1. Such rows are counted and highlighted so that you check them before accepting.
Person

Accept the contract

A person clicks Accept. The contract is frozen and gets a content hash.

Content hash, shortened a8f2871c
Language model

Propose a circuit

The model proposes a divider on 5 V: 10 kΩ on top, 20 kΩ below, both from the E24 series.
Engine

Eight checks

The engine checks the proposal in a fixed order. If a check fails, its report goes back to the model, which revises the design.
1. erc Electrical rule check of the generated schematic passed
2. isomorphism Schematic and generated netlist are electrically the same circuit passed
3. static Read the netlist and check it for errors passed
4. analysis_binding Every analysis in the contract is also in the design passed
5. spec_binding Every net the contract measures exists in the design passed
6. dynamic Every analysis in the contract runs to completion passed
7. spec The requirements of the contract hold passed
8. final_artifact The final schematic is regenerated exactly and passes every check once more passed
All passed in iteration 1.
Engine

Measure

The engine computes the operating point:

vout_3v3_accuracy [op]: actual 3.333333 V · target 3.300000 V ± 0.066 V · pass

5 V · 20 kΩ / (10 kΩ + 20 kΩ) = 3.333 V

3.234 V 3.366 V

3.2 V 3.4 V
Person

Release

The accept button only becomes active once every check has passed. The schematic is applied when a person clicks it.

If a check fails, the design can only be imported as an unverified draft.

A verified run sends the circuit and the conversation to the provider. If attaching the circuit is switched off in this conversation, the run therefore does not start.

Steps paraphrased from the product. Verified means: the contract you accepted holds in simulation on this build of the engine. It is not a guarantee for the hardware.

34 tools, none of them edits the design

The AI layer of Circuit Forge knows 34 typed tools: 11 run the simulator, 5 draft proposals and 18 are read-only. Depending on the task, the assistant gets a subset of them. A schematic change is applied to a copy, checked by the rule check and by a proof that drawing and netlist are the same circuit, and then shown to you to accept or reject.

Simulate 11 tools

cf_op
cf_sens
cf_tf
cf_noise
cf_meas
cf_wave_digest
cf_explain_convergence
cf_check_spec
cf_optimize
bm_run_tests
cf_run_component_tests

Propose 5 tools

bm_propose_model
cf_propose_circuit_edit
cf_propose_deck
cf_propose_patch
cf_propose_spec

Read and ask 18 tools

cf_complete
cf_lint
cf_catalog
cf_resolve_component
cf_find_model
cf_erc
cf_result_digest
cf_compare_runs
cf_result_window
cf_result_meas
cf_result_spectrum
cf_sweep_digest
cf_sweep_table
bm_catalog
bm_read_model
cf_layout_variants
cf_validate_component
cf_ask_user

0 Tools that edit the design directly

When the assistant has to guess, it is instructed to use conventional values and to state every assumption. It is only meant to ask in defined cases, such as mains voltage, anything above 50 V, battery charging or anything connected to a person, and then with three questions at most.

As of September 2026

Where your data goes

Your own API key for Anthropic or OpenAI, kept in the operating system’s key store.
Simulation runs locally. The engine contains no call to a language model.
Your circuit only goes to the provider while it is attached. A switch in each conversation controls that. It is on out of the box, and the default for new conversations can be changed.
By default, conversations are stored locally and unencrypted. Storing them can be switched off.
Changes by the AI are proposals. Auto-apply is off out of the box.
Without a key, the assistant stays off. Schematic, simulation and analysis work without it.

Requirements as a file

Requirements you can run.

Requirements live in a short text file, the .cfspec. One engine command runs the analyses they need and reports pass or fail for every requirement at every declared temperature. The worst corner decides. The exit code is 0 when everything is met, 3 when a requirement is missed and 65 when the circuit could not be simulated. You reach it through the engine’s command line or through the assistant.

Three temperatures, one verdict

Requirement (.cfspec)

cfspec = 1

[meta]
name = "diode-bias"

[[analyses]]
kind = "op"
directive = ".op"
corners = [-40, 27, 85]

[[assertions]]
name = "diode_bias"
analysis = "op"
measure = ".meas op vd FIND V(d) AT 0"
check = { kind = "value", target = 0.634, tol = 0.02 }

Circuit (excerpt)

V1 in 0 5
R1 in d 10k
D1 d 0 DM
.model DM D

Measured value and verdict per temperature
Corner	Measured	Verdict
−40 °C	0.7547 V	fail
27 °C	0.6337 V	pass
85 °C	0.5260 V	fail

V(d) 0.614 V 0.654 V −40 °C 27 °C 85 °C

Overall: fail

Put together from the engine’s documentation: a diode on 5 V through 10 kΩ. Its forward voltage drops by roughly 2 mV per kelvin, so the requirement 0.634 V ± 0.02 V, that is 0.614 V to 0.654 V, only holds at 27 °C.

A lucky sample certifies nothing

For Monte-Carlo yield, Circuit Forge judges the lower bound of a confidence interval, not the raw pass ratio. 20 passes out of 20 give a bound of only 0.8808, so a required yield of 0.99 is refused. Certifying it takes at least 268 runs without a single failure.

L_{95} = \frac{\hat{p} + \frac{z^{2}}{2 n} - z \sqrt{\frac{\hat{p} (1 - \hat{p})}{n} + \frac{z^{2}}{4 n^{2}}}}{1 + \frac{z^{2}}{n}}

Wilson lower bound, one-sided 95%, with z = 1.6449. p̂ is the share of passing runs, n their number.

Raw ratio and lower bound for a few samples, checked against a required yield of 0.99
Passed of N	Raw ratio	Lower bound	Verdict
20 of 20	1.0000	0.8808	not certified
198 of 200	0.9900	0.9702	not certified
267 of 267	1.0000	0.9899	not certified
268 of 268	1.0000	0.9900	certified

Minimum number of runs without a failure: 25 for 0.90, 52 for 0.95, 268 for 0.99.

Computed with the engine’s formula. The bound is rounded down to four places; the verdict uses the unrounded value.

Raw ratio: 1.0000
Lower bound (Wilson, one-sided 95%): 0.8808
Verdict: not certified

20 of 20 passed: bound 0.8808, required 0.99, not certified.

Buildable values or an honest no

For the example divider, the arithmetic asks for R2 = 19,411.76 Ω. Nobody sells that resistor. The Circuit Forge optimizer therefore snaps to preferred values and simulates the buildable point again, and when no value in the series works, it says so. You can try the arithmetic behind it here.

| V_{out} - V^{*} | \leq p V^{*}, V_{out} = V_{1} \frac{R_{2}}{R_{1} + R_{2}}

V* is the target, p the tolerance as a fraction.

The engine’s optimizer tunes up to 16 component values at once. Today you reach it through the assistant. It snaps to preferred values from E6 to E192 and simulates the buildable point again. Its result is a recommendation that you review and apply like any other proposal.

Computed for an unloaded divider. The tolerance band is the target plus or minus the percentage of the target, as in the example contract. With a percentage tolerance the engine uses the larger of measured and target value, so at a few edge points its verdict differs.

Supply 5 V, R1 = 10 kΩ fixed, R2 from the series

Ideal R2 19.41 kΩ

10 kΩ 100 kΩ

Next value below

18 kΩ

V(out): 3.214 V
Deviation: −2.60%

misses it closest

Next value above

20 kΩ

V(out): 3.333 V
Deviation: +1.01%

meets it closest

E24: 20 kΩ gives 3.333 V, a deviation of +1.01%. The requirement is met.

The example cases at a glance
Target	Tolerance	Series	Ideal R2	Next value below	Next value above	Solution
3.3 V	2%	E12	19.41 kΩ	18 kΩ misses it 3.214 V −2.60%	22 kΩ misses it 3.438 V +4.17%	none
3.3 V	2%	E24	19.41 kΩ	18 kΩ misses it 3.214 V −2.60%	20 kΩ meets it 3.333 V +1.01%	yes
3.3 V	2%	E96	19.41 kΩ	19.1 kΩ meets it 3.282 V −0.55%	19.6 kΩ meets it 3.311 V +0.33%	yes
2.9 V	1%	E24	13.81 kΩ	13 kΩ misses it 2.826 V −2.55%	15 kΩ misses it 3.000 V +3.45%	none
2.9 V	1%	E96	13.81 kΩ	13.7 kΩ meets it 2.890 V −0.33%	14 kΩ meets it 2.917 V +0.57%	yes

A solver that tells you what it did

When a simulation fails, you find out why.

The solver records which strategy got it there. When it fails, you get a typed finding with hints, not a bare “singular matrix”. Whatever the engine cannot compute faithfully, it refuses by name instead of quietly replacing it.

Six stages, each one logged

Stage 0

Newton

The plain Newton iteration. Most circuits converge right here.

did not converge
Stage 1

GMIN stepping I

A first variant that adds extra conductances and removes them step by step.

did not converge
Stage 2

GMIN stepping II

Extra conductances on an adaptive schedule: a level that converges quickly widens the next step. A failed level is retried from the last solved state with a smaller step.

converged
Stage 3

Source stepping

Every independent source ramps from zero to its full value. Each level starts from the solution of the one before.

not needed
Stage 4

Homotopy

A single parameter ramps the sources up and removes extra conductances at the same time.

not needed
Stage 5

Pseudo-transient

The circuit is led to its resting state as in a time-domain run. If that fails as well, the solver gives up and says so.

not needed

Attempts in the result

Attempt 1: Newton, did not converge
Attempt 2: GMIN stepping I, did not converge
Attempt 3: GMIN stepping II, converged

The result names the method that won and lists every attempt.

Schematic sequence, not a recorded run. Which stage wins depends on the circuit; in this picture it is stage 2.

Failures with instructions

When a simulation fails, the engine returns a typed finding. It names the nets involved and says what to do next. Three cases, shown with the engine’s message templates.

No DC path to ground

Before it computes anything, the engine checks the topology. Every net without a DC path to ground is named, and disconnected parts of the circuit are grouped into islands.

no DC path to ground: <n> net(s) float (<nets>) in <k> disconnected island(s)

Refuse instead of quietly ignoring

A parameter the engine does not model yet is refused by name. Carrying on with half a model as if it were the whole one is not an option.

JFET "J1" `.model` uses CGSO=<value>; the transient stamp models gate-junction depletion charge only (CGSO is not yet modelled) at byte <n>

A partial result instead of nothing

When the time step of a transient analysis becomes too small, the run ends as a partial result. Every point that converged up to then is kept, and the last one carries the diagnostic. The hints fit the case, here the trapezoidal rule without .ic.

Schema: cf.tran.v1
Status: partial
Diagnostic: timestep_too_small
Hints: try_gear2

check_source_discontinuity

relax_reltol

add_ic

17 hints, machine-readable

check_floating_nodes Look for a node with no DC path to ground and anchor or reconnect it.
check_voltage_source_loop Look for ideal voltage sources in a loop or in parallel that impose contradictory constraints.
add_dc_path_to_ground Give every disconnected part of the circuit a DC path to ground, for example a high-value bleed resistor.
add_nodeset Give a .nodeset initial guess near the expected operating point. It is honoured for the start of a .tran, not yet for .op and .dc.
check_bistable_topology Check for bistable or multi-root topologies, such as latches or oscillators with no unique DC operating point.
relax_reltol Relax .options reltol. The tolerance may be tighter than the conditioning of the circuit supports.
check_model_parameters Inspect the .model parameters for extreme or non-physical values.
increase_itl1 Raise the cap on Newton iterations (.options itl1).
check_source_magnitudes Check source magnitudes and behavioural expressions for values that overflow the device equations.
try_gear2 For stiff circuits, switch to the L-stable Gear-2 integrator (.options method=gear).
check_source_discontinuity Check PULSE and PWL sources for edges with zero duration and give every edge a finite rise or fall time.
add_ic Add a .ic initial condition, or start the .tran with UIC, so the run begins in a known state.
check_initial_conditions The initial state the deck asserts (.ic or IC=) may itself be the problem. Check it for implausible values, such as a junction held several volts forward, or remove it and let the bias solve seed the run.
run_tran_instead Run a .tran instead of the DC operating point.
check_block_hysteresis A behavioural block with hysteresis may have no DC fixed point. Start the .tran from its declared initial state (with UIC), give the loop a startup stimulus or remove the hysteresis.
use_uic_tran Add UIC to the .tran line. The run then starts from the asserted initial state instead of solving for a bias point the circuit may not have.
add_startup_stimulus Give the circuit a defined start, such as a reset or enable pulse at t = 0 or a source that ramps up from zero. A latch or oscillator then has exactly one initial state.

Messages as the engine words them. Values in angle brackets are placeholders; the part about islands only appears when there is more than one island.

As of September 2026

The phase margin trap

A control loop with a gain of 1000 (60 dB) and 3 poles at 100 Hz. Read the phase margin from the principal value of the phase and the loop looks stable. Circuit Forge unwraps the phase, evaluates every point where the gain crosses 0 dB and reports the margin that decides.

60 dB 0 dB −60 dB 180° 0° −180° −270° 10 Hz 100 Hz 1 kHz 10 kHz 995 Hz 173.2 Hz

Naive, principal value

180° + 107.22° = 287.22°

looks stable

Unwrapped

180° + (−252.78°) = −72.78°

unstable

Gain margin −41.94 dB at 173.2 Hz

Gain: 1000
Poles: 3
Pole frequency: 100 Hz
Crossover frequency (0 dB): 995 Hz
Phase there, unwrapped: −252.78°
Phase there, principal value: 107.22°
Phase margin, unwrapped: −72.78°
Phase margin, naive: 287.22°
Frequency at −180°: 173.2 Hz
Gain there: +41.94 dB
Gain margin: −41.94 dB

Magnitude and phase of the example loop, one row per decade
Frequency	Magnitude	Phase, unwrapped	Phase, principal value
10 Hz	59.870 dB	−17.13°	−17.13°
100 Hz	50.969 dB	−135.00°	−135.00°
1 kHz	−0.130 dB	−252.87°	107.13°
10 kHz	−60.001 dB	−268.28°	91.72°

Conditionally stable

A second loop from the engine’s tests crosses 0 dB more than once. At the first crossing it looks safe. Circuit Forge reports the crossing with the smallest margin, because that is the one that decides.

First 0 dB crossing: 100 Hz, phase −30°, margin 150°
Limiting crossing: 10 kHz, phase −190°, margin −10°

The margin is available in requirements (.cfspec) and in the machine-readable results; the user interface has no readout of its own for it yet.

Computed example in closed form, as in the engine’s test.

If you want to see what the solver computes: the engine’s command line prints the MNA equations of a circuit and, for every transistor, its operating region, threshold voltage, gm and gds.

cf matrix --explain
cf op --device-op

Same input, same bytes

Computed in parallel, identical byte for byte.

The engine runs sweeps, temperature runs and Monte-Carlo in parallel. Results are gathered by their index, and floating-point numbers are never combined across threads. Every analysis result names its schema and carries a BLAKE3 hash of the normalised input that ignores white space, comments and letter case.

The promise covers the same input, the same build and the same platform. We do not make it across platforms or versions.

One sweep, two runs

Netlist

parallel determinism smoke
.param rr = 1k
V1 in 0 DC 1
R1 in out {rr}
R2 out 0 10k
.dc V1 1 1 1
.step param rr 1k 33k 1k
.end

One thread

00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

SHA-256 of this table

f79851f3de65e3af2f41283b56f7457e6d17f2101b5acda46babf272a7ee7ff9

8 threads

00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

SHA-256 of this table

f79851f3de65e3af2f41283b56f7457e6d17f2101b5acda46babf272a7ee7ff9

identical

Order in which the points finished in the parallel run: 05, 06, 07, 02, 00, 03, 04, 08, 01, 13, 11, 14, 09, 16, 10, 12, 15, 18, 21, 20, 23, 24, 17, 22, 27, 19, 25, 26, 28, 30, 29, 32, 31

View the table: 33 lines, 990 bytes

00  rr= 1k  V(out)=0.909091 V
01  rr= 2k  V(out)=0.833333 V
02  rr= 3k  V(out)=0.769231 V
03  rr= 4k  V(out)=0.714286 V
04  rr= 5k  V(out)=0.666667 V
05  rr= 6k  V(out)=0.625000 V
06  rr= 7k  V(out)=0.588235 V
07  rr= 8k  V(out)=0.555556 V
08  rr= 9k  V(out)=0.526316 V
09  rr=10k  V(out)=0.500000 V
10  rr=11k  V(out)=0.476190 V
11  rr=12k  V(out)=0.454545 V
12  rr=13k  V(out)=0.434783 V
13  rr=14k  V(out)=0.416667 V
14  rr=15k  V(out)=0.400000 V
15  rr=16k  V(out)=0.384615 V
16  rr=17k  V(out)=0.370370 V
17  rr=18k  V(out)=0.357143 V
18  rr=19k  V(out)=0.344828 V
19  rr=20k  V(out)=0.333333 V
20  rr=21k  V(out)=0.322581 V
21  rr=22k  V(out)=0.312500 V
22  rr=23k  V(out)=0.303030 V
23  rr=24k  V(out)=0.294118 V
24  rr=25k  V(out)=0.285714 V
25  rr=26k  V(out)=0.277778 V
26  rr=27k  V(out)=0.270270 V
27  rr=28k  V(out)=0.263158 V
28  rr=29k  V(out)=0.256410 V
29  rr=30k  V(out)=0.250000 V
30  rr=31k  V(out)=0.243902 V
31  rr=32k  V(out)=0.238095 V
32  rr=33k  V(out)=0.232558 V

An illustration based on an engine test: the table here is computed from the closed-form formula, and the thread order is made up. The engine gathers results by index, so its output does not depend on the order; its test compares two parallel runs byte for byte.

Versioned contracts (selection)

cf.op.v1
cf.dc.v1
cf.tran.v1
cf.ac.v1
cf.noise.v1
cf.tf.v1
cf.four.v1
cf.bode.v1
cf.mc.v1
cf.measure.v1
cf.error.v1

The major version in the schema name only goes up with an incompatible change. New fields that a reader can ignore stay within the same version.

More on reproducibility: Determinism and AI

Mixed-signal and firmware

Firmware and circuit in the same transient.

The behavioural model of a microcontroller runs in the same transient analysis as the circuit. Its pins drive through real conductances, push-pull or open-drain, so an input with an internal pull-up reads 3.2869 V rather than an ideal 3.3 V. Two models can also exchange data over a byte channel without any electrical connection between them.

A behavioural model, not an emulator: the firmware is written in the Circuit Forge model language, and there is no instruction timing. It can be exported as C or Rust, equivalent in behaviour but not bit for bit.

One byte there and back

Netlist

VDD vdd 0 3.3
N1 vdd 0 echo uart_probe
N2 vdd 0 rx uart_terminal
.serial link0 N1.uart0 N2.uart0 BAUD=9600
.tran 100u 5m
.end

Firmware (excerpt from the model)

if reset_pending() {
    gpio_mode(ECHO, OUTPUT_PUSH_PULL);
    gpio_write(ECHO, false);
    serial_write(UART0, 65.0);
}
if serial_readable(UART0) {
    state.got = serial_read(UART0);
    if state.got == 65.0 {
        gpio_write(ECHO, true);
    }
}

N1 → N2

V(rx)

N2 → N1

V(echo)

0 ms 1 ms 2 ms 3 ms 4 ms 5 ms

Length of one frame: 1.0416667 ms
Byte arrives at the terminal: 1.0417667 ms
Terminal drives RX high: 1.047590 ms
Echo arrives at the firmware: 2.0892567 ms
Firmware drives ECHO high: 2.090331 ms

At 9600 baud the byte arrives after 1.0417667 ms.

Times in the transient at both baud rates
Event	9600 baud	4800 baud
Length of one frame	1.0416667 ms	2.0833333 ms
Byte arrives at the terminal	1.0417667 ms	2.0834333 ms
Terminal drives RX high	1.047590 ms	2.085090 ms
Echo arrives at the firmware	2.0892567 ms	4.1684233 ms
Firmware drives ECHO high	2.090331 ms	4.171581 ms

At half the baud rate the round trip takes 1.9957 times as long: the frames grow with it, the two wake-up steps do not.

Values from the engine’s documentation: firmware and terminal on one byte channel, 8N1, 3.3 V.

Technology and status

The state of the development build, line by line. Whatever does not run yet is marked “in progress” or “planned”.

As of September 2026

Technology and development status of Circuit Forge, as of September 2026
Area	Scope	Status
Engine and interface	Written in Rust. The interface is currently in English.	runs in the development build
Analyses	.op .dc .tran .ac .noise .tf .sens .pz .net .disto .four .bode .meas, plus multi-axis .step sweeps, temperature and Monte-Carlo; .disto currently for diodes and a single tone only	runs in the development build
Solver	MNA, sparse LU factorisation, Newton with a six-stage convergence strategy; trapezoidal, Gear-2 and backward Euler with an adaptive step	runs in the development build
Device models	Passive components with temperature coefficients, controlled and behavioural sources, diodes, bipolar transistors up to a high-frequency compact model, JFET, MESFET, MOSFET from level 1 up to short-channel models, power MOSFET and transmission lines. Some models still have limitations.	runs in the development build
More models	Further compact transistor models and models written in a hardware description language	planned
Requirements	.cfspec with temperature corners, worst case over tolerances and Monte-Carlo yield	runs in the development build
Mixed-signal	Behavioural and microcontroller models in the same transient, firmware export as C or Rust. First stage.	runs in the development build
AI assistant	Your own key for Anthropic or OpenAI, 34 tools in the AI layer, changes only as proposals	runs in the development build
Import	Schematics in the .qsch format and from Altium (.SchDoc)	in progress
Import	KiCad and LTspice	planned
Results	Versioned JSON contracts, byte-identical for the same input, the same build and the same platform	runs in the development build
Platform	Windows, macOS and Linux	runs in the development build
Access	Not yet publicly available, early access on request

Engine and interface: Written in Rust. The interface is currently in English.; runs in the development build
Analyses: .op .dc .tran .ac .noise .tf .sens .pz .net .disto .four .bode .meas, plus multi-axis .step sweeps, temperature and Monte-Carlo; .disto currently for diodes and a single tone only; runs in the development build
Solver: MNA, sparse LU factorisation, Newton with a six-stage convergence strategy; trapezoidal, Gear-2 and backward Euler with an adaptive step; runs in the development build
Device models: Passive components with temperature coefficients, controlled and behavioural sources, diodes, bipolar transistors up to a high-frequency compact model, JFET, MESFET, MOSFET from level 1 up to short-channel models, power MOSFET and transmission lines. Some models still have limitations.; runs in the development build
More models: Further compact transistor models and models written in a hardware description language; planned
Requirements: .cfspec with temperature corners, worst case over tolerances and Monte-Carlo yield; runs in the development build
Mixed-signal: Behavioural and microcontroller models in the same transient, firmware export as C or Rust. First stage.; runs in the development build
AI assistant: Your own key for Anthropic or OpenAI, 34 tools in the AI layer, changes only as proposals; runs in the development build
Import: Schematics in the .qsch format and from Altium (.SchDoc); in progress
Import: KiCad and LTspice; planned
Results: Versioned JSON contracts, byte-identical for the same input, the same build and the same platform; runs in the development build
Platform: Windows, macOS and Linux; runs in the development build
Access: Not yet publicly available, early access on request

Frequently asked questions

What is Circuit Forge?

Circuit Forge is a SPICE simulator that elsyQ develops as its own product, with a solver core in Rust and a built-in AI assistant. Schematic, simulation and analysis run in one program, and the drawing is also the netlist. The assistant proposes circuits, values and requirements, and a deterministic engine checks them. Circuit Forge is in development and not yet publicly available.

What does AI-native mean in Circuit Forge?

In Circuit Forge, AI-native means that the AI is part of the design from the start but never has the last word. Every machine-readable result is a versioned document that a program or an agent can read. The assistant works through the simulator’s typed tools, and every change it proposes is assessed by deterministic checks before anyone applies it. elsyQ builds Circuit Forge on the same principle as its other systems: the model proposes, deterministic code checks and computes.

Does the AI compute the simulation?

In Circuit Forge the simulation is computed by the solver that elsyQ wrote itself in Rust, and the engine contains no call to a language model. The assistant starts analyses through tools and reads the numbers the simulator returns. Whether a design counts as verified is decided by the engine’s deterministic checks.

Can I use Circuit Forge yet?

Circuit Forge is in development and not yet publicly available. elsyQ builds it for Windows, macOS and Linux. We are not giving a date yet. If you would like early access, tell us what you are working on through the contact form or by e-mail. We will get in touch when a preview version fits your use.

Which netlists does Circuit Forge read?

Circuit Forge reads SPICE netlists and parts of extended dialects. Whatever the engine does not support, such as encrypted models or .control blocks, it refuses by name instead of quietly skipping it. elsyQ is currently working on importing schematics in the .qsch format and from Altium; import from KiCad and LTspice is planned.

Where does my circuit data go?

In Circuit Forge, the simulator by elsyQ, the simulation runs locally on your computer. For the assistant you enter your own API key for Anthropic or OpenAI, which is kept in the operating system’s key store. Your circuit only goes to that provider while it is attached to the conversation. A switch in each conversation controls this; it is on out of the box, and the default can be changed. Conversations are stored locally and unencrypted, and that can be switched off too.

Is a verified design guaranteed to work?

A verified design in Circuit Forge is not guaranteed to work: verified means that the contract you accepted holds in simulation on this build of the engine. That is not a guarantee for the hardware you build. elsyQ recommends putting tolerances, temperature and yield into the contract and measuring the circuit once it is built.

Trademark notice Third-party names mentioned here (Anthropic, OpenAI, Altium, KiCad, LTspice, Windows, macOS, Linux) and the file formats mentioned are marks of their respective owners and are used only to identify providers, programs or formats. Circuit Forge is not affiliated with them, and they neither endorse nor sponsor it.

Early access

Early access to Circuit Forge, or a tool like it for your own process?

Circuit Forge is not yet publicly available. Tell us what you are working on. We will get in touch when a preview version fits your use.

In development. Not yet publicly available. For Windows, macOS and Linux.

Request early access [email protected]

Circuit Forge: The AI-native SPICE simulator

Why it exists

Our own solver core in Rust

AI with tools

Schematic, simulation, analysis

Reproducible to the byte

The loop

Schematic

Simulation

Analysis

AI-native

One request, step by step

Request

Propose a contract

Accept the contract

Propose a circuit

Eight checks

Measure

Release

34 tools, none of them edits the design

D Simulate 11 tools

P Propose 5 tools

D Read and ask 18 tools

Where your data goes

Requirements as a file

Three temperatures, one verdict

A lucky sample certifies nothing

Buildable values or an honest no

A solver that tells you what it did

Six stages, each one logged

Newton

GMIN stepping I

GMIN stepping II

Source stepping

Homotopy

Pseudo-transient

Failures with instructions

No DC path to ground

Refuse instead of quietly ignoring

A partial result instead of nothing

The phase margin trap

Conditionally stable

Same input, same bytes

One sweep, two runs

Mixed-signal and firmware

One byte there and back

Technology and status

Frequently asked questions

What is Circuit Forge?

What does AI-native mean in Circuit Forge?

Does the AI compute the simulation?

Can I use Circuit Forge yet?

Which netlists does Circuit Forge read?

Where does my circuit data go?

Is a verified design guaranteed to work?

Early access to Circuit Forge, or a tool like it for your own process?

Simulate 11 tools

Propose 5 tools

Read and ask 18 tools