Same 'if', different timing

Sun, 15 Nov 2026 00:00:00 GMT

Here is a small quantum program. Measure a qubit. If the result is 1, apply a correction to a second qubit. Then carry on.

OPENQASM 3.0;
include "stdgates.inc";

qubit[3] q;
bit c;

h q[0];
cx q[0], q[1];      // q[0] and q[1] are now entangled
c = measure q[0];   // read q[0] in the middle of the program

if (c == 1) {
    x q[1];         // correction: two gates long
    z q[1];
} else {
    // nothing to do
}

h q[2];             // q[2] has been waiting this whole time

Every programmer can read this. Now ask a question the code does not answer: at what time does h q[2] run?

On a laptop you would never ask. A branch takes a few nanoseconds longer or shorter, and nothing cares. On a quantum computer the answer decides whether the waiting qubit, q[2], is still holding its information when you get to it. And when I read the documentation of the stacks that run programs like this, I found that they answer the question differently. Some make both arms of the if take the same time. Some synchronize and accept a small gap. One hands the clock to the programmer and raises an error if you get it wrong. One avoids most of the question by restricting what you can write.

This post explains why time is part of a quantum program’s meaning, what each of those answers looks like, and why I think the missing piece is a written statement of what each layer of the stack promises the next. If you have never written a quantum program, start at the next section. If you have, skip to Four answers to one question.

Background: qubits forget, so time costs something

A classical bit sitting in memory stays a 0 or a 1 until something changes it. A qubit does not sit still. It holds a delicate superposition, and its environment keeps nudging it: stray electromagnetic fields, tiny fluctuations in the chip’s materials, heat. Over time the stored state drifts and blurs. Physicists call this decoherence, and on today’s superconducting chips the useful lifetime of a qubit’s state is on the order of tens to hundreds of microseconds.

That turns a quantum program into a race. Every operation, including doing nothing, uses up some of that lifetime. A qubit that sits idle for a microsecond is not “paused”. It is decaying.

This is why quantum compilers do something classical compilers never do: they schedule the program in physical time. Every gate gets a start time and a duration, measured in nanoseconds, for every qubit. The schedule is not a performance detail. It determines how much error the program accumulates.

Dynamic circuits: programs that react

For most of quantum computing’s history, programs were fixed lists of gates, with all measurements at the very end. A dynamic circuit breaks that rule. It measures some qubits in the middle of the run, sends the result to a classical controller, and lets that controller decide what to do next while the other qubits are still alive. The step from measurement to decision to action is called feedforward.

Dynamic circuits are not exotic. Quantum teleportation needs one: you measure, then correct the receiving qubit depending on the outcome. Resetting a qubit mid-program is measure-then-flip-if-needed. And quantum error correction, the thing every large machine will depend on, is a loop of measuring check qubits, decoding what went wrong, and applying corrections, forever.

How long is “a step”?

It helps to put real numbers on this. IBM’s documentation shows the properties of one qubit on a Heron r2 processor: a two-qubit CZ gate takes 68 nanoseconds and a measurement takes 2,684 nanoseconds (IBM, View backend details). IBM’s November 2025 announcement put its feedforward latency at about 600 nanoseconds (IBM Quantum blog). These numbers vary by qubit and by calibration day, but the proportions are what matter.

Measure plus decide comes to about 3.3 microseconds, the time it takes to run roughly 48 two-qubit gates. IBM says this plainly in its own guide: mid-circuit measurements and classical operations “typically have longer execution time than two-qubit gates”, which can cancel out the benefit of a shorter circuit (IBM, Execute dynamic circuits). In my example program, q[2] spends that whole stretch waiting.

Idle time is not wasted time, if you know how long it is

There is a standard trick for protecting a waiting qubit. It is called dynamical decoupling, and the idea is older than quantum computing. If a qubit is slowly drifting in one direction, you flip it over halfway through the wait. Now the same drift pushes it back the other way, and by the end of the wait the two halves roughly cancel. Do this with a few carefully spaced flips and much of the slow noise averages out. The flips add up to “do nothing”, so they don’t change what the program computes.

The catch is in the phrase carefully spaced. The flips have to be placed relative to the start and end of the idle window. Qiskit’s standard pass for this, PadDynamicalDecoupling, says so directly: it “works on a scheduled, physical circuit”, scans for idle periods (the explicit delays the scheduler inserted), and fills them with decoupling pulses (Qiskit API docs). IBM’s own announcement ties the two together: because mid-circuit measurements are long, qubits that aren’t measured “are left to sit idle and decohere”, and a more flexible way of specifying durations is what lets you run accurate decoupling during those waits (IBM Quantum blog).

So the compiler needs to know how long each idle window is. For a fixed list of gates, it does. Now put an if in the middle.

The branch problem

Go back to the example. The if arm has two gates. The else arm has none. Those two paths take different amounts of time, and which one runs is decided by a measurement result that nobody knows until the program is running.

That leaves the next instruction, h q[2], with two possible start times. Or more, if the feedforward latency itself varies from shot to shot. The compiler, which wanted to fill q[2]’s idle window with evenly spaced decoupling pulses, no longer knows where the window ends.

Something in the stack has to settle this. Either the language says what an if costs in time, or the compiler decides, or the control hardware decides at run time. To see who does, I went through the specification of the language most of these programs are written in, and then the documentation of four control systems.

What the language says

The example above is OpenQASM 3, the most widely supported language for this kind of program. It has a rich vocabulary for time: durations, explicit delays, flexible stretch durations that the compiler solves for, and a box that groups instructions into a block. Its circuit-timing chapter is clear that this is a compile-time system: stretch variables “are resolved at compile time”, and all arithmetic on durations happens at compile time (OpenQASM, Circuit timing). The same chapter offers box for code whose exact duration “is runtime dependent”, so that you can impose a duration on it for scheduling purposes.

The one firm rule about branches and time that I found is in the pulse-level chapter, which covers hand-written calibrations (defcal blocks). There, each branch of the control flow must have “definite and equivalent duration resolvable at compile time”. The spec’s own example is a reset: measure, and if the result is 1 flip the qubit, otherwise “delay for an equivalent amount of time” (OpenQASM, Pulse-level descriptions).

I did not find a matching rule for an ordinary circuit-level if like the one in my example. If I missed it, please point me to it. As far as I can tell, the question is left to whoever runs the program.

Every arrow in that diagram is a handoff between two pieces of software or hardware, usually built by different teams. Each layer is careful about time internally. What I couldn’t find is a written statement, at each arrow, of what the layer below guarantees about the duration of a branch.

Four answers to one question

Here is what the control systems’ own documentation says. I have kept to what each document states, and I flag what it doesn’t.

1. Pad both arms to the same length

Qblox’s Q1 sequencers handle conditional playback with an instruction called set_cond. When the next real-time instruction comes up, the hardware checks the condition. If it holds, the instruction runs. If not, the hardware waits for a fixed time, the else_duration, that the programmer supplied (Qblox Q1ASM guide). The effect is that the timeline advances by the same amount whichever way the condition goes. The defcal rule in OpenQASM above is the same idea, written into a language spec.

The appeal is obvious: everything after the branch happens at a time the compiler knows. The price is also obvious: the short arm idles for as long as the long arm runs, every single time.

2. Synchronize, and accept a gap

Quantum Machines’ QUA language takes a different route. Its timing guide says there is an implicit align whenever several elements take part in a flow-control branch, whether an if, a loop or a switch, and that they are “aligned in the beginning of the flow control branch” (Quantum Machines, Timing in QUA).

How costly that align is depends on whether the compiler can predict it. If every duration is known at compile time, the compiler replaces the hardware synchronization with precomputed waits and no gaps appear. But the guide states that any dependence on a runtime value, including “a branch condition”, is treated as non-deterministic. In that case the processing cores signal each other at run time, which takes several clock cycles and leaves gaps in the pulse sequence. The gap is smallest when the channels are on the same module and longest across separate chassis. QUA also lets you mark a block as strict_timing_, in which case any gap raises an error instead.

So here the branch is synchronized at its start, and the small, hardware-dependent gap is part of the deal.

3. Hand the timeline to the programmer

ARTIQ, the open-source control system used in many trapped-ion labs, makes time explicit in the program itself. A kernel keeps a timeline cursor, now_mu, which the programmer advances with calls like delay(). Events are scheduled at the cursor’s position. Trying to schedule an event at a time that has already passed raises an RTIOUnderflow exception (ARTIQ manual, Real-time I/O concepts).

That design gives the programmer full control and full responsibility. If one arm of a branch needs more classical processing time than you budgeted, the next event lands in the past and you get an exception you can catch. The same manual also describes errors that behave differently. Sequence errors, collisions and busy errors “are not raised as exceptions and cannot be caught”. The offending event is discarded, the experiment keeps running, and the problem is reported in the core log. A timing mistake in a rarely taken arm can therefore remove a pulse from the run, and you learn about it from the log.

4. Allow only simple branches

IBM’s cloud machines take the most conservative route I found. Of the control-flow structures OpenQASM 3 defines, IBM currently supports only the conditional if. Nested conditionals are not allowed, measurements and resets inside a conditional are not supported, and for, while and switch are not supported (IBM, Execute dynamic circuits). IBM’s announcement adds that the new infrastructure can detect independent conditional operations and run them in parallel (IBM Quantum blog).

Restricting what you can write removes most of the hard cases. What I could not find in the pages I read is a statement of how two arms of unequal length are timed on IBM hardware. That is a gap in my reading, not a claim about IBM’s behaviour, and I’d be glad to be pointed to the right page.

Side by side

Stack	What its documentation says about a branch	Category	Tag
OpenQASM 3, `defcal`	Every branch must have definite and equal duration, known at compile time (spec)	Pad	Observed
OpenQASM 3, circuit-level `if`	No rule found in the circuit-timing chapter (spec)	Unspecified	Observed (absence)
Qblox Q1 (`set_cond`)	False condition waits `else_duration` ns (docs)	Pad	Observed
Quantum Machines QUA	Implicit align at branch start; runtime branch conditions are non-deterministic and leave gaps of a few cycles (docs)	Synchronize with gap	Observed
ARTIQ	Explicit cursor; past timestamps raise `RTIOUnderflow`; some other errors drop the event and log it (manual)	Exposed timeline	Observed
IBM Quantum	Only un-nested `if`; no measure or reset inside; feedforward about 600 ns (guide, blog)	Restrict	Observed
IBM Quantum, unequal arms	Not stated in the pages I read	Unknown	Not verified
All of the above	The same source-level `if` gets a different timing contract on each stack	—	Argument

None of these designs is wrong. Each makes sense for the hardware and users it was built for. The issue is that they are different, and nothing in the program says which one it expects.

Why this matters

Portability. The same if means different things in time depending on where it runs. A program whose correctness depends on a waiting qubit being protected for a known window carries that assumption silently. Move it to a different stack and the assumption changes without any line of code changing.

Idle-time protection. As above, decoupling sequences are placed by a compiler that needs to know window lengths. A branch makes the window depend on a measurement outcome and on feedforward latency. Padding gives the compiler a known window at the cost of extra idling. Synchronizing gives a shorter wait with a small unknown gap. The program can’t currently say which it wants.

Error correction raises the stakes. In a fault-tolerant machine, reacting to measurements on time stops being a fidelity concern and becomes part of correctness. Gidney and Ekerå’s well-known estimate for factoring a 2048-bit RSA number with 20 million noisy qubits assumes a surface code cycle of 1 microsecond and a reaction time of 10 microseconds (arXiv:1905.09749). For comparison, Google’s 2024 below-threshold experiment decoded in real time with an average decoder latency of 63 microseconds at distance 5, against a 1.1-microsecond cycle (arXiv:2408.13687). Decoder latency and reaction time are not the same quantity, so this is not a like-for-like comparison. It does show that the time budgets are tight, and that timing will be stated as a requirement rather than measured after the fact.

The rare branch is the one you never test. A correction arm that runs once in a hundred shots gets very little real-world exercise, and the one that runs once in a million gets almost none. If its timing is wrong, testing is a poor way to find out. This is the classic argument for checking timing by analysis instead of by observation.

Other fields learned this the hard way

None of this is new outside quantum computing. Two well-documented failures show what happens when a timing assumption lives only in someone’s head.

The Patriot battery at Dhahran, 1991. On 25 February 1991, a Patriot missile battery in Dhahran, Saudi Arabia, failed to intercept an incoming Scud, which struck an Army barracks and killed 28 American soldiers. The US General Accounting Office (now the Government Accountability Office) traced it to software. The system’s registers were 24 bits long, and converting the clock’s integer time to a real number lost a little precision each time. The error grew with uptime. After 100 hours of continuous operation the time error was about 0.34 seconds, enough to shift the radar’s range gate by 687 metres, so the system looked in the wrong place. Alpha Battery had been running for over 100 consecutive hours (GAO report IMTEC-92-26; full text mirror). The rule that mattered, roughly “this is only accurate for so many hours of uptime”, was not part of anything the software checked.

The Boeing 787’s 248-day counter. In 2015 the US Federal Aviation Administration issued an airworthiness directive for every 787. A software counter inside the generator control units would overflow after 248 days of continuous power and push the unit into failsafe mode. If all four main units had been powered up at the same moment, they would all fail together after 248 days, “resulting in a loss of all AC electrical power regardless of flight phase” (Federal Register, 1 May 2015). No flight test runs for 248 days. It is the rarely taken path from the previous section in its purest form.

What embedded systems did about it. Real-time systems research has a long-standing answer: separate when an operation is supposed to happen from how long the hardware actually takes, and write the first one into the program. The Logical Execution Time idea, introduced with the Giotto language in 2000, gives each task a fixed logical time window. The implementation’s job is to meet that window, and if it does, the observable timing is the same on any machine (Giotto technical report; LET paradigm overview). More recent work such as Lingua Franca makes the same split between logical and physical time, and states plainly which bounds the guarantee depends on, so that a violation is detectable rather than silent (Lohstroh et al., ACM TECS 2024).

A simpler picture. Think of a railway line where two routes split at a junction and rejoin later. The timetable doesn’t describe the track. It promises when the train arrives at the rejoining station, and each route is either fast enough to meet that time or waits at a signal until it does. Everyone downstream plans around the promise. A quantum if is a junction with no timetable: each control stack decides on its own how long the detour takes.

What is missing

Put the pieces together. Each layer of a quantum stack is careful about time inside itself. The language specifies durations at compile time. The compiler schedules every gate. The control hardware is deterministic down to the clock cycle once an instruction is committed. Where they meet, at the branch, nobody writes down what one layer promises the next.

What would such a statement contain? I think at least four things:

how long a branch may take, as a bound rather than a hope;
whether the arms are padded, synchronized, or left to the programmer;
how long a measurement result takes to become usable, and where that number comes from (a certified worst case, a measured maximum, or a vendor’s typical figure);
what happens when something is late: an error, a dropped event, or a silent delay.

With that written down, a compiler could know whether the idle window it is about to fill with decoupling pulses really ends where it thinks it does. A program could say “this branch needs padding” and be told on the wrong hardware that it won’t get it. Error-correction designers could check a reaction-time requirement before running anything.

I am working on how to state and check this. That will come later, and I’d rather the problem be understood before I propose an answer. For now, if you build control software, compilers or error-correction stacks, I’d like to hear two things: whether your system makes a timing promise about branches that I missed, and whether the four categories above match how you think about it.

What I do not claim

I don’t claim any of these designs is a bug. Each is a deliberate trade-off.
I don’t claim which choice is best for fidelity. That depends on hardware, noise and workload, and I have not measured it.
I didn’t run code on any of these systems for this post. Everything above comes from public documentation, read in November 2026. Documentation changes, so check the linked pages.

Corrections

None yet. Corrections will be listed here with dates.

Sources

Language and compilers

OpenQASM live specification, Circuit timing and Pulse-level descriptions
Qiskit API, PadDynamicalDecoupling

Control systems and hardware

Qblox, Q1ASM user guide (docs version 2026.10)
Quantum Machines, Timing in QUA
M-Labs, ARTIQ Real-Time I/O concepts
IBM Quantum, Execute dynamic circuits, View backend details, and Utility-scale dynamic circuits now available for all users (Nov 2025)

Fault tolerance

Gidney and Ekerå, How to factor 2048 bit RSA integers in 8 hours using 20 million noisy qubits, Quantum 5, 433 (2021)
Google Quantum AI, Quantum error correction below the surface code threshold, arXiv 2024, published in Nature

Other fields

US GAO, Patriot Missile Defense: Software Problem Led to System Failure at Dhahran, Saudi Arabia, IMTEC-92-26 (1992)
US FAA, Airworthiness Directives; The Boeing Company Airplanes, Federal Register, 1 May 2015
Henzinger, Horowitz and Kirsch, Giotto: a time-triggered language for embedded programming (2000); Kirsch and Sokolova, The Logical Execution Time paradigm
Lohstroh et al., Deterministic coordination across multiple timelines, ACM TECS (2024)