← Back to blog
4 min read Intermediate

From circuits to pulses: what happens between 'write code' and 'run on quantum hardware'

You write a quantum program as gates on qubits. The hardware runs microwave pulses and laser beams. The gap between these two is called compilation — and it determines whether your algorithm actually works.

compilationhardwareengineering

When you write a classical program, you don’t think about transistors. The compiler handles the translation from “high-level idea” to “electrical signals in silicon.” Quantum computing has the same problem, but the translation is harder and matters much more.

Here’s why.

The gap between theory and hardware

In a textbook, a quantum algorithm is described as a circuit: a sequence of operations (gates) applied to qubits. Something like “apply a Hadamard gate to qubit 1, then a CNOT between qubit 1 and qubit 2.”

The real hardware doesn’t understand “Hadamard” or “CNOT.” A superconducting quantum computer runs precisely timed microwave pulses. A trapped-ion machine fires specific laser sequences. The circuit description has to be translated into physical instructions the hardware can actually execute.

This translation — compilation — involves several steps, and each one can make or break your computation.

Step 1: Decompose into native gates

Every quantum chip has a small set of operations it can actually perform — its native gate set. IBM’s chips, for example, natively support a few specific rotations and one type of two-qubit gate.

Your algorithm might call for a CNOT, but the hardware natively runs a different two-qubit gate. The compiler has to rewrite your operation as a combination of native gates. This is like translating French into Spanish — the meaning is preserved, but the words (and the number of words) change.

Step 2: Map qubits to physical locations

Your algorithm says “qubit 1” and “qubit 5.” But on the actual chip, there are specific physical qubits at specific locations, each with different properties (some have better fidelity, some have longer coherence times).

The compiler decides which of your logical qubits goes on which physical qubit. Good placement puts frequently interacting qubits close together. Bad placement means more work later.

Step 3: Route around connectivity constraints

Here’s where it gets expensive. Most quantum chips only let neighbouring qubits interact directly. If your algorithm needs qubit 1 and qubit 50 to interact, but they’re on opposite sides of the chip, the compiler has to move one of them closer.

It does this by inserting SWAP gates — operations that exchange the states of two adjacent qubits. Think of it like passing a message in a classroom: if you need to send a note from the front row to the back, it gets passed desk to desk. Each pass takes time and introduces errors.

The number of extra SWAPs depends on the chip’s connectivity — how qubits are connected. All-to-all connectivity (like some trapped-ion systems) needs zero SWAPs. A grid layout (like IBM’s chips) might need many.

Step 4: Schedule and optimise

The compiler arranges operations in time to minimise the total circuit duration. Some gates can run in parallel (on different qubits). Others have to wait. The schedule determines the circuit’s depth — how many time steps the computation takes.

Along the way, the compiler looks for optimisations: cancelling redundant gates, merging rotations, reordering operations to reduce depth.

Why this matters more than you’d think

In classical computing, compilation is a solved problem. The compiler might make your code 2× faster or 2× slower — significant, but not make-or-break.

In quantum computing, compilation can be the difference between getting a result and getting noise. Here’s why:

  • Every extra gate adds errors (roughly 0.1-1% per two-qubit gate)
  • Every extra time step means more decoherence
  • A circuit that’s 3× deeper might go from 80% success probability to 5%

A well-compiled circuit can be 10× better than a naively compiled one on the same hardware. This makes quantum compilation an active research area, not just an engineering detail.

The honest summary

  • Quantum programs are written as abstract circuits, but hardware runs physical pulses
  • Compilation translates between these, with huge impact on whether your algorithm works
  • The biggest cost is usually routing: moving qubit states to satisfy connectivity constraints
  • Hardware architecture directly affects compilation overhead — better connectivity means fewer extra operations
  • When evaluating quantum results, always ask about the compiled circuit depth, not just the algorithm description

What’s next?

Now that you understand how algorithms become hardware instructions, the natural question is: how do you evaluate whether a quantum computation actually worked? Spoiler: it’s more complicated than “did we get the right answer.”