The Quantum Software Stack

Running a quantum algorithm on real hardware is never a single step. Between the mathematical idea and the microwave pulses that drive a chip sits a software stack: a sequence of layers, each translating a higher-level description into a lower-level one. Understanding these layers is what separates someone who can write a textbook circuit from someone who can ship a quantum program that actually executes on a noisy device within a fixed gate budget.

The layers, top to bottom

A useful mental model has five layers. Information flows downward from intent to electronics.

Algorithm / application. The problem statement and the high-level quantum routine — Shor's factoring, a VQE energy estimate, amplitude estimation. At this layer you reason in terms of oracles, query counts, and asymptotic complexity, not individual gates.
Circuit / program. The algorithm expressed as a concrete sequence of gates and measurements on a fixed number of qubits, written in a host language (Qiskit, PennyLane, Cirq) or our own circuit(n) builder. This is still hardware-agnostic.
Intermediate representation (IR). A compiler-friendly, serialisable form such as OpenQASM or QIR. The IR is where optimisation passes, gate cancellation, and qubit-routing analyses operate. It is the lingua franca between front-end frameworks and back-end compilers.
Transpiled / scheduled circuit. The IR rewritten for one specific device: gates decomposed into the hardware's native gate set, two-qubit gates routed to respect the chip's connectivity graph, and operations scheduled in time. Layout and routing are added here.
Pulses / control electronics. The lowest layer: each native gate becomes a calibrated analogue waveform (a microwave or laser pulse) emitted by an arbitrary-waveform generator, plus the classical control logic that reads out qubits.

Why a stack instead of one big translator

Separating concerns lets each layer evolve independently. A new algorithm does not require a new compiler; a new chip does not require rewriting your application. The IR layer is the key seam: because OpenQASM and QIR are standardised, a circuit authored in one framework can be compiled by a different vendor's back end, and resource-estimation tools can analyse a program without ever running it. This mirrors classical computing, where source code, LLVM IR, and machine code form analogous layers.

Native gate sets and the cost of decomposition

No real device implements every textbook gate directly. A superconducting chip might offer $\{R_z, \sqrt{X}, \text{CNOT}\}$ as natives; a trapped-ion system might offer single-qubit rotations plus a Mølmer–Sørensen entangling gate. A Toffoli (CCX) gate, which we write as a single call, decomposes into roughly six CNOTs plus several single-qubit gates on such hardware. The abstract gate count and the transpiled gate count can therefore differ by an order of magnitude — which is exactly why resource estimation (the subject of the rest of this module) operates on transpiled circuits, not idealised ones.

Where simulators fit

A state-vector simulator like the one in this platform sits beside the stack rather than inside it: it consumes a layer-2 circuit and computes the exact mathematical outcome, with no native gate set and no connectivity constraints. That makes it ideal for verifying correctness — does the circuit compute what we intended? — and useless for predicting hardware cost. Both questions matter, and keeping them separate is a core discipline of quantum software engineering.

The full pipeline at a glance

\underbrace{\text{algorithm}}_{\text{intent}} \;\to\; \underbrace{\text{circuit}}_{\text{gates}} \;\to\; \underbrace{\text{IR}}_{\text{optimise}} \;\to\; \underbrace{\text{transpile}}_{\text{native + routed}} \;\to\; \underbrace{\text{pulses}}_{\text{hardware}}

Each arrow is a translation that can introduce overhead, lose information, or open an opportunity for optimisation. The chapters that follow zoom into the IR layer, the resource-counting that happens just below it, and the engineering practices — testing, version control, reproducibility — that keep the whole pipeline trustworthy.