Fluxus · Superconducting EDA
The superconducting
design studio.
Fluxus designs the whole superconducting stack — transmon-resonator qubits and RSFQ single-flux-quantum logic — against fast surrogate models, with a calibrated confidence bound and a source label on every prediction. A browser studio and an HTTP API, built so the design loop is interactive instead of an overnight simulation queue.
What Fluxus is
One studio for two stacks.
Superconducting hardware splits into two worlds — analog cQED qubits and classical RSFQ logic — and they almost never share a tool. Fluxus puts both behind one interface: an analytic cQED oracle for transmon and resonator Hamiltonians, neural surrogates for qubit cells and RSFQ margins, and a verification kernel that attaches honest error bars to every answer.
Because the oracle, the surrogate, and any future EM backend speak one interface, swapping the ground truth — from closed-form physics to Palace / HFSS, from analytic RCSJ to full JoSIM corpora — changes the data the models train on, not the studio you work in.
Two design surfaces
Capabilities · the whole stack
Every feature, with the number behind it.
The full surface, scannable — qubit design, RSFQ verification, and the deep geometric-cell screener — each line carrying the metric that backs it. No call required: if it fits, the live demo and an API key are a click away.
Qubit design · cQED
metric
Hamiltonian prediction
f01 / α / fr / g / χ from geometry
Inverse design
target Hamiltonian → ranked cells
Frequency-collision yield
Monte-Carlo over fab scatter
RSFQ design & verification
metric
Analytic margins
functional verdict + bias / Ic bands
Assembled-chain margin
shared-rail window, whole circuit
Three-engine validation
one operating point
Process portability
one netlist, retargeted
ERSFQ / eSFQ bias
resistor vs zero-static sizing
One-click datasheet
characterize a cell in one call
Deep screening · RSFQ-JEPA
metric
Hierarchical JEPA surrogate
layout-aware geometric cells
Chain delay
222 held-out 2–7-cell chains vs JoSIM
DRV detection
from layout geometry, held-out cells
Ic / bias margins
JoSIM sweeps, held-out cells
Calibrated uncertainty
MC-dropout on every output
Chip-scale throughput
warm GPU batch
Trust · on every value
metric
Conformal intervals
split-conformal, per prediction
Source labels + abstention
which backend answered
Honest provenance
calibrated vs learned heads
Deep-engine figures are RSFQ-JEPA vs JoSIM on the ColdFlux SFQ5ee+ family; single-cell delay / current carry their stated RMSE, so for fast cells they read near the noise floor and are flagged — the screening grade, design-rule flags, and chip-scale batch are where the deep engine earns its keep. Suite figures are surrogate-vs-oracle, conformal-calibrated. Nothing here is fab-measured.
The studio · five desks
A design loop, not a simulation queue.
Each desk is a slice of the same API. Design a cell, screen a chip for collisions, invert toward a target, lay out and wire a block, and characterize RSFQ margins — all against surrogates fast enough to stay in the loop with you.
Design · Hamiltonian
01Live transmon-resonator cell designer. Drag seven geometry knobs — pad gap, width, height, junction Lⱼ, resonator length, coupling cap, substrate εᵣ — and read the dispersive-regime Hamiltonian (f01, anharmonicity, fr, g, χ) live, each with a calibrated conformal interval and a source label telling you which backend answered.
/api/qem · /api/inv
Chip · Yield
02Heavy-hex or square lattice with a per-qubit frequency-collision heatmap. A Monte Carlo over fabrication scatter implements all seven Hertzberg et al. (2021) collision rules and returns a yield rollup plus a yield-versus-frequency-spread curve — so you can see where a process node's frequency precision starts costing you working chips.
/api/chip · /api/yld
Inverse design
03Hand Fluxus a target Hamiltonian — f01 = 4.8 GHz, fr = 7.0 GHz — and it returns ranked candidate cells. The surrogate proposes across a screened design space; the analytic oracle disposes, re-solving every finalist so the candidates you see are verified, not just predicted.
/api/inv
Floorplan
04A hardware co-design canvas. Drag and wire real cells from a palette — quantum transmon-resonators alongside RSFQ JTL / splitter / DFF and a custom-netlist cell — and the inspector shows live per-cell surrogate health. Multi-select supports group moves and saved composite blocks; paste a raw .cir netlist and it is scored on the spot.
/api/cells · /api/floorplan/eval
RSFQ margins
05The single-flux-quantum desk characterizes cell margins two ways. The analytic Neural-SPICE oracle reproduces JoSIM's functional verdict and bias / Ic margin sweeps WITHOUT JoSIM or WSL installed; the graph surrogate gives a fast prediction that abstains when a netlist falls outside its trained envelope.
/api/spice/cell · /api/sfq/predict
Validation · measured
Measured, not asserted.
Every surrogate is benchmarked on a fresh 10,000-point sample it never saw in training, against the analytic oracle it learned from. The headline is the 95th-percentile relative error — the tail, not the average.
Predictions ship with split-conformal intervals calibrated to ≥89% empirical coverage at α = 0.1. The yield engine reproduces all seven Hertzberg et al. (2021) frequency-collision rules; the RSFQ engine reproduces JoSIM's verdict and margin bands exactly, with no JoSIM installed.
Surrogate vs. analytic oracle · 10k held-out
p95 rel. error
≥89%
conformal coverage at α = 0.1
7 / 7
Hertzberg (2021) collision rules
JoSIM-exact
RSFQ margins, WSL-free
* χ has a heavy relative-error tail near the dispersive poles inside the sampled envelope; median absolute error is the representative figure. Full card: surrogate-vs-oracle, regenerated per release.
Scope · honest by default
What Fluxus is — and isn't — today.
The in-house Fluxus stack is a v0 pipeline proof. Its surrogates are trained against closed-form cQED physics — Koch et al. (2007) for the transmon, Göppl et al. (2008) for the CPW resonator, standard dispersive coupling — and the analytic RCSJ branch validated against JoSIM for RSFQ. Every accuracy figure is surrogate-versus-oracle, not surrogate-versus-measurement.
Because the v0 oracle is already fast (~100k cells/s), the surrogate buys you the differentiable, abstaining design loop — not raw speed. The latency argument is the production path: when the ground truth is a Palace / HFSS solve that costs minutes per cell, the surrogate is what makes design-space exploration tractable at all.
Nothing in the Suite is fab-calibrated. Process-registry entries are literature-derived defaults with stated sources and confidence tags — order-of-magnitude anchors, not validated PDK data. We say so on every surface so you always know which backend answered.
Delivery · studio and API
Verify a chip's worth of cells before lunch.
Fluxus runs two ways from the same engine. The browser studio is the interactive design loop; the API and CLI are the batch surface — point them at a cell library and a PDK and you get propagation delay, switching margin, and design-rule compliance for every cell with a confidence bound, auto-flagging the low-confidence handful for a full SPICE check. Trained per process node on your reference simulator.
API + CLI · licensed per team
RSFQ circuit verification · MIT-LL SFQ5ee+
import cogitan
# verify a whole cell library in one batch
results = cogitan.verify(
path = "./layouts/sfq5ee+",
pdk = "mit-ll-sfq5ee+",
batch = True,
)
for cell, r in results.items():
print(
f"{cell:<14} {r.delay:>5.1f}
f" ± {r.sigma:.1f} ps {r.status}"
)$ cogitan verify ./layouts/sfq5ee+
SPLIT_v1_a 17.2 ± 1.4 ps ✓
SPLIT_v2_b 18.9 ± 1.1 ps ✓
DFF_x3_c 22.1 ± 5.8 ps → spice
AND2_v1_d 14.4 ± 1.6 ps ✓
...
─────────────────────────────────
1,000 cells 4.8s (SPICE: ~85 min)
997 pass · 3 → spice fallback
>1,000×
faster than SPICE per cell
2.1 ps
chain delay RMSE, held-out chains vs JoSIM
100%
DRV detection from layout, held-out cells
grouped split
no held-out cell seen at any training stage
Designing superconducting hardware?
Let's talk.
Whether it's qubit chips or RSFQ logic, if your design loop is bottlenecked on simulation we'd like to understand it — and train Fluxus on your process.
Get in touch