The Control Plane and Real-Time Feedback

The control plane is where abstract circuits become physical actions. It converts compiled operations into timed microwave pulses, laser operations, voltage changes, ion transport, detector windows, measurement discrimination, and feedback decisions.

At this layer, quantum computing stops looking like software and starts looking like precision instrumentation.

8.1 Control-plane responsibilities

A quantum control plane must do five things well:

1. translate a scheduled program into hardware instructions,
2. enforce timing and alignment constraints,
3. drive analog control channels,
4. acquire and classify measurement signals,
5. feed selected classical results back into future quantum operations when supported.

flowchart LR
    Circuit[Compiled circuit] --> Schedule[Timing schedule]
    Schedule --> ControlIR[Control IR]
    ControlIR --> Waveforms[Pulse / laser / voltage commands]
    Waveforms --> Hardware[Control hardware]
    Hardware --> QPU[QPU]
    QPU --> Acquisition[Signal acquisition]
    Acquisition --> Discriminate[Measurement discrimination]
    Discriminate --> Feedback{Real-time feedback?}
    Feedback -- yes --> ControlIR
    Feedback -- no --> Results[Shot results]

The difficulty is not merely generating commands. The difficulty is generating commands that remain valid under drift, noise, latency, hardware limits, and safety constraints.

8.2 The abstraction boundary

Most users should not program pulses directly. They should program circuits or higher-level kernels. The platform should lower those abstractions into hardware-specific control programs.

That boundary protects users from accidental device damage and protects the platform from unbounded operational complexity.

flowchart TB
    User[User program] --> Circuit[Circuit / kernel layer]
    Circuit --> Compiler[Compiler and scheduler]
    Compiler --> Target[Backend target model]
    Target --> Control[Control-plane program]
    Control --> Device[Physical device]

    Cal[Calibration snapshot] --> Target
    Safety[Safety policies] --> Control
    Timing[Timing constraints] --> Control

The boundary moves over time. Historically, some platforms exposed pulse-level programming to advanced users. IBM has documented a migration away from direct Qiskit Pulse access on its processors toward fractional gates, with pulse-level control deprecated for that user-facing path [R25]. The architectural lesson is not that pulses disappear. The lesson is that low-level control remains essential, while the public abstraction may rise.

8.3 Timing is a correctness constraint

In classical systems, timing is often a performance issue. In quantum systems, timing can be correctness. A pulse that is late, early, too long, misaligned, or phase-shifted may implement the wrong operation.

Timing constraints include:

flowchart LR
    Reset[Reset and initialize] --> Gate1[Gate block 1]
    Gate1 --> Entangle[Entangling operation]
    Entangle --> Gate2[Gate block 2]
    Gate2 --> Acquire[Acquire measurement signal]
    Acquire --> Discriminate[Discriminate outcome]
    Discriminate --> Branch[Evaluate condition]
    Branch --> Conditional[Conditional operation]
    Timing[Target durations and channel alignment] -. constrain .-> Gate1
    Timing -. constrain .-> Acquire
    Timing -. constrain .-> Conditional

A compiler that ignores timing will produce attractive circuit diagrams and poor machine behavior.

8.4 Mid-circuit measurement and feed-forward

Dynamic circuits allow measurement results inside a circuit to influence later operations. OpenQASM 3 explicitly includes support for measurement-based circuits and classical feed-forward, and its language documentation distinguishes low-level embedded classical control from higher-level external classical functions [R26, R27].

Dynamic control is required for many important workflows:

• error-correction syndrome extraction,
• teleportation-style protocols,
• repeat-until-success subroutines,
• active reset,
• branching experiments,
• adaptive phase estimation.

sequenceDiagram
    participant Q as Qubits
    participant M as Measurement unit
    participant D as Discriminator
    participant C as Real-time controller
    participant G as Gate engine

    G->>Q: apply gates
    M->>Q: measure ancilla
    M->>D: analog signal
    D->>C: classical bit / register
    C->>C: evaluate condition
    C->>G: issue conditional operation
    G->>Q: apply correction or branch

The hard part is latency. Feedback must arrive before the quantum state it protects has degraded beyond usefulness.

8.5 Near-time vs real-time control

Do not collapse all hybrid behavior into one category. There are at least three timing regimes.

flowchart TB
    subgraph RealTime[Real-time loop]
        Measure[Measure] --> Decode[Decode / condition]
        Decode --> Correct[Correct]
    end

    subgraph NearTime[Near-time loop]
        Shots[Run shot batch] --> Estimate[Estimate objective]
        Estimate --> NextParams[Choose next parameters]
    end

    subgraph BatchTime[Batch-time loop]
        Campaign[Experiment campaign] --> Analysis[Offline analysis]
        Analysis --> Redesign[Redesign workload]
    end

These are illustrative scales, not universal timing classes. A real-time path must meet the target’s bounded latency and jitter requirements; an ordinary cloud API cannot be assumed to meet them.

8.6 Control IR and portability

A production control plane benefits from an internal representation between compiled circuits and device commands. That representation should carry:

• timing constraints,
• channel assignments,
• conditional branches,
• calibration references,
• waveform or primitive references,
• acquisition windows,
• safety constraints,
• provenance identifiers.

flowchart LR
    CircuitIR[Circuit IR] --> Lowering[Hardware lowering]
    Lowering --> ControlIR[Control IR]
    ControlIR --> BackendA[Superconducting backend]
    ControlIR --> BackendB[Trapped-ion backend]
    ControlIR --> BackendC[Photonic backend]
    CalA[Calibration A] --> BackendA
    CalB[Calibration B] --> BackendB
    CalC[Calibration C] --> BackendC

The same circuit may lower to very different control programs across hardware types. A portability layer should not pretend otherwise.

8.7 Hardware-specific control differences

Different quantum technologies impose different control-plane shapes.

Quantinuum’s H-Series documentation, for example, describes operational constraints around ion movement, gate zones, and state preparation and measurement [R18]. These constraints are not incidental; they shape the control and scheduling problem.

8.8 Real-time decoder path for error correction

Surface-code operation repeatedly extracts syndromes while a decoder processes the stream. Sustained decoding throughput must keep up, but decoding latency may span multiple extraction rounds. A frame update must arrive before an operation or readout interpretation that depends on it. Google’s Willow work demonstrates pipelined real-time decoding [R5].

flowchart LR
    Stabilizer[Measure stabilizers] --> Syndrome[Syndrome bits]
    Syndrome --> Decoder[Real-time decoder]
    Decoder --> Frame[Update Pauli frame]
    Stabilizer --> NextCycle[Continue scheduled QEC cycles]
    NextCycle --> Stabilizer
    Frame --> Feedforward[Dependent logical operation or readout]
    Decoder --> Alert{Decoder confidence low?}
    Alert -- yes --> Flag[Flag logical risk]

Corrections can often be tracked in a classical Pauli frame. Track decoder backlog and the deadlines of dependent logical operations explicitly; completing every decode within one syndrome cycle is not a universal requirement.

8.9 Safety and guardrails

The control plane must prevent invalid or unsafe programs from reaching the device.

Guardrails include:

• amplitude and power limits,
• forbidden channel combinations,
• timing alignment checks,
• thermal load constraints,
• crosstalk risk limits,
• measurement and reset sequencing rules,
• hardware interlock integration,
• permission boundaries for experimental control features.

flowchart TD
    Program[Control program] --> Static[Static validation]
    Static --> Limits[Hardware limit checks]
    Limits --> Sim[Timing and conflict simulation]
    Sim --> Approval{Allowed?}
    Approval -- no --> Reject[Reject with diagnostics]
    Approval -- yes --> Arm[Arm execution]
    Arm --> Runtime[Runtime monitors]
    Runtime --> Abort{Unsafe condition?}
    Abort -- yes --> Stop[Abort / safe state]
    Abort -- no --> Complete[Complete shot batch]

The operator should assume malformed control programs will occur. The system should fail closed.

8.10 Observability at the control layer

Control-plane telemetry should include both expected and observed behavior:

User-facing result reports do not need every trace, but the platform must preserve enough for audits and root-cause analysis.

8.11 Operator checklist

• Keep the user abstraction above raw control unless there is a deliberate expert path.
• Treat timing as correctness, not merely performance.
• Separate real-time, near-time, and batch-time loops.
• Carry calibration snapshot identifiers into the control program.
• Validate timing, channel, power, and safety constraints before execution.
• Design feedback paths around measured latency, not desired latency.
• Store enough control telemetry to reconstruct incidents.
• Use a control IR that can represent hardware constraints explicitly.

8.12 Chapter summary

The control plane is the bridge between symbolic quantum programs and physical operations. It is where schedules become signals, measurements become bits, and bits may become immediate decisions. A platform that hides the control plane from users can still expose its consequences: timing constraints, feedback limits, calibration identifiers, and result provenance.

Additional technical sources: [R254], [R300].