Qiskit QM Provider¶
Welcome to the Qiskit-QM-Provider documentation!
This project is a toolbox for crossing abstraction layers between high-level circuits written in Qiskit and low-level QUA control programs on Quantum Machines’ Quantum Orchestration Platform (QOP).
Author: Arthur Strauss — Centre for Quantum Technologies, National University of Singapore, in collaboration with Quantum Machines Ltd.
License: Apache 2.0 (see the LICENSE.md file in the repository).
Documentation map¶
This site has two complementary layers:
Guides (sidebar pages below) — purpose, architecture, and practical snippets: why and how to use each part of the toolbox.
API Reference — auto-generated signatures and docstrings from the Python source: the authoritative reference for every class and method.
Runnable scripts live in the examples folder.
What this toolbox gives you¶
The provider supports two layers of use:
Traditional —
QMBackend.run()and V2 primitives (QMSamplerV2,QMEstimatorV2) compile Qiskit circuits to QUA and execute them on QOP, with optional real-time parameter streaming. Large circuit batches are automatically chunked into multiple QUA programs viamax_circuits(default 30); this applies tobackend.run,QMSamplerV2, andQMEstimatorV2. See Backend guide.Extended (hybrid) — embed Qiskit circuits as QUA macros inside larger programs via
quantum_circuit_to_qua, withParameterTableas the classical-quantum contract.
Underneath both paths, the backend reads your QuAM machine description to build a Qiskit Target (connectivity, native gates, qubit properties), so the full transpiler stack applies. You can bring your own QuamRoot and QMBackend subclasses, or start from FluxTunableTransmonBackend.
Installation¶
pip install qiskit-qm-provider
quam-builder is required for the built-in FluxTunableTransmonBackend and related QuAM components. It is not published on PyPI and must be installed from source:
pip install git+https://github.com/qua-platform/quam-builder.git@v0.4.0
For IQCC cloud access and QM SaaS simulation:
pip install qiskit-qm-provider[iqcc]
pip install qiskit-qm-provider[qm-saas]
Open Acceleration Stack (OAS) and QUARC¶
Advanced real-time parameter workflows can be accelerated through Quantum Machines’ Open Acceleration Stack (OAS), which features an OPNIC link enabling high-bandwidth classical–quantum communication via QUARC. QUARC is currently in a private alpha and is not publicly available. If you are interested in using these capabilities, please reach out to the Quantum Machines team.
Using Qiskit Experiments with this provider¶
Many users want to combine Qiskit Experiments with this provider (especially via IQCCProvider). Two caveats are worth reading before you start:
1. Match the tool to the execution model¶
Qiskit Experiments typically expresses characterization as a large batch of pre-defined circuits — often nearly identical except for one swept parameter (Rabi amplitudes, Ramsey delays, and so on). That pattern mirrors AWG-style playback: every variant is compiled and loaded ahead of time.
QUA is designed differently: one program with real-time loops, streaming, and on-device parameter updates. For many calibration sweeps, Qualibrate and qua-libs are the natural QUA-native counterparts.
This provider shines when you invert the usual assumption: use Qiskit for circuit authoring (synthesis, visualization, transpilation, portability) and wrap those circuits as QUA macros inside richer real-time programs — not when you treat Qiskit as the entire control stack and never engage with QUA.
IQCC + Experiments (see examples/iqcc_t1_experiment.py) is supported and useful, but ask whether a batch-of-circuits experiment is really what you need, or whether a parameterized QUA loop (with ParameterTable / quantum_circuit_to_qua) would be more efficient on QOP. See Workflows — Qiskit Experiments for the full discussion.
2. Classified measurement outcomes only¶
Experiments that need raw I & Q, kerneled shots, or other non-discriminated data are not yet supported end-to-end. Only classified results (0/1 counts / bitstrings) are reliably returned today. Contributors are welcome if IQ/kernels matter for your workflow.
(Note: meas_level options may appear in the API, but non-classified paths are not production-ready.)
Where to go next¶
Use the sidebar to browse guides, then dive into the API Reference for signatures:
Installation — package install, quam-builder, optional extras, and OAS/QUARC.
Workflows — routing guide for the five main paths through the toolbox.
Providers — obtain a backend for local QOP, QM SaaS, or IQCC.
Backend & Utilities —
QMBackend, embedding, utilities, custom gates.Measurement outputs —
QuaCircuitCompilation,MeasurementOutcomeTable,MeasurementRegisterField.Primitives —
QMSamplerV2andQMEstimatorV2.Parameter Table —
ParameterTableand real-time data flow.Jobs — job handles,
program,qm_job, IQCCrun_data, and printing QUA withgenerate_qua_script.Error-Correction Workflow — hybrid EC pattern with
ParameterTable.API Reference — autodoc pages for all public classes and functions.
Design philosophy¶
Working at the intersection of algorithms and control is hard. This provider is designed to:
keep the Qiskit user experience for circuit design and experimentation,
expose QOP/QUA features (real-time feedback, streaming, hybrid control) without rewriting everything as low-level QUA,
make it easy to embed Qiskit circuits inside larger QUA programs with a shared calibration model.
The compiler’s value is not “hide QUA behind Qiskit forever.” It is frictionless advanced QUA — real-time logic, streaming, control flow — with the quantum-writing parts expressed as reusable, transpilable, debuggable Qiskit QuantumCircuit macros.
Who is this for?¶
Experimentalists on Quantum Machines hardware who want Qiskit ergonomics with QUA power underneath.
Researchers building hybrid classical–quantum control loops and streaming-heavy workloads.
Developers who need a documented bridge between Qiskit abstractions and QOP/QUA.
Start with Providers and Backend & Utilities, then Primitives and Parameter Table as you move toward hybrid programs.
Experimental project — feedback welcome¶
This provider is experimental by design. If you have suggestions, use cases, or integration issues, contact Arthur Strauss at arthur.strauss@u.nus.edu.