From circuits to pulses: what quantum compilation actually does

When you write a quantum program, you usually describe it as a circuit: a sequence of gates acting on qubits.

Real devices don’t run “CNOT” as an abstract unitary. They run control signals, shaped pulses, and calibrated interactions that approximate the desired operation.

The compilation pipeline (high level)

1. Parse / normalize your program into a circuit.
2. Optimize: cancel inverses, merge rotations, reduce two-qubit count, etc.
3. Map logical qubits to physical qubits (placement).
4. Route two-qubit gates that don’t match device connectivity (insert SWAPs).
5. Schedule operations considering timing and constraints.
6. Lower gates into device-native operations (and sometimes pulses).

Each stage can change the final fidelity more than you might expect.

Why connectivity shows up everywhere

Many devices only allow strong entangling operations between certain neighbors (a coupling graph).

If your circuit needs a two-qubit gate between distant qubits, routing inserts extra gates (often SWAPs), which:

• increases depth,
• increases error accumulation,
• and increases total runtime (more exposure to decoherence).

A practical takeaway

When someone says “we ran algorithm X on device Y,” the real question is:

• How many native two-qubit operations did the compiled circuit require?
• What was the final depth and total runtime?
• What was the effective error rate after compilation?

Compilation is not just “making it run”—it’s part of the algorithm’s real-world performance.

Tempus quam pellentesque nec nam aliquam sem. Risus at ultrices mi tempus imperdiet. Id porta nibh venenatis cras sed felis eget velit. Ipsum a arcu cursus vitae. Facilisis magna etiam tempor orci eu lobortis elementum. Tincidunt dui ut ornare lectus sit. Quisque non tellus orci ac. Blandit libero volutpat sed cras. Nec tincidunt praesent semper feugiat nibh sed pulvinar proin gravida. Egestas integer eget aliquet nibh praesent tristique magna.