"Hardware-agnostic" is a term that gets applied to quantum software tools loosely enough to mean almost anything. In this article I want to be specific about what it means in the context of fault-tolerant circuit compilation, where the claim is technically non-trivial and where the failure modes of generic tools are concrete and measurable.
The short version: a fault-tolerant circuit compiler is hardware-agnostic when it can compile the same logical circuit to physically correct, efficiency-optimized schedules on heterogeneous hardware platforms — not by ignoring device differences, but by exploiting them. A compiler that treats every backend as a generic gate set and topology is not hardware-agnostic; it is hardware-blind. The difference matters for qubit overhead, T-gate factory scheduling, and decoder weight configuration.
What the DeviceSpec captures
QECSync represents hardware in a DeviceSpec object. This is a structured data type that captures the properties a fault-tolerant compiler actually needs:
- Connectivity graph. Which qubits are coupled to which, and with what gate type. A superconducting device in heavy-hex layout has a different connectivity graph than a square grid transmon device or a trapped-ion all-to-all system. Surface-code plaquette measurements require 4-qubit CNOT sequences, and their routing depends directly on which physical qubits can interact.
- Native gate set. A superconducting device may offer CX (CNOT), ECR, or RZX as its native two-qubit gate. A trapped-ion device natively implements Mølmer-Sørensen (XX) interactions. The compiler decomposes logical gate sequences into the device's native gates — this decomposition is different for each backend.
- T1 and T2 per qubit. Coherence times determine how many syndrome cycles a qubit can survive idle. If T2 at qubit Q₁₂ is 40 µs and your syndrome cycle is 5 µs, you have at most 8 idle cycles before decoherence dominates. Circuit scheduling — the order and timing of stabilizer measurements — must respect these constraints.
- Per-gate and per-qubit error rates. Two-qubit gate fidelity from randomized benchmarking, single-qubit gate fidelity, and readout assignment error matrices feed directly into the decoder's edge weight computation.
- Measurement speed and mid-circuit measurement support. Syndrome extraction requires mid-circuit measurement of ancilla qubits. Not all current platforms support fast mid-circuit measurement. Where it is available, the syndrome cycle time (and thus real-time decode latency budget) is limited by measurement time, not gate time.
The same logical circuit, three different physical schedules
Consider a simple logical circuit: prepare a logical |0⟩ state, apply a logical CNOT between two logical qubits, apply a logical T gate, measure. This is a concrete circuit with specific resource requirements. Here's how QECSync compiles it differently across three backend types.
Superconducting transmon (heavy-hex lattice, d=5)
The heavy-hex topology — used by multiple current superconducting systems — has a reduced connectivity compared to a full square grid. Not every pair of neighboring qubits is directly coupled. This affects plaquette measurement circuit depth: some stabilizer circuits require 6 CNOT steps rather than 4 due to routing constraints around degree-2 nodes in the coupling graph.
QECSync's compiler maps the surface-code plaquette measurement circuit to the available coupling edges, schedules the CNOT steps to avoid idle time on high-T2 qubits, and inserts dynamical decoupling sequences on qubits that idle for more than 2 syndrome steps.
T-gate implementation via magic state distillation: the compiler analyzes the T-count (1 T-gate in this example), schedules 1 distillation factory at code distance 5 with qubit overhead of 49 physical qubits per factory, and routes the |T⟩ magic state injection into the logical circuit after distillation rounds are complete.
Trapped-ion (all-to-all, d=5)
Trapped-ion all-to-all connectivity removes the routing constraints of heavy-hex. Any qubit can interact with any other qubit via the Mølmer-Sørensen gate. The compiler does not need to insert SWAP chains or routing steps — plaquette measurements are scheduled in the optimal 4-CNOT depth.
However, Mølmer-Sørensen gates are slower than superconducting CNOT gates (typically 100–500 µs vs 50–200 ns). A syndrome cycle on a trapped-ion device is therefore 100–1000× longer than on a superconducting device. This makes real-time decode latency a non-constraint — even MWPM at code distance 9 decodes in under 5 ms, well within a 50 ms syndrome cycle.
Because coherence times are long (>1 s), the compiler's scheduling objective shifts: minimize syndrome circuit depth (number of Mølmer-Sørensen gate layers) rather than minimize idle time. The resulting schedule has fewer gates but takes longer wall-clock time.
Neutral atom (reconfigurable 2D array, d=3)
Reconfigurable neutral atom arrays offer a unique property: qubits can be physically moved between gate zones and measurement zones during a circuit. This enables mid-circuit measurement in some architectures and allows flexible plaquette layouts that would require SWAP chains on a fixed-connectivity device.
At distance 3, the qubit overhead is modest (17 physical qubits per logical qubit). The compiler maps the stabilizer circuit to the available gate zone layout, schedules atom transport steps between syndrome rounds, and accounts for the transport time (typically 10–50 µs) in the idle budget.
T-gate factory scheduling: the most hardware-sensitive step
Magic state distillation — the protocol for implementing fault-tolerant T-gates — is where hardware differences have the largest impact on qubit overhead. A T-gate requires preparing a resource state |T⟩ = |0⟩ + e^{iπ/4}|1⟩ with logical fidelity sufficient to contribute less than the target logical error budget. The distillation factory must run multiple rounds of error correction at a code distance chosen to meet the target fidelity.
The number of factory instances, the code distance of each factory, and the distillation protocol (15-to-1, 20-to-4, Reed-Muller) all depend on the physical error rate and the target logical error per T-gate. A device at p=0.001 physical error rate can run smaller factories at lower code distance than a device at p=0.005. QECSync's compiler determines the factory configuration automatically from the DeviceSpec error rates and the target logical error budget specified at compile time.
What "hardware-agnostic" does not mean
Hardware-agnostic compilation does not mean the same compiled output works on any hardware. The compiled output is a device-specific physical schedule — a specific sequence of physical gate operations, measurement cycles, and error correction steps tailored to that backend's gate set, connectivity, and noise parameters. The logical circuit is hardware-agnostic; the compiled output is not.
This distinction is important for researchers running experiments on multiple platforms. QECSync will compile your logical circuit separately for each target device, producing different physical schedules. The logical behavior is the same; the physical implementation is adapted to each device's constraints.
Reading the compiler output: resource estimates
Before executing a compiled circuit, the compiler's resource estimate output is worth examining. The CompileResult object includes physical qubit count, T-gate count, number of distillation rounds, expected logical error rate, and estimated circuit depth in physical gate cycles. These numbers tell you whether your experiment is feasible on your current device — if the required physical qubit count exceeds your device's qubit count, you need to reduce code distance or use a shallower circuit.
See the Circuit Compiler page for the full compile-time parameter reference, and the quickstart guide for a working example from logical circuit to compiled schedule in 10 lines of Python.