Hardware-Constrained Lab
An ideal circuit diagram hides everything that makes quantum hardware hard. In this capstone you build a lab that puts the ideal circuit next to its constrained twin and measures what connectivity, native gates, noise, and timing actually change.
A circuit you cannot map onto a real machine's constraints is a specification, not a computation.
In this capstone you build a lab that puts an ideal circuit next to its hardware-constrained twin and measures what connectivity, native gate sets, noise, and timing actually change. The deliverable is small, reproducible, and honest about every assumption.
Core concepts: capstone synthesis, hardware modalities, control and readout stack.
Ideal circuits lie politely
Nothing in a textbook circuit diagram is false — it just leaves things out. The diagram assumes any two qubits can interact, any gate is available, operations are noiseless, and time is unlimited. Real machines violate all four assumptions. The hardware-constrained lab makes the omissions visible: take one circuit, compile it under explicit machine assumptions, and show the before and after side by side.
The goal is not to reproduce a vendor's system. It is to train the reflex that hardware assumptions are part of the computation, not an implementation detail someone else handles.
Four constraints do most of the work. Connectivity decides which qubit pairs can interact directly, and everything else is routing. The native gate set decides what one operation actually is; any gate outside the set is synthesized from the ones inside it. Noise decides how much of the output is signal. Timing — gate durations against coherence time — decides how deep a circuit can run at all. A lab that varies these four and records what changes has taught the core lesson of Part VII in one artifact.
Two budgets that bound every run
The coherence budget: . Whatever your circuit wants to do, it must fit inside the time the state survives.
The error budget: , one factor per gate type. Depth costs multiplicatively, not additively — which is why routing overhead matters so much. Every added gate taxes the whole computation.
And because this is a teaching artifact, the mastery check applies: correct explanation, worked check, transfer prompt, stated limitation. A lab without a limitation is an advertisement.
Worked example: a Bell state meets a real topology
The ideal Bell-state circuit is two operations: a Hadamard on one qubit, a CNOT between the pair. Now constrain it. Suppose the target device offers no direct coupling between those two qubits and no native CNOT. The CNOT decomposes into the native gate set, the qubits need a swap chain to become adjacent, and each swap is itself three two-qubit gates.
The two-line circuit is now noticeably deeper. Apply the error budget: with an illustrative one percent error per two-qubit gate, the constrained version's success probability drops by the product over all those added gates. Apply the coherence budget and ask whether the deeper circuit still fits. Then add readout error, which corrupts the answer even when everything upstream went right. The abstract circuit did not change; its physical meaning did.
The lab deliverable is a note or runnable example with the two versions side by side, the changed depth and gate count written out, and every assumption labeled: gate set, topology, error model, timing values, and whether the numbers are illustrative.
How labs go wrong
The weakest lab runs only the clean circuit and declares victory. The second-weakest uses fake precision: illustrative numbers dressed as measurements. If a value is invented for teaching, say so. If it is a real hardware figure, it needs a source and a date.
Two subtler failures: letting one depolarizing noise model stand in for all hardware behavior, and hiding the comparison in prose. If the reader cannot see the ideal and constrained circuits side by side with the deltas written down, the lab is a description, not a demonstration.
The engineer's analogy
This is performance profiling. The algorithm is not the deployed program: compilation target, runtime, memory hierarchy, and failure modes all change observed behavior, and the only way to learn that is to measure. Include reproducibility notes with the lab — command, expected result, assumptions, known limitations. If it later becomes an interactive playground route, the user should be able to toggle topology, error rate, and depth and watch the conclusion move.
Why hardware fit is a diligence question
The same discipline answers a partner question: given this workload, which constraint dominates — connectivity, gate error, coherence, or readout — and which machine fits? That question comes up whenever a team compares hardware vendors or cloud backends, and it cannot be answered from a spec sheet's qubit count. Keep the capstone vendor-neutral. Use illustrative constraints unless you perform a dated source refresh, and make clear the lesson is reasoning, not benchmarking a current device.
Exercise
Build the comparison. Build or fully specify a lab comparing ideal and hardware-constrained behavior for one small circuit.
- Submit: the side-by-side comparison with depth, gate counts, and output differences written out, plus topology, gate set, timing, noise, readout, and calibration assumptions labeled.
- Check: compute the coherence budget and the error budget, then run the teaching mastery check.
- Transfer: repeat the lab for a second hardware modality or a second circuit.
- Repair: if hardware appears in your lab only as a qubit count, rebuild the stack picture after Chapter 54, The Full Quantum Computer Stack.
Check your understanding
Present the lab and answer: which constraint changed the result most, and how do you know?
A passing answer names a mechanism — routing depth, gate error, coherence, readout — and shows the comparison that reveals it.
If you get stuck
If the lab treats noise as an afterthought or hardware as a spec sheet, work through Chapter 45 (Decoherence and Error Channels) for the noise model and Chapter 54 (The Full Quantum Computer Stack) for how constraints enter each layer, then rebuild the comparison.