Hardware Architecture and the Full Stack

A computer is a stack, not a chip

A quantum computer is the whole path from problem statement to classical answer — application, algorithm, circuit, compiler, control system, physical qubits, measurement, decoder, and classical post-processing. Every layer transforms the one above it, and every layer can independently kill the workload.

The stack, layer by layer

Layer	The question it answers
Application	What useful problem is being solved?
Algorithm	What quantum structure gives an advantage?
Circuit	How many qubits, gates, depth, and measurements?
Compiler	How does the circuit map to native gates and connectivity?
Runtime	How are jobs scheduled, batched, and measured?
Control	Which pulses, lasers, voltages, or optical operations implement the gates?
QPU	What physical system stores the quantum information?
Measurement	How is quantum information converted to classical bits?
Decoder	How are errors inferred and corrected?
Classical HPC and AI	What classical compute supports simulation, optimization, decoding, and workflow integration?

The metrics that matter

Raw qubit count is one metric among many, and rarely the binding one. The numbers that actually predict whether a workload runs:

• one-qubit and two-qubit gate fidelity
• measurement fidelity
• reset fidelity and speed
• coherence times
• gate times
• connectivity
• crosstalk
• leakage
• calibration stability
• uptime and queue time
• compiled circuit depth
• logical error rate
• reliable logical operations
• cost per useful result

Notice the ordering of this list as you read vendor materials: the metrics near the top are measured per device; the ones near the bottom are measured per system. Serious roadmaps migrate downward over time.

The hardware modalities

Superconducting qubits

Strengths: fast gates, a mature fabrication and control ecosystem borrowed from semiconductor engineering, and broad cloud availability.

Bottlenecks: coherence, crosstalk, wiring and cryogenics, fabrication yield, and scaling the qubit count while preserving fidelity.

Trapped ions

Strengths: high gate fidelities, long coherence, and flexible connectivity within a trap.

Bottlenecks: gate speed, scaling across modules, photonic interconnects between traps, and system cost per unit of throughput.

Neutral atoms

Strengths: large arrays, reconfigurable geometry, natural analog simulation, and promising parallelism for error-correction cycles.

Bottlenecks: high-fidelity digital gates, atom loss and movement errors, continuous operation, and the depth of error-correction cycles.

Photonics

Strengths: networking comes naturally, some components run at room temperature, and there is a credible semiconductor-style manufacturing path with a long-term fault-tolerance vision.

Bottlenecks: photon loss, source and detector performance, switching, resource overhead, and integrating enormous component counts.

Silicon spin qubits

Strengths: compatibility with semiconductor manufacturing, a tiny physical footprint, and the prospect of genuine density.

Bottlenecks: control complexity, device variability, coupling and readout, and scaling with high yield.

Cat, bosonic, and topological routes

Strengths: the promise of cutting error-correction overhead by building protection or error bias into the hardware itself.

Bottlenecks: complete logical gate sets, high-quality two-qubit operations, independent validation of the underlying claims, and system integration.

Worked example: circuit depth after connectivity

Suppose an algorithm needs a CNOT between qubits q0 and q3. On an all-to-all device that gate may be native. On a line topology, q0 - q1 - q2 - q3, you pay for routing:

SWAP(q0, q1)
SWAP(q1, q2)
CNOT(q2, q3)
SWAP(q1, q2)
SWAP(q0, q1)

Each SWAP decomposes into three CNOT-like gates, so one logical interaction became roughly thirteen physical two-qubit gates. Two-qubit gates are the noisiest operations on most machines, so connectivity is not a convenience feature — it is an error budget.

Compilation is not cosmetic

Compilation maps an ideal circuit onto real hardware, and in doing so it can change gate count, depth, error exposure, measurement placement, routing, native gate usage, and schedule length. A circuit that looks short in a textbook can become unrunnable after compilation to a sparse topology. This is why Part V treats the transpiler as part of the algorithm, not as plumbing beneath it.

Control systems

The control layer is where symbolic gates become physical actions: microwave pulses for superconducting qubits, laser pulses for ions and atoms, optical components for photonics, magnetic and electric fields for spins. It has to manage timing, amplitude, phase, calibration, feedback, synchronization, and low-latency correction — continuously, and at scale.

Once error correction enters the picture, the control stack and decoder stop being accessories and become part of the computer. Their throughput and latency bound how fast correction cycles can run, which bounds everything else.

Measurement and reset

Quantum output is classical data, so readout quality caps everything the machine can report. The questions: How accurate is readout? How fast? Is mid-circuit measurement supported? Can qubits be reset quickly for reuse? Does measuring one qubit disturb its neighbors? Can the data feed real-time control?

Mid-circuit measurement and fast reset deserve special attention: without them, the correction cycles from the previous guide cannot run at all.

Cloud, on-prem, and HPC integration

Quantum hardware reaches users through public cloud platforms, private deployments, on-premise systems, national lab and HPC centers, and hybrid data centers. The access model is not a commercial footnote — it changes the engineering:

• Cloud favors access, ecosystem, and queue-based throughput.
• On-prem favors sovereignty and deep integration with a customer's own systems.
• HPC integration favors scientific workflows with classical pre- and post-processing.
• Data-center integration favors enterprise operations and scheduling discipline.

Misconceptions worth unlearning

"The company with the most physical qubits is winning." Useful progress depends on quality, scaling method, logical performance, and workload execution. The metrics list above is the antidote.

"Hardware and software can be evaluated separately." Algorithms compile differently on different hardware, and hardware limits reshape what software is worth writing. The stack is coupled at every seam.

"A quantum computer is just a faster accelerator." It is a fragile, probabilistic accelerator that demands specialized algorithms, exotic control, constant error handling, and explicit verification. The word "just" is doing all the work in that sentence.

What this buys you in diligence

Hardware diligence should cover:

• the modality, and why the team chose it,
• native gates,
• error rates and how they were measured,
• connectivity,
• the scaling method,
• manufacturing dependencies,
• the error-correction path,
• the control stack,
• the software ecosystem,
• the customer access model,
• evidence that performance improves with scale.

The connecting test: can the company trace its hardware metrics all the way to application resource estimates? If the chain breaks anywhere, so does the strategy.

Exercises

1. Pick one modality and write its top three strengths and top three bottlenecks from memory.
2. Explain why two-qubit gate fidelity matters more than one-qubit fidelity for most circuits.
3. Take a CNOT-heavy circuit and show how limited connectivity inflates its depth.
4. Explain why mid-circuit measurement matters for error correction.
5. Compare cloud access and on-premise deployment from a customer-adoption perspective.
6. Write a one-page hardware diligence memo for one company, using the checklist above.

Check your understanding

You have this guide when you can, without notes:

• trace a workload from application to physical qubit and back,
• explain why compilation changes feasibility,
• compare hardware modalities without raw-qubit-count hype,
• identify control and decoder latency as scaling constraints,
• write a defensible hardware diligence memo.