The Full Quantum Computer Stack
Every quantum run is a round trip: a classical problem goes in, becomes shaped pulses and fields, and returns as classical bits you have to earn trust in. This chapter walks that whole path and shows where claims quietly break.
The qubit is the only layer of the quantum stack that makes headlines, and it is rarely the layer that decides whether a workload runs. Reading the whole stack — every translation, every assumption — is the core hardware skill this book builds.
This chapter draws the full stack, folds depth and time into one budget, traces a small algorithm through every layer, and turns the trace into a diligence instrument.
Core concepts: hardware modalities, control readout stack, resource estimation.
A round trip through nine translations
A quantum computer is a layered system that converts a classical problem into a fragile physical process and back into trustworthy classical information. The path:
- Problem. A real task with a classical baseline to beat.
- Algorithm. Assumes an input model and a success metric.
- Circuit. Assumes a gate set, a width, and a depth.
- Compiler. Assumes routing, calibration, and timing data about one specific machine.
- Control. Assumes pulses, fields, or lasers can be shaped and delivered on schedule.
- Qubits. Assume coherence long enough to survive the schedule.
- Readout. Assumes measurement fidelity and latency.
- Post-processing. Assumes the statistics support the claim.
- Decision. Assumes the quantum result beats or complements the classical baseline.
Every arrow hides an assumption, and any assumption can be the one that fails. The stack is the machine; the chip is one component of it.
Depth, time, and topology are one budget
Two small formulas keep the middle layers honest. The coherence budget converts lifetime into an operation count:
The routing overhead converts an idealized circuit into the one the hardware will actually run:
Their product is the trap: a circuit that looks shallow in a textbook can grow too deep after routing, too slow after control timing, or too noisy after measurement and reset. Depth, time, and topology are not three concerns; they are one budget wearing three hats.
Worked example: tracing phase estimation
Take a small phase-estimation routine built from repeated controlled operations, and walk it down the stack. The algorithm requires controlled evolution that preserves phase information long enough to matter. The circuit layer turns that into controlled gates plus an inverse Fourier transform. The compiler asks whether the target device offers the needed two-qubit interactions directly or must insert routing — on a sparsely connected chip, the routing layers arrive before control limits are even considered. The control layer asks whether the pulses fit calibration windows and coherence time. Readout asks whether the outcomes are trustworthy enough to reconstruct a phase. Post-processing asks whether the final distribution supports the original claim.
A useful trace names at least one failure mode per layer, and it ends with a gate: the next measurable result that would raise confidence in the weakest layer — say, reliable execution of the deepest controlled-operation block on the real topology, with settings published so others can reproduce it.
Where the intuition fails
The first trap is starting hardware evaluation at the qubit count. Count matters, but by itself it says nothing about fidelity, topology, runtime, readout, reset, calibration, compilation, or the error-correction path. It is one layer's headline number.
The second trap is mistaking cloud access for stack maturity. Renting time on a machine is excellent for learning and benchmarking. It proves nothing about whether the system can carry a useful workload or a fault-tolerant roadmap.
The engineering view
For a computer scientist, this stack is a compiler plus an operating system plus a real-time control loop for unusual hardware. The abstract program is not the machine. Between the two live an intermediate representation, placement, routing, scheduling, runtime metadata, error handling, measurement records, and reproducibility.
That is why resource estimation belongs inside the stack rather than after it. A resource estimate is a contract among algorithm, logical operation count, physical error rates, modality, code assumptions, and runtime. Change any layer and the estimate moves. The expert skill is explaining which layer changed — and why the decision changed with it.
What this buys you in diligence
The stack is also an ownership map. A hardware company may own qubits but rent cryogenics, packaging, control electronics, compilers, and application software. A software company may own the workflow while depending entirely on someone else's hardware roadmap. A cloud provider may own the orchestration and none of the physics.
A serious memo therefore separates, layer by layer: what the team owns, what it depends on, the next proof gate, and the characteristic failure mode. Four columns, nine rows, and the pitch deck becomes checkable.
Exercise
Trace one algorithm through the stack. Pick a small algorithm — phase estimation, a variational ansatz step, anything with a few dozen gates — and trace it from problem to decision.
- Submit: the trace, with one named bottleneck or failure mode at each of the nine layers. Finish with a label for the stack — build, partner, monitor, wait, or avoid — for the workload you chose.
- Check: apply the coherence budget and the routing overhead; state which binds first — depth, time, or topology — and show the arithmetic.
- Repair: if your trace concludes only that the machine needs "more qubits," redo it after Chapter 53 (Why Useful Quantum Computers Are Systems Engineering Projects), which is the method this exercise practices.
Check your understanding
Answer without notes: why does the qubit layer get the headlines while other layers decide the outcome?
A passing answer explains that qubits are countable and photographable, while routing depth, control latency, readout fidelity, and post-processing are where workloads actually live or die. It gives one concrete example of a non-qubit layer breaking a claim.
Oral defense: pick any layer except qubits and argue for ninety seconds that it is the most important one.
If you get stuck
If your traces keep collapsing into a single number — qubits, fidelity, benchmark score — go back to Chapter 53 (Why Useful Quantum Computers Are Systems Engineering Projects). It builds the weakest-layer habit this chapter applies to hardware.