- Hardware
Qubit Connectivity
The graph specifying which pairs of qubits on a quantum processor can directly interact via two-qubit gates, determining how circuits must be compiled to run on that hardware.
Every physical quantum processor has a connectivity graph: a map of which qubits are physically coupled to which others. A two-qubit gate can only be applied directly between connected pairs. When an algorithm requires a gate between two qubits that are not neighbors on the hardware graph, the compiler must insert SWAP gates to route the logical qubit’s state through intermediate physical qubits until it reaches a location adjacent to its target. Each SWAP costs three CNOT gates. On noisy hardware, where every gate introduces error, SWAP overhead is a direct hit to algorithm fidelity.
Connectivity is therefore not a minor implementation detail: it determines how efficiently any given algorithm compiles to a given chip, and it shapes the hardware design decisions made by every major quantum computing company.
The details
IBM’s heavy-hex topology is the dominant connectivity pattern on IBM Quantum processors. It is a variant of a hexagonal lattice where each qubit connects to at most two or three neighbors. Heavy-hex was chosen because it minimizes the number of two-qubit-gate-adjacent pairs per qubit, which reduces unwanted crosstalk errors. The tradeoff is low connectivity: many circuits require significant SWAP overhead on heavy-hex.
Google’s quantum processors (Sycamore and its successors) use a square grid topology where each interior qubit connects to four neighbors. This gives higher average connectivity than heavy-hex and lower SWAP overhead for many circuit patterns, but also higher crosstalk risk.
Trapped-ion processors (IonQ, Quantinuum) implement all-to-all connectivity: any qubit can directly gate any other qubit, because ions in a linear chain share collective phonon modes that mediate long-range interactions. This eliminates SWAP overhead entirely. The cost is that gate time grows with the number of ions (more modes to manage), limiting qubit count relative to solid-state platforms.
Neutral atom platforms achieve reconfigurable connectivity by physically moving atoms between operations, enabling dynamic topology changes that approximate all-to-all connectivity over the course of a computation.
Qiskit’s transpiler automates circuit compilation to hardware connectivity using a sequence of passes: layout (mapping logical to physical qubits), routing (inserting SWAPs), and optimization (reducing gate count). Here is an example compiling a 3-qubit circuit to IBM’s heavy-hex topology:
from qiskit import QuantumCircuit, transpile
from qiskit_ibm_runtime.fake_provider import FakeKyotoV2
# A circuit that requires non-adjacent interactions
qc = QuantumCircuit(3)
qc.h(0)
qc.cx(0, 2) # qubits 0 and 2 may not be adjacent on heavy-hex
qc.cx(1, 2)
# Transpile to the fake Kyoto backend (heavy-hex topology)
backend = FakeKyotoV2()
transpiled = transpile(qc, backend=backend, optimization_level=3)
print(f"Original gates: {qc.count_ops()}")
print(f"Transpiled gates: {transpiled.count_ops()}")
# The transpiled circuit typically contains additional SWAP gates
The SWAP overhead scales poorly with circuit depth and qubit count on sparse graphs. For algorithms with high entanglement (like quantum phase estimation or the QFT over many qubits), the routing overhead on a heavy-hex processor can multiply the two-qubit gate count by 3-5x, turning a circuit that would be feasible into one that is too noisy to produce useful results.
Why it matters for learners
Qubit connectivity is the bridge between algorithm design and hardware reality. Algorithms described in terms of arbitrary-connectivity circuits often look deceptively simple. Adding connectivity constraints, and the SWAP gates they require, frequently changes whether an algorithm is executable on today’s hardware.
Understanding connectivity also explains several important patterns in the NISQ literature: why algorithms are often benchmarked on circuits that happen to match hardware topology, why circuit depth is not the only relevant complexity measure, and why the same algorithm can have very different performance profiles on IBM versus Google versus ion trap hardware.
For learners using Qiskit, the transpiler is the practical interface between the circuit you write and the circuit that actually runs. Understanding what the transpiler does, and why it sometimes inflates gate counts dramatically, is essential for interpreting hardware results.
Common misconceptions
Misconception 1: More connectivity is always better. Higher connectivity increases two-qubit coupling, which increases crosstalk. IBM’s choice of heavy-hex was a deliberate fidelity tradeoff: fewer connections mean fewer crosstalk-induced errors, even if more SWAPs are needed. The optimal connectivity depends on the gate error model and the target circuit family.
Misconception 2: Transpilation is just a compiler detail that does not affect results. On noisy hardware, SWAP gates add real errors. A circuit that requires 10 additional SWAP gates (30 additional CNOTs) on one topology versus zero SWAPs on another will produce substantially different output distributions. Connectivity-aware algorithm design and circuit optimization are not optional for getting useful results from current hardware.
Misconception 3: All-to-all connectivity makes trapped-ion systems strictly better for algorithms. All-to-all connectivity eliminates SWAP overhead but does not eliminate all routing cost. As ion count grows, long-range gates become slower and more error-prone due to mode crowding. For small circuits, ions dominate on connectivity. For large circuits, the tradeoffs become more complex and hardware-specific.