Firmware, FPGA, and Embedded Control Lifecycle

The quantum software stack does not end at the SDK. Between a circuit and a measured bit string sit pulse generators, waveform memories, timing systems, FPGAs, digitizers, microwave chains, feedback paths, and embedded software. Changes at this layer can silently change the semantics of a quantum workload.

OpenQASM 3 defines timing constructs and calibration hooks for expressing experiments near the hardware boundary. Qiskit Dynamics remains a historical example of pulse-level simulation tooling, but its repository was archived in October 2025 and is no longer actively maintained [R138]. A language or simulator does not itself grant pulse access on hardware: access depends on the provider and target. The more physical control a platform exposes, the more governance it needs.

78.1 Control lifecycle stack

Diagram loads as you read

78.1 Control lifecycle stack · Figure 1

View diagram source

flowchart TB
    Program[Quantum program] --> IR[IR or assembly]
    IR --> Schedule[Timed schedule]
    Schedule --> Pulse[Pulse artifact]
    Pulse --> Firmware[Firmware and FPGA image]
    Firmware --> Electronics[Control electronics]
    Electronics --> Device[Quantum device]
    Device --> Readout[Readout and classification]

Every layer has a version. The evidence package should record them.

78.2 Firmware release pipeline

Diagram loads as you read

78.2 Firmware release pipeline · Figure 2

View diagram source

flowchart LR
    Change[Change request] --> Sim[Simulation]
    Sim --> Bench[Bench test]
    Bench --> Shadow[Shadow target]
    Shadow --> Canary[Hardware canary]
    Canary --> Rollout[Controlled rollout]
    Rollout --> Monitor[Monitor metrics]
    Monitor --> Promote{Promote?}
    Promote -- yes --> Stable[Stable release]
    Promote -- no --> Rollback[Rollback]

A firmware release should not be judged only by whether it loads. It should be judged by whether calibrated operations, timing assumptions, readout classification, and feedback behavior remain valid.

78.3 Timing contract

Diagram loads as you read

78.3 Timing contract · Figure 3

View diagram source

flowchart TB
    Timing[Timing contract] --> Clock[Clock source]
    Timing --> Latency[Feedback latency]
    Timing --> Jitter[Jitter budget]
    Timing --> Alignment[Channel alignment]
    Timing --> Duration[Instruction duration]
    Timing --> Drift[Timing drift monitor]

Timing is a semantic dependency. If a compiler assumes a gate duration or feedback latency, the embedded-control layer must either honor that assumption or advertise a new target profile.

78.4 Change blast radius

Diagram loads as you read

78.4 Change blast radius · Figure 4

View diagram source

flowchart LR
    FirmwareChange[Firmware change] --> Gates[Native gate behavior]
    FirmwareChange --> Readout[Readout pipeline]
    FirmwareChange --> Calibration[Calibration validity]
    FirmwareChange --> Compiler[Compiler target]
    FirmwareChange --> Evidence[Evidence comparability]
    FirmwareChange --> Safety[Safety interlocks]

A small control change can invalidate a month of benchmark trend data. The platform needs a blast-radius assessment before deployment.

78.5 Embedded telemetry

Diagram loads as you read

78.5 Embedded telemetry · Figure 5

View diagram source

flowchart TB
    Controller[Controller] --> ClockTelemetry[Clock and sync telemetry]
    Controller --> Buffer[Buffer and underrun telemetry]
    Controller --> Waveform[Waveform version telemetry]
    Controller --> Feedback[Feedback-path telemetry]
    Controller --> Error[Hardware error codes]
    ClockTelemetry --> Collector[Telemetry collector]
    Buffer --> Collector
    Waveform --> Collector
    Feedback --> Collector
    Error --> Collector

The telemetry system should detect when a job was technically accepted but physically compromised by underruns, timing errors, thermal events, or classifier failures.

78.6 Control rollback

Diagram loads as you read

78.6 Control rollback · Figure 6

View diagram source

stateDiagram-v2
    [*] --> Stable
    Stable --> Candidate: release staged
    Candidate --> Canary: canary run
    Canary --> Stable: promote
    Canary --> RolledBack: regression
    RolledBack --> Stable: previous image restored
    Candidate --> Blocked: safety or timing violation

Rollback must include more than firmware bits. It may require restoring calibration parameters, target profiles, compiler settings, and evidence labels.

78.7 Hardware-software interface review

Diagram loads as you read

78.7 Hardware-software interface review · Figure 7

View diagram source

flowchart TB
    Review[HSI review] --> Semantics[Instruction semantics]
    Review --> Timing[Timing semantics]
    Review --> Safety[Safety and interlocks]
    Review --> Observability[Telemetry coverage]
    Review --> Rollback[Rollback path]
    Review --> Evidence[Evidence compatibility]

The hardware-software interface review is the place where physicists, controls engineers, compiler engineers, and platform operators converge.

78.8 Operating rule

Treat embedded control images like production software and like laboratory instrumentation. They need release notes, rollback, calibration impact analysis, and safety review.

Diagram loads as you read

78.8 Operating rule · Figure 8

View diagram source

flowchart LR
    ControlChange[Control change] --> Review[Review]
    Review --> Release[Release]
    Release --> Evidence[Evidence annotation]
    Evidence --> Learning[Post-release learning]

Additional technical sources: [R25].