Source-linked AI summary
Quantum computing with Qiskit
Ali Javadi-Abhari, Matthew Treinish, Kevin Krsulich, Christopher J. Wood, Jake Lishman, Julien Gacon, Simon Martiel, Paul D. Nation, Lev S. Bishop, Andrew W. Cross, Blake R. Johnson, Jay M. Gambetta
TL;DR
Quantum-computing research needs software that can represent, transform, and execute programs across abstraction levels and hardware platforms. This paper presents Qiskit’s architecture and design, demonstrates an end-to-end Hamiltonian-simulation workflow, and discusses its ecosystem and future scope. The paper concludes that Qiskit 1.0 provides the maturity, stability, and performance for utility-scale quantum computational workflows.
Problem
Quantum computing requires software that supports varied circuit abstractions, hardware targets, quantum-classical computation, and evolving research workflows.
Method
The paper describes Qiskit’s design philosophy, architecture, core components, end-to-end workflow, extensibility, and ecosystem through technical discussion and examples.
Results
Qiskit 1.0 has reached a stage of maturity, stability, and performance that enables utility-scale quantum computational workflows.
Takeaways & Limitations
Qiskit’s flexible circuit model and retargetable transpiler support computations across qudits, Bosonic modes, measurement-based and Pauli-based models, and incoherent noise.
Abstract
from arXiv · showhide
We describe Qiskit, a software development kit for quantum information science. We discuss the key design decisions that have shaped its development, and examine the software architecture and its core components. We demonstrate an end-to-end workflow for solving a problem in condensed matter physics on a quantum computer that serves to highlight some of Qiskit's capabilities, for example the representation and optimization of circuits at various abstraction levels, its scalability and retargetability to new gates, and the use of quantum-classical computations via dynamic circuits. Lastly, we discuss some of the ecosystem of tools and plugins that extend Qiskit for various tasks, and the future ahead.
I. INTRODUCTION
Qiskit is an open-source quantum-computing toolkit designed to support research through modular, extensible, fast, and hardware-retargetable software. Its architecture spans abstract circuit representation through hardware-compatible transpilation and execution.
- Adoption and use: Qiskit has supported utility-scale quantum workflows, including demonstrations involving up to 133 qubits and O(10^4) two-qubit entangling gates.The paper also reports evidence of utility and fault-tolerant magic-state preparation demonstrations using Qiskit.
- Paper contribution: The paper demonstrates Qiskit through an end-to-end Hamiltonian-simulation workflow using hardware-native gates, dynamic circuits, and error-suppression techniques.The workflow is presented as a demonstration of Qiskit’s capabilities on quantum hardware.
- Software scope: Qiskit supports quantum-computing research with tools for representing and compiling circuits across multiple abstraction levels.Its scope covers abstract Hamiltonian circuits, gate synthesis, routing, optimization, scheduling, and hardware-compatible ISA circuits.
- Design philosophy: Qiskit’s modular design enables external circuit, synthesis, and optimization projects to integrate through plug-in interfaces.The paper presents modularity and extensibility as principal design forces.
- Design philosophy: Qiskit balances rapid prototyping with performance by keeping Python as the main environment while implementing performance-critical components in Rust.About 6% of the code base is currently written in Rust, with performance tracked through benchmarks.
- Design philosophy: Qiskit uses hardware-agnostic circuit representations while its retargetable transpiler optimizes circuits for diverse instruction-set architectures.The Target class describes available instructions, timings, error rates, and hardware constraints.
4. Interoperability across abstraction levels
Qiskit allows users to combine circuit abstractions with real-time and near-time classical computation, supporting iterative workflows from circuit construction through evaluation and post-processing.
- Abstraction levels: Qiskit supports programming at different abstraction levels, from high-level development to gate timing and dynamics.These abstraction levels can be combined within compatible circuit descriptions.
- Quantum-classical integration: Dynamic circuits integrate measurement-conditioned classical control flow with quantum operations while qubits remain coherent.Qiskit’s model supports classical operations concurrent with quantum operations, including control flow based on measurement outcomes.
- Quantum-classical integration: Near-time classical computation supports parameter binding, just-in-time compilation, circuit-parameter optimization, and error mitigation.Qiskit can be integrated into runtime environments that colocate classical processors with quantum hardware.
- Circuit evaluation: Qiskit evaluates circuits through sampling or expectation-value estimation using a common primitives interface.Samplers return measurement outcomes, while estimators return post-processed expectation values.
- Qiskit patterns: A common Qiskit workflow maps a classical problem to circuits, transpiles them for target hardware, evaluates them, and post-processes the results.The workflow may iterate by generating new circuits from earlier circuit batches.
- Tooling: Visualization tools expose circuits, hardware targets, outputs, transpiler passes, and circuit graph structures for inspection and debugging.These capabilities support understanding circuit behavior and execution-related information.
9. Tensor ordering convention
Qiskit centers its flexible software model on quantum circuits that can express operations, control flow, timing, and multiple internal representations. Its tensor-ordering convention is explicit but remains a convention rather than a universal rule.
- Tensor ordering convention: Qiskit’s tensor products follow Q2 ⊗ Q1 ⊗ Q0, so Pauli ZX denotes Z1X0 and basis states use the corresponding register ordering.The convention yields computational-basis labels aligned with classical-register numbering.
- Tensor ordering convention: Qiskit’s qubit-ordering convention is a choice that may differ from textbook definitions and may be natural for some tasks but not others.Instruction order and matrix-multiplication order also require explicit conventions.
- Circuit model: Quantum circuits are Qiskit’s core component, expressing computations as time-ordered instructions that other tools can transform and analyze.The circuit data structure supports operations on both quantum and classical data.
- Circuit model: Qiskit circuits can mix gates, measurements, higher-level operators, real-time classical computation, control flow, timing, and continuous-time dynamics.Circuits can also be composed as building blocks and used at multiple abstraction levels.
- Internal representations: Circuit representations include instruction lists, DAGs, canonical dependency graphs, and structured subcircuits suited to different rewriting tasks.These representations make operations, information flow, or true dependencies explicit as needed.
- Internal representations: Qiskit keeps circuits lightweight through reusable blocks, singleton standard gates, and lazy synthesis or lowering of abstract operations.The transpiler performs deferred circuit synthesis and lowering when required.
- Circuit examples: Qiskit examples span high-level phase estimation, classically controlled entanglement distillation, parameterized Hamiltonian simulation, and GHZ preparation.These examples illustrate the circuit model’s range across abstraction levels and execution patterns.
B. Pass Manager
Qiskit’s Pass Manager organizes reusable, composable, and conditional circuit-transformation pipelines that translate and optimize circuits for target devices while preserving circuit-based inspection.
- Transpiler: The transpiler applies proven translation and optimization passes to both abstract and hardware-aware circuits.It produces device-compatible and device-optimized implementations while exposing APIs for extensions.
- Transpiler: Because transpiler output remains a quantum circuit, users can inspect, characterize, modify, and compare transformed circuits with the same tooling.This supports evaluating execution cost and experimenting with alternative optimization techniques.
- Pass Manager: The Pass Manager executes composable, reusable, semantic-preserving transformation pipelines with flow control based on device and circuit properties.Its architecture is similar to classical compiler infrastructures such as LLVM.
- Pass Manager: Standardized compilation stages provide hook points for transpiler plugins and extensions to alter predefined Pass Managers.These Pass Managers encode optimization and translation practices across applications and hardware architectures.
- Primitives: Primitives provide a consistent execution interface: samplers return measurement outcomes, while estimators return post-processed expectation values.They execute circuits through simulator or hardware backends.
- Primitives: A Qiskit runtime environment colocates general-purpose classical processors with quantum hardware to reduce latency in quantum-classical workloads.Near-time runtime computation is distinct from the more timing-constrained classical computation inside dynamic circuits.
IV. QISKIT BY EXAMPLE
Qiskit is demonstrated through an end-to-end condensed-matter workflow that solves a spin-lattice problem on a quantum computer and highlights general software capabilities.
- The example uses Qiskit to solve a condensed-matter physics problem on a quantum computer.
A. Ising model simulation on a quantum computer
The experiment simulates an Ising spin model with lattice interactions and local magnetic fields on IBM Pinguino1, a 127-qubit heavy-hexagonal device.
- The simulated system has Ising interactions between lattice sites and a local magnetic field on each site.
- The experiment runs on IBM Pinguino1, which provides 127 fixed-frequency transmon qubits in a heavy-hexagonal architecture.
B. Scalablility
Qiskit scales the Ising simulation through efficient circuit handling, parameterized templates, hardware-aware layering, transpilation, scheduling, and primitive-based evaluation.
- Qiskit uses memory-efficient circuit representations, Rust-based transpilation, and parameter binding to process many large or similar circuits.Parameter binding lets lower-level hardware reuse one circuit template with different substitutions.
- A 23-qubit hardware subgraph is edge-colored so nonintersecting qubit pairs can interact simultaneously.The edge-coloring produces layers of compatible two-qubit interactions.
- Each Trotter step contains three layers of ZZ interactions and one layer of parameterized X rotations, with 0 to 9 steps evaluated.The ZZ angle is fixed at π/8, while X-rotation angles are bound later for different kick strengths.
- Figure 4 compares heavy-hexagonal and honeycomb instances, with 23 and 12 qubits respectively, across transpilation and execution strategies.The honeycomb lattice requires hardware mapping, while the heavy-hexagonal lattice matches the hardware topology.
- The pass manager transforms circuits for target hardware and inserts dynamical decoupling sequences for noise suppression.
- The Estimator primitive evaluates observable expectation values, producing average magnetization across Trotter steps and kick strengths.
C. Retargetable transpilation
Qiskit’s transpiler can retarget circuits to overcomplete, heterogeneous gatesets, including partially available ZX rotations, to shorten circuits and improve simulation results.
- The transpiler can target nonstandard and heterogeneous gates, including a partial ZX rotation enabled by shorter cross-resonance interactions.
- An overcomplete gateset can be used opportunistically on available edges, even when the new gate is not calibrated everywhere.
- Significantly reduced circuit durations correspond to improved Ising model simulations after retargeting to the new gateset.
D. Dynamic circuit adaptation
Qiskit uses dynamic circuits to simulate a honeycomb Ising lattice while reducing circuit depth relative to swap-based mapping. Mid-circuit measurements, feed-forward, parallelization, and conditional operations support the workflow, which shows a slight experimental improvement.
- The honeycomb lattice is harder to simulate classically because each node has degree 3, compared with 2.4 for the heavy-hex lattice.
- Dynamic circuits replace swap-based routing with mid-circuit measurements and real-time classical feed-forward, producing shorter-depth circuits.
- The workflow constructs honeycomb coupling maps, builds parameterized circuits with repeated Trotter steps, transpiles them for a selected layout, and evaluates magnetization.
- The circuit computes parities into ancillas, applies rotations, measures ancillas in the X basis, and conditionally applies Pauli corrections and resets.
- Because ZZ interactions commute, CX layers can parallelize and the measurement-based construction reaches measurement-depth 1.
- The dynamic-circuit execution shows a slight improvement over the swap-based approach, while avoiding error-mitigation methods with large sampling overhead.
V. QISKIT ECOSYSTEM
Qiskit supports a broad ecosystem of open-source packages and research tools that extend its core capabilities across simulation, hardware, algorithms, transformations, and interoperability.
- Open-source packages built on Qiskit extend its functionality with high-performance simulation, hardware calibration, characterization, and open-system simulation tools.
- Qiskit-based research includes circuit transformation, resource optimization, pulse and timing methods, error suppression, new gates, language design, and compiler verification.
- Qiskit’s flexible circuit model and retargetable transpiler support qudits, Bosonic modes, measurement-based and Pauli-based computation, incoherent noise, and multiple hardware platforms.
- OpenQASM connects Qiskit to a wider quantum-software ecosystem through tools built around the language and tools supporting serialization to and from it.
VI. CONCLUSIONS
The paper presents Qiskit’s architecture, core components, and hardware workflows, positioning version 1.0 as a mature foundation for utility-scale quantum computation. It also frames future progress around continued software–hardware co-design.
- Quantum computing’s path toward useful, classically intractable tasks requires advances across architectures, compilers, error correction, error suppression, mitigation, algorithms, and applications.
- The paper discusses Qiskit’s software architecture, key components, and workflows for exploring quantum algorithms on today’s hardware.
- With version 1.0, Qiskit is described as having the maturity, stability, and performance needed for utility-scale quantum computational workflows.
Appendix A: Suppressing errors in dynamic circuits
The dynamic-circuit experiment suppresses latency-induced decoherence and crosstalk during honeycomb Ising simulation, but current control and ISA constraints limit timing precision and parallel execution.
- The appendix analyzes real-time classical control flow in dynamic circuits and uses it to suppress known coherent errors.
- Measurements lasting 1400 ns require dynamical decoupling during ancilla measurement to reduce decoherence on data qubits.
- Feed-forward latency of 1060 ns creates periods with decoherence and correlated crosstalk, while the available control electronics prevent quantum gates during instruction evaluation.
- A switch-case structure reduces serial control-flow evaluation, and conditional inverse-Z rotations compensate crosstalk according to ancilla states.
- Conditional X gates reset ancillas without using potentially long reset instructions, and the combined suppression techniques support the dynamic circuits’ reported performance.
- The current Heron ISA omits timing data for classical expressions and branching and serializes control flow, limiting short-duration dynamic circuits.
- Future ISA constraints aim to enable parallel execution of independent control-flow blocks, while stretches would express timing intent without requiring exact timing data.