Transpilation and Hardware-Aware Compilation

What the transpiler does

An abstract circuit assumes any gate anywhere. Hardware offers a fixed menu: a small native gate set, a specific connectivity graph, calibrated control pulses, and readout on particular lines. Transpilation rewrites the first into the second — decomposing gates the device does not have, inserting routing operations so qubits that must interact end up adjacent, scheduling the result, and folding measurements into the layout the readout chain expects.

Each of those steps can change depth, two-qubit gate count, and error exposure while leaving the circuit's meaning untouched. Hence the working rule: never evaluate a hardware claim from the abstract circuit alone. Ask for the pre-transpilation circuit, the post-transpilation circuit, the target assumptions, and the resource deltas between them.

Two formulas worth keeping

The first prices connectivity:

If two qubits must interact but are not neighbors on the device, the transpiler pays the distance in swaps or equivalent operations. On sparse topologies, routing depth can dwarf the algorithm's own.

The second prices the result, as a teaching model:

Every gate carries an error rate, and survival multiplies. Two-qubit gates usually dominate the error budget, so the two-qubit count after transpilation — not the gate count in your textbook diagram — is the number to watch. Real device models are richer than this product, but the direction of concern is exactly right.

Worked example: one entangling operation, mapped down

Start with a requirement stated abstractly:

apply one reliable two-qubit entangling operation

Now map it down the stack:

• the target gate set,
• the connectivity graph,
• the control mechanism,
• the readout assumptions,
• the calibration state,
• the compiled circuit depth,
• the two-qubit gate count, and
• the expected error exposure.

If the transpiler inserts routing to satisfy the topology, the algorithm is unchanged and the execution cost is not. That gap — invisible in the abstract circuit, decisive on the device — is often the difference between a demo that survives hardware and one that stays in the slide deck.

Where the analysis fails

The first trap is treating transpilation as cosmetic formatting — pretty-printing for a picky machine. It is compilation under physical constraints, and it preserves meaning while changing feasibility. Those are different guarantees, and only one of them is free.

The second trap is comparing SDKs or devices using logical circuit diagrams alone. Two targets can execute the same abstract circuit with very different compiled depths and error risks. A comparison that never looks below the diagram compares intentions, not machines.

The engineering view

This is compiler work, and it deserves a compiler engineer's artifact. A serious circuit review records:

• abstract width and depth,
• target gate set and topology,
• post-transpilation width and depth,
• one-qubit and two-qubit gate counts,
• routing overhead,
• measurement mapping, and
• assumptions and date.

Do not stop at one optimization setting. Compare at least two compilation choices or target assumptions: one setting may shrink depth while inflating the two-qubit count; another may preserve layout while adding idle time. The right answer depends on the device's error profile and the workload's objective, so record the choice and the reason.

One warning from the field: the most common integration bug is a convention mismatch — bit order, qubit order, measurement-register order, or control-target direction. Compilation does not excuse losing semantic equivalence. Keep a small known circuit, such as Bell preparation, as a regression test and run it through every new target before trusting larger compiled workloads.

What this buys you in diligence

When a partner shows a low-depth abstract circuit, ask for the transpiled depth on the actual target. If routing and two-qubit errors dominate, the claim may remain mathematically correct while becoming commercially weak — and you want to know that before the term sheet, not after.

A strong partner can show both circuits, explain why the added gates are necessary, and connect them to the error budget. If the compiled circuit is treated as proprietary with not even summary resource counts shared, the claim cannot be evaluated, and an unevaluable claim should be priced as an unproven one.

Exercise

Write a transpilation depth memo. Take a small circuit and compile it — with a tool or by hand — against two different connectivity assumptions.

• Record: abstract depth, routing depth, effective depth, gate set, topology, and two-qubit gate count for each target.
• Write: a memo that applies the effective-depth formula and explains the practical risk using the error-budget model.
• Check: state explicitly which circuit properties stayed equivalent and which feasibility properties changed.
• Decide: write one sentence naming the safer target and the evidence that could change your answer.

Check your understanding

Compare pre- and post-transpilation depth, gate counts, and connectivity overhead for a small circuit. A passing answer distinguishes equivalence (the unitary is the same) from feasibility (the error budget is not).

Oral defense: explain to a software colleague why "the circuit is correct" and "the circuit will survive the device" are separate claims that need separate evidence.

If you get stuck

If you find yourself treating transpilation as formatting, or writing reviews that omit topology entirely, revisit Chapter 22 (Circuit Cost: Depth, Width, Gate Set, Connectivity) — this chapter is that chapter's cost vocabulary applied to a real target, and it reads much easier with the vocabulary in hand.