Building the software stack for fault-tolerant neutral atom computers
We recently announced our roadmap for Libra: 256 logical qubits on more than 10,000 physical qubits, a megaquop system planned for 2028, with a gigaquop system following in 2028/29.
QuEra quantum roadmap
The path to fault-tolerant quantum computing
- Launched 2022AquilaNISQ system
- Launched 2025GeminiNISQ system & QEC testbed
- Launching 2028LibraMegaquop fault tolerant
- Coming 2028/29Next GenGigaquop fault tolerant
Three orders of magnitude inside about a year deserves a word of explanation. A gigaquop machine runs a thousand times more reliable operations than a megaquop one, but it is not a thousand times the machine: the next-generation system is 1,000+ logical qubits on more than 20,000 physical qubits, roughly four times the logical width. The rest of the factor comes from logical fidelity, 99.9999% to 99.9999999%. Once a machine is fault-tolerant, buying three more orders of magnitude in logical error rate is a matter of QEC code and architecture design, and those are an architecture and software problem as much as a hardware one.
A fault-tolerant neutral-atom computer is not a bigger version of the machine we run today. It is a distributed, real-time system in which quantum operations, atom movement, measurement, decoding, loss handling, and classical decisions all happen at once and all depend on each other. If the hardware is going to be useful the day it arrives, the software has to be ready for it before then.
That is what we are turning Bloqade into: one stack to program, compile, emulate, verify, and operate a fault-tolerant neutral-atom computer. This post is how we see the challenges and how we envision the stack we want to build.
What changes at fault-tolerant scale?
Movement becomes part of the program
Reconfigurability is the headline feature of a neutral-atom platform. Instead of living with a fixed coupling graph, we move atoms coherently during the computation and create interactions where we want them. Experiments have already used this for dynamic, non-local connectivity and highly parallel transport.[1]
The flexibility does not come for free: it moves the complexity into software. A compiler may have to synthesize atom movement from a circuit, while a lower-level programmer may want to write that movement down directly. And at fault-tolerant scale, some of those decisions depend on measurements that only exist while the program is running.
So atom movement cannot be just a routing pass hidden inside the compiler. It is part of what the program does at runtime. What should the programming model expose? What should the compiler infer? And what has to stay a runtime decision? Those are some of the questions we need to answer in a fault-tolerant software stack.
The machine becomes asynchronous
Researchers from Harvard and MIT recently kept a coherent array of more than 3,000 atoms running continuously for over two hours, loading fresh atoms into it as it ran.[2]
Reloading is one such asynchronous subroutine, and there are many more. Decoding, atom-loss detection, state preparation, and magic-state factories all run on their own timelines and trigger their own control paths. A magic-state factory is not just a circuit diagram: it is a subsystem that produces a resource, and its output may succeed, fail, wait in a queue, or be consumed by another part of the computation. QuEra’s recent logical magic-state-distillation experimental demonstration is a first concrete look at one.[3]
Anyone who has written concurrent classical code knows how quickly this gets out of hand. The quantum version is no different, and neither is the fix: languages, compilers, and runtimes need explicit ways to talk about events, dependencies, feedback, and failure.
More is different[4]
Libra is planned for more than 10,000 physical qubits carrying 256 logical qubits. No quantum software stack has driven a fault-tolerant machine that big yet, ours included.
At 100 physical qubits you can still get away with thinking of a quantum program as a static circuit with little structure in its layout or control logic. At 10,000 you cannot. Programs get wider, run for longer, and expose far more parallelism. Compiling them takes careful co-design with the machine architecture. Verification changes too: some behavior gets too expensive to check by emulation, and some of it cannot be checked that way at all. That is what moves formal verification and compiler analysis from nice-to-have to load-bearing.
The stack we want to build
We want a progressive stack of languages for programming neutral-atom computers, and we want Bloqade to cover the whole path: from applications and logical programs, through architecture-aware compilation and real-time execution, down to physical models of AOD–SLM arrays.
A digital twin at every abstraction level
Alongside the Libra-class machine, we are releasing our digital twin of it piece by piece, at each level of abstraction: large-scale logical circuits, noisy physical circuits with their controllers, and AOD–SLM arrays.
An emulator is more than its circuit
Emulating hardware faithfully takes more than a circuit simulator. The quantum effects, the control system, the optics, and the decoding runtime have to be modeled as one system, because that is what they are on the machine.
Our most recent release, the Pauli Propagation Virtual Machine (PPVM), is the circuit-level part of that effort. PPVM puts several techniques behind one instruction set, each with its own use cases and tradeoffs: Pauli propagation, generalized tableaus, and mixtures of tableaus. It runs them on a virtual machine that understands classical control flow. That combination is what lets us emulate quantum hardware together with the controllers and decoding runtime that operate it. Check it out in a more detailed blog, Introducing PPVM: A Step Toward a Quantum Digital Twin.
A digital twin is useful long before the final hardware exists. It lets us address the practical questions that emerge at this scale: Can a target machine satisfy the latency requirements of its decoders? How does a protocol behave when an atom is lost halfway through it? Will a scheduling strategy remain effective under realistic transport constraints? Can we verify that the controller and the quantum program agree on what state the machine is in?
The closer the software model gets to the complete system, the earlier we can find architectural mistakes, and the cheaper they are to fix.
Compiler, architecture, and hardware co-design
One cannot design a compilation algorithm in isolation from the architecture. The architecture decides what the compiler is allowed to do, and how well atoms can be routed at runtime.
We recently introduced the lane architecture and its compiler for our Gemini-class testbed. Much like designing a silicon chip, we lay out atom movement together with the Steane-code[5] layout of the neutral-atom array, with the calibration budget in the room from the start. The technical details are in an upcoming paper, and we will be presenting the Gemini architecture at CEVNAC 2026.
Co-design also means being honest about what a restriction costs. A lane architecture publishes a finite set of pre-calibrated transports and asks programs to compose their moves out of those, instead of synthesizing an arbitrary trajectory per move, the abstraction that existing neutral-atom compilers target.[6,7] The upside is that every move the machine can execute has been characterized. The cost is that composing a move out of lanes takes more hops than flying the atom straight there.
Atom transport
The lane architecture
a Arbitrary moves
every move needs its own calibration
b Composed fixed lanes
small calibrated lane set, all-to-all by hopping
- lattice site
- source atom
- target site
- stop between hops
- fixed lane
- arbitrary move
- lane hop
- Calibration
- aevery source–target pair
- bthe fixed lane set only
- Execution
- a1 hop
- b2 hops
- Fidelity
- two calibrated lane moves beat one uncalibrated arbitrary move
Whether that trade is worth taking comes down to a number nobody has measured yet: how much fidelity an uncalibrated arbitrary move really loses. So rather than guess at it, we swept it. The baseline is ZAC[8], a compiler for zoned architectures under the arbitrary-move abstraction, run on the QASMBench[9] circuits from its own evaluation. When the calibration overhead is not enough to make up for the extra hops, the lane architecture is ahead. In reality, the calibration is not free, so most of the time the lane architecture is ahead.
Lane architecture vs. arbitrary moves
How expensive does an uncalibrated move have to be before fixed lanes win?
ε is the fidelity penalty an uncalibrated arbitrary move pays; each circuit's break-even ε is where lanes and the baseline reach equal circuit fidelity. Drag the threshold: marks to its left are circuits where lanes are already ahead.
- All-to-all — a bus for every rigid shift — the densest lane set
- Dense H/V — straight shifts and diagonals only
- Hypercube — log-diameter — the sparsest, so the most hops per move
Preliminary, and compiler-dependent. The lane side is compiled with deliberately simple strategies: greedy atom placement and a plain depth-first search for routing. These thresholds therefore measure today's compiler as much as the architecture, and they should be expected to move as fixed-lane placement and routing algorithms improve.
At 2% per uncalibrated move, 7 of 18 circuits have already broken even in favor of fixed lanes.
All 18 circuits · lanes ahead at 2%
How break-even is computed
- Reading the plot
- Only the horizontal position carries data. The two dense vocabularies are identical to six digits on several circuits, so wherever two vocabularies break even at the same penalty their marks are nudged apart vertically to keep both countable. Composing a move out of lanes takes more hops than flying an atom straight to its destination, so at ε = 0, where every baseline move pattern is perfectly calibrated, the baseline is ahead on every circuit here; the trade only starts to pay once an uncalibrated move costs something.
- Lane vocabularies
- All-to-all publishes a bus for every rigid (Δcol, Δrow) shift. It is maximally connected, and the largest lane set to calibrate. Dense H/V is parity-split rigid horizontal and vertical shifts plus diagonals, O(n_col²) lanes. Hypercube is a log-diameter column hypercube, the sparsest vocabulary, so the most hops per move.
- Baseline
- ZAC, a zoned-architecture compiler for the arbitrary-move abstraction: transport is specified coordinate-to-coordinate, with placement and routing chosen freely subject only to geometry. Circuits are the QASMBench programs from ZAC's own evaluation, 14–98 qubits, compiled through both toolchains.
- What ε is
- Cross-tone compensation depends on absolute tone frequencies, so calibration does not transfer between translated copies of a move pattern. A baseline that skips pattern-specific calibration therefore executes uncompensated transport; ε is the fidelity penalty each such move pays. Every lane move is calibrated by construction, so the lane architecture never pays it. No measured value for ε is available yet, which is why it is swept rather than fixed.
- Break-even
- Gate error is an identical factor on both sides and cancels, so the model prices transport only. Writing Δ for the lane architecture's log-fidelity deficit at ε = 0 and m for the number of uncompensated baseline moves, the two sides are equal at
ε = 1 − exp(Δ / m). Below that the baseline is ahead; above it the lane architecture is. - Why bigger circuits break even later
- Break-even rises with circuit size: composing lanes costs more hops as programs get wider, so the baseline's uncalibrated move has to be dearer before the vocabulary pays for itself. The two Ising circuits are the instructive outlier for the hypercube vocabulary: very few baseline move instructions (12 and 21), but very wide parallel ones, which a sparse log-diameter lane set has to serialise.
- Compiler maturity
- Break-even is not a property of the two architectures alone; it is a property of the compilers that target them. The lane results here come from deliberately simple strategies: atoms are placed greedily, and routing is a straightforward depth-first search over the lane graph. Better placement and routing compose the same move in fewer hops, which shifts these thresholds; the numbers should be read as a snapshot of the current compiler, not as a fixed property of fixed-lane hardware.
- Status
- Preliminary numbers from work in progress; the architecture, the fidelity model and this sweep are described in full in the upcoming paper. Compiler and architecture generator live in bloqade-lanes.
Show every number
| Circuit | Qubits | Baseline moves | All-to-all | Dense H/V | Hypercube |
|---|---|---|---|---|---|
| Bernstein–Vazirani bv_n14 | 14 | 27 | 0.8% | 0.8% | 2.2% |
| Quantum Fourier transform qft_n18 | 18 | 131 | 1.2% | 1.4% | 3.8% |
| Bernstein–Vazirani bv_n19 | 19 | 36 | 1.4% | 1.7% | 3.3% |
| W state wstate_n27 | 27 | 77 | 1.6% | 1.5% | 3.4% |
| Binary multiplier multiply_n13 | 13 | 55 | 1.7% | 1.6% | 3.1% |
| Cat state cat_n22 | 22 | 43 | 1.7% | 1.7% | 4% |
| GHZ state ghz_n23 | 23 | 45 | 1.8% | 1.8% | 3.1% |
| SECA seca_n11 | 11 | 88 | 2.2% | 2.2% | 3.6% |
| Swap test swap_test_n25 | 25 | 124 | 2.2% | 2.2% | 4.7% |
| Bernstein–Vazirani bv_n30 | 30 | 37 | 2.3% | 2.8% | 4.4% |
| Quantum Fourier transform qft_n29 | 29 | 243 | 2.4% | 2.7% | 8.1% |
| Cat state cat_n35 | 35 | 69 | 2.5% | 2.6% | 6.1% |
| GHZ state ghz_n40 | 40 | 79 | 2.7% | 3.3% | 6.5% |
| Quantum k-NN knn_n31 | 31 | 151 | 2.9% | 2.9% | 8.6% |
| Ising model ising_n42 | 42 | 12 | 3.9% | 4.1% | 61% |
| GHZ state ghz_n78 | 78 | 160 | 5% | 7.4% | 15% |
| Bernstein–Vazirani bv_n70 | 70 | 75 | 5.2% | 5.3% | 12% |
| Ising model ising_n98 | 98 | 21 | 7% | 13% | 87% |
Better placement and routing compose the same move in fewer hops, so we expect these thresholds to fall as compilation for fixed-lane architectures improves. The full paper will have a more complete evaluation and a discussion of how to get there.
Discuss these ideas at CEVNAC 2026
None of these problems belong to one company or one software project. Together with the neutral-atom community, we are organizing the first Workshop on Compilation, Emulation and Verification of Neutral Atom Computing (CEVNAC 2026), co-located with IEEE Quantum Week in Toronto.
We want CEVNAC to put hardware researchers, compiler developers, language designers, verification experts, and application scientists in the same room, and to start a community around these new and exciting challenges. If you are working on any part of this stack, we would like to hear from you.
Outlook
Fault-tolerant neutral-atom computers will be dynamic systems: atoms move, resources are produced and consumed, errors are decoded, and classical decisions shape the computation while it runs.
We are building Bloqade so that this complexity stays manageable, by connecting applications, architecture, hardware, and digital twins in one stack. Our technology roadmap points at 2028.
Authors
Xiu-Zhe Luo, Phillip Weinberg and Shengtao Wang.
Acknowledgements
We thank Wan-Hsuan Lin.
Cite this post
@misc{luo2026building,
author = {Xiu-Zhe Luo and Phillip Weinberg},
title = {Building the software stack for fault-tolerant neutral atom computers},
howpublished = {Bloqade blog, QuEra Computing},
year = {2026},
month = {aug},
url = {https://bloqade.quera.com/blog/building-the-software-stack-for-fault-tolerant-neutral-atom-computers/},
}References
- D. Bluvstein et al., “A Quantum Processor Based on Coherent Transport of Entangled Atom Arrays,” Nature 604(7906), 451–456 (2022). ↩
- N.-C. Chiu et al., “Continuous Operation of a Coherent 3,000-Qubit System,” Nature 646(8087), 1075–1080 (2025). ↩
- P. S. Rodriguez et al., “Experimental Demonstration of Logical Magic State Distillation,” Nature 645(8081), 620–625 (2025). ↩
- Pun intended. P. W. Anderson, “More Is Different,” Science 177(4047), 393–396 (1972). ↩
- A. M. Steane, “Multiple-Particle Interference and Quantum Error Correction,” Proceedings of the Royal Society of London. Series A: Mathematical, Physical and Engineering Sciences 452(1954), 2551–2577 (1996). ↩
- D. B. Tan, D. Bluvstein, M. D. Lukin, and J. Cong, “Compiling Quantum Circuits for Dynamically Field-Programmable Neutral Atoms Array Processors,” Quantum 8, 1281 (2024). ↩
- D. B. Tan, W.-H. Lin, and J. Cong, “Compilation for Dynamically Field-Programmable Qubit Arrays with Efficient and Provably Near-Optimal Scheduling,” Proceedings of the 30th Asia and South Pacific Design Automation Conference 921–929 (2025). ↩
- W.-H. Lin, D. B. Tan, and J. Cong, “Reuse-Aware Compilation for Zoned Quantum Architectures Based on Neutral Atoms,” 2025 IEEE International Symposium on High-Performance Computer Architecture (HPCA) 127–142 (2025). ↩
- A. Li, S. Stein, S. Krishnamoorthy, and J. Ang, “QASMBench: A Low-Level Quantum Benchmark Suite for NISQ Evaluation and Simulation,” ACM Transactions on Quantum Computing 4(2), Article 10 (2023). ↩