Case Study: Choosing a Code for a Given Hardware Architecture
Executive Summary
There is no best quantum error-correcting code. There are codes matched to hardware and codes that are not, and the mismatch is usually about connectivity — which stabilizers you can measure without shuttling qubits across the chip.
This case study evaluates four codes against three real hardware architectures, and the rankings invert completely between them. The exercise makes concrete a point that resource estimates usually bury: code choice and hardware architecture are a joint decision, not sequential ones.
Skills applied
- Mapping stabilizer support onto hardware connectivity graphs (§24.14).
- Weighing rate, threshold, locality, and decodability jointly.
- Estimating syndrome-extraction circuit cost per architecture.
- Recognizing co-design between code and hardware.
Phase 1: The candidates
| Code | Params | Stabilizer weight | Connectivity needed | Threshold |
|---|---|---|---|---|
| Steane | $[[7,1,3]]$ | 4 | All-to-all within block | ~$10^{-4}$ |
| Surface | $[[d^2,1,d]]$ | 4 | 2D nearest-neighbour | ~$10^{-2}$ |
| Colour | $\sim[[d^2,1,d]]$ | 6 | 2D, degree-3 lattice | ~$5\times10^{-3}$ |
| Gross (qLDPC) | $[[144,12,12]]$ | 6 | Long-range (degree 6) | ~$7\times10^{-3}$ |
Phase 2: Architecture A — superconducting heavy-hex
Properties: 2D planar, degree ≤ 3, nearest-neighbour only, no long-range couplers, gate error $5\times10^{-3}$.
| Code | Verdict |
|---|---|
| Steane | Poor. Weight-4 stabilizers on 7 qubits need near-all-to-all connectivity within the block; routing SWAPs dominate extraction, and each SWAP is an error opportunity. Threshold is also two orders of magnitude below the device's error rate. |
| Surface | Excellent. Designed for exactly this: weight-4 stabilizers on a square lattice, every check local. Heavy-hex requires a modified layout (flag qubits) but works. Threshold ~1% comfortably above $5\times10^{-3}$. |
| Colour | Fair. Weight-6 stabilizers mean deeper extraction circuits; threshold is lower. Compensating advantage: more transversal gates. |
| Gross | Poor on this hardware. Requires degree-6 connectivity with long-range links that heavy-hex does not provide. |
Winner: surface code, decisively — which is why every major superconducting roadmap is built on it.
Phase 3: Architecture B — trapped ions with all-to-all connectivity
Properties: any qubit can interact with any other in a chain; gate error $10^{-3}$; gates are slow (~100 μs); qubit counts modest (tens).
| Code | Verdict |
|---|---|
| Steane | Excellent. All-to-all connectivity makes weight-4 stabilizers free — no routing at all. Its full Clifford transversality is a major advantage. 7 qubits per logical fits a small register. |
| Surface | Wasteful. Its whole design assumption is limited connectivity. Spending $d^2$ qubits to respect a 2D locality constraint the hardware does not have is pure overhead. |
| Colour | Good. Weight-6 is fine with all-to-all; full transversality of the Clifford group plus, for some variants, transversal $T$ in 3D. |
| Gross | Good in principle, but 144 qubits exceeds most current ion registers. |
Winner: Steane or colour code. The surface code — the default everywhere else — is actively the wrong choice here.
The inversion. Surface is best on architecture A and worst on B; Steane is worst on A and best on B. Neither code is better; they encode different assumptions about connectivity.
Phase 4: Architecture C — neutral atoms with movable tweezers
Properties: atoms physically relocatable during computation; effectively reconfigurable connectivity; gate error $3\times10^{-3}$; hundreds to thousands of atoms.
| Code | Verdict |
|---|---|
| Steane | Fine but low rate. |
| Surface | Works, but atom movement makes its locality constraint unnecessary. |
| Colour | Good. |
| Gross (qLDPC) | Excellent. Non-local checks are implementable by moving atoms into interaction zones. The 24× rate advantage over the surface code becomes accessible. |
Winner: qLDPC codes — which is precisely why the recent qLDPC results have driven so much interest in neutral-atom and shuttling-based architectures.
Phase 5: The joint decision
Summarizing:
| Heavy-hex SC | Trapped ion | Neutral atom | |
|---|---|---|---|
| Steane | ✗ | ✓✓ | ~ |
| Surface | ✓✓ | ✗ | ~ |
| Colour | ~ | ✓ | ✓ |
| Gross qLDPC | ✗ | ~ | ✓✓ |
Three conclusions.
- Code choice follows connectivity. Every ranking above is driven mainly by whether the hardware can measure the code's stabilizers without shuttling.
- Rate is a secondary criterion. The gross code's 24× rate advantage is worthless on hardware that cannot implement its checks. Rate only matters once locality is satisfied.
- This is co-design. Hardware architects choosing connectivity are choosing a code family, and code designers targeting a threshold are choosing an architecture. Roadmaps that list qubit counts without stating a code and connectivity model are underspecified.
Phase 6: Applying it
For a new architecture, work through:
- What is the connectivity graph? Degree, locality, reconfigurability.
- What is the physical error rate? This sets the minimum acceptable threshold, and codes with thresholds below it are excluded outright.
- Which codes have stabilizers embeddable in that graph without routing?
- Among survivors, compare rate — now, and not before.
- Check decoder availability. A code with no fast decoder is unusable regardless of parameters.
- Check logical-gate support. Transversality and lattice-surgery-style operations differ substantially between codes.
Steps 1–3 usually eliminate all but one or two candidates, which is why the field's apparent consensus on the surface code is better understood as a consensus on 2D superconducting hardware.
Discussion Questions
- The rankings invert completely between architectures. What does that say about "which code is best" as a question?
- Rate is ranked below locality and threshold. Construct a scenario where rate should dominate.
- Neutral-atom shuttling enables qLDPC codes. What does shuttling cost, and how would you decide whether it is worth it?
- If you were designing hardware today, would you target the surface code or design for qLDPC? Defend the choice.
Your Turn: Extensions
- Draw the heavy-hex lattice and attempt to embed Steane's stabilizers; count the SWAPs required.
- Compute physical qubits for 100 logical qubits at distance 11 under surface and gross codes.
- Research a specific hardware roadmap and identify which code its connectivity implies.
- Estimate the syndrome-extraction circuit depth for each code on each architecture.
Key Takeaways
- No code is universally best; rankings invert entirely with hardware connectivity.
- The surface code dominates 2D nearest-neighbour superconducting hardware and is a poor choice for all-to-all trapped ions, where Steane and colour codes excel.
- qLDPC codes offer large rate advantages but require non-local checks, making them a natural fit for reconfigurable neutral-atom architectures.
- Evaluate connectivity and threshold first; rate is only a meaningful criterion among codes the hardware can actually implement.
- Code and architecture are a joint design decision, and roadmaps that omit either are underspecified.