Also known as pulse-level compilation · pulse compilation · pulse-level programming · intermediate representation · OpenPulse · quantum compiler · pulse scheduling
Pulse-level compilation turns a quantum program into the control signals that run it. A standard compiler maps
a circuit onto native gates and replaces each gate with a pulse from a calibrated library. Pulse-level compilation
breaks that abstraction where it pays off. It optimizes pulses for whole blocks of gates, reshapes calibrated
pulses to implement gates the library lacks, or lets programs specify pulses directly. The goal is the same as in
Quantum gate synthesis — shorter, more accurate operations — but applied across a whole program.
The standard pipeline
A circuit is decomposed into native gates, mapped and routed onto the device’s connectivity, and scheduled as a
sequence of pulses. Some operations cost nothing: \(Z\) rotations can be implemented “virtually” as phase changes of
later drives [1]. Calibration keeps the library accurate, and closed-loop tune-up can use
randomized benchmarking as its cost [2] or fit a device model along the way [3]. See
Closed-loop & in-situ optimization and System identification for control.
Compiling blocks with optimal control
Aggregated instructions. The gate set is an artificial boundary: a block of gates on a few qubits can be
implemented by one pulse much shorter than the sum of its gates. Aggregating instructions into blocks of up to 10
qubits and compiling each block with optimal control reduced program latency [4]. See
GRAPE.
Compilation latency. Optimal-control compilation is slow, which is a problem when compilation and execution
alternate, as in Variational algorithms & QAOA as control. Partial compilation pre-computes pulses for the parameter-independent
blocks, giving pulse speed-ups of 1.5–3× at a small fraction of the compilation cost [5].
Static pre-compilation combined with accelerated dynamic compilation reduces it further [6]. GPUs and
automatic differentiation speed up the underlying optimization [7].
Compiling from calibrated pulses
Full optimal control needs an accurate model of the device. A lighter approach starts from the existing
calibrations. Building pulses from calibrated gates rather than by optimal control gave 1.6× lower error rates and
2× faster execution on IBM devices [8]. Scaling calibrated cross-resonance pulses exposes a
continuous family of two-qubit gates. Combined with a Cartan decomposition of SU(4), this reduced the error of
arbitrary two-qubit gates by up to 50% and shortened QAOA schedules by up to 52%, with no extra calibration
[9].
Pulse-level programming
Interfaces. OpenPulse specified how pulse schedules are sent to cloud hardware [10]. Qiskit
Pulse implemented it, from calibrating cross-resonance gates to Hamiltonian characterization through the cloud
[11]. Qiskit deprecated its pulse module in version 1.3 (November 2024) and removed it in
version 2.0 (March 2025). OpenQASM 3 adds real-time control flow and lets programs describe operations at several
levels, down to calibrations [12].
Analog and neutral-atom devices. Pulser programs neutral-atom arrays at the pulse level, in digital and analog
modes [13].
Simulation. Circuits can be compiled to pulses on simulated processors and run with realistic noise
[14].
Variational algorithms at the pulse level. Pulses themselves can be the variational parameters, as in ctrl-VQE
[15] or adjoint-based pulse optimization for neutral-atom hardware [16]. See
Variational algorithms & QAOA as control.
The trade-off
Gates are an abstraction that pays for itself. They are calibrated once, benchmarked individually, portable across
devices, and come with the simple error models that error correction relies on. Pulse-level compilation gains time
and fidelity by giving some of this up. Its pulses are device-specific, harder to benchmark and only as good as the
model or calibration behind them.
Limitations
Custom block pulses are hard to characterize: randomized benchmarking applies to gate sets, not to one-off blocks.
Access to pulse-level control depends on the hardware provider and can change, as the removal of Qiskit Pulse
showed.
Key papers
Yunong Shi, Nelson Leung, Pranav Gokhale, Zane Rossi, David I. Schuster, et al.Optimized Compilation of Aggregated Instructions for Realistic Quantum ComputersProceedings of the Twenty-Fourth International Conference on Architectural Support for Programming Languages and Operating Systems, 1031-1044 (2019)doi
Aggregates circuit instructions into multi-qubit blocks and compiles each block into a custom optimal-control pulse.
Pranav Gokhale, Yongshan Ding, Thomas Propson, Christopher Winkler, Nelson Leung, et al.Partial Compilation of Variational Algorithms for Noisy Intermediate-Scale Quantum MachinesProceedings of the 52nd Annual IEEE/ACM International Symposium on Microarchitecture, 266-278 (2019)doi
Partial compilation — pre-computes optimal pulses for fixed blocks so that variational algorithms are not slowed by compilation.
Nathan Earnest, Caroline Tornow and Daniel J. EggerPulse-efficient circuit transpilation for quantum applications on cross-resonance-based hardwarePhys. Rev. Research3, 043088 (2021)doi
Pulse-efficient transpilation, which scales calibrated cross-resonance pulses instead of decomposing into CNOTs.
Thomas Alexander, Naoki Kanazawa, Daniel J Egger, Lauren Capelluto, Christopher J Wood, et al.Qiskit pulse: programming quantum computers through the cloud with pulsesQuantum Sci. Technol.5, 044006 (2020)doi
Qiskit Pulse — pulse-level programming of cloud quantum computers (since removed from Qiskit).
Andrew Cross, Ali Javadi-Abhari, Thomas Alexander, Niel De Beaudrap, Lev S. Bishop, et al.OpenQASM 3: A Broader and Deeper Quantum Assembly LanguageACM Transactions on Quantum Computing3, 1-50 (2022)doi
OpenQASM 3, an assembly language with real-time control flow and pulse-level calibration descriptions.
Software
Pulser — pulse-level and analog programming of neutral-atom devices, with a QuTiP-based emulator
qutip-qip — compiles circuits to pulses on simulated processors and simulates them with noise
References
David C. McKay, Christopher J. Wood, Sarah Sheldon, Jerry M. Chow and Jay M. GambettaEfficient Z gates for quantum computingPhys. Rev. A96, 022330 (2017)doi
J. Kelly, R. Barends, B. Campbell, Y. Chen, Z. Chen, et al.Optimal Quantum Control Using Randomized BenchmarkingPhys. Rev. Lett.112, 240504 (2014)doi
Nicolas Wittler, Federico Roy, Kevin Pack, Max Werninghaus, Anurag Saha Roy, et al.Integrated Tool Set for Control, Calibration, and Characterization of Quantum Devices Applied to Superconducting QubitsPhys. Rev. Applied15, 034080 (2021)doi
Yunong Shi, Nelson Leung, Pranav Gokhale, Zane Rossi, David I. Schuster, et al.Optimized Compilation of Aggregated Instructions for Realistic Quantum ComputersProceedings of the Twenty-Fourth International Conference on Architectural Support for Programming Languages and Operating Systems, 1031-1044 (2019)doi
Pranav Gokhale, Yongshan Ding, Thomas Propson, Christopher Winkler, Nelson Leung, et al.Partial Compilation of Variational Algorithms for Noisy Intermediate-Scale Quantum MachinesProceedings of the 52nd Annual IEEE/ACM International Symposium on Microarchitecture, 266-278 (2019)doi
Jinglei Cheng, Haoqing Deng and Xuehai QiaAccQOC: Accelerating Quantum Optimal Control Based Pulse Generation2020 ACM/IEEE 47th Annual International Symposium on Computer Architecture (ISCA), 543-555 (2020)doi
Nelson Leung, Mohamed Abdelhafez, Jens Koch and David SchusterSpeedup for quantum optimal control from automatic differentiation based on graphics processing unitsPhys. Rev. A95, 042318 (2017)doi
Pranav Gokhale, Ali Javadi-Abhari, Nathan Earnest, Yunong Shi and Frederic T. ChongOptimized Quantum Compilation for Near-Term Algorithms with OpenPulse2020 53rd Annual IEEE/ACM International Symposium on Microarchitecture (MICRO), 186-200 (2020)doi
Nathan Earnest, Caroline Tornow and Daniel J. EggerPulse-efficient circuit transpilation for quantum applications on cross-resonance-based hardwarePhys. Rev. Research3, 043088 (2021)doi
David C. McKay, Thomas Alexander, Luciano Bello, Michael J. Biercuk, Lev Bishop, et al.Qiskit Backend Specifications for OpenQASM and OpenPulse Experimentspreprint (2018)arXiv:1809.03452
Thomas Alexander, Naoki Kanazawa, Daniel J Egger, Lauren Capelluto, Christopher J Wood, et al.Qiskit pulse: programming quantum computers through the cloud with pulsesQuantum Sci. Technol.5, 044006 (2020)doi
Andrew Cross, Ali Javadi-Abhari, Thomas Alexander, Niel De Beaudrap, Lev S. Bishop, et al.OpenQASM 3: A Broader and Deeper Quantum Assembly LanguageACM Transactions on Quantum Computing3, 1-50 (2022)doi
Henrique Silvério, Sebastián Grijalva, Constantin Dalyac, Lucas Leclerc, Peter J. Karalekas, et al.Pulser: An open-source package for the design of pulse sequences in programmable neutral-atom arraysQuantum6, 629 (2022)doi
Boxi Li, Shahnawaz Ahmed, Sidhant Saraogi, Neill Lambert, Franco Nori, et al.Pulse-level noisy quantum circuits with QuTiPQuantum6, 630 (2022)doi
Oinam Romesh Meitei, Bryan T. Gard, George S. Barron, David P. Pappas, Sophia E. Economou, et al.Gate-free state preparation for fast variational quantum eigensolver simulationsnpj Quantum Inf7, 155 (2021)doi
Robert de Keijzer, Oliver Tse and Servaas KokkelmansPulse based Variational Quantum Optimal Control for hybrid quantum computingQuantum7, 908 (2023)doi
Recent papers
162 tracked papers since 2000 are classified
under this topic. See all ·
Feed
The use of reinforcement learning (RL) in the design of quantum control strategies for pulse level control of NISQ era quantum devices is attracting growing interest. Model-free RL, not requiring preexisting knowledge of the physical system, acts as a black-box optimization tool well suited for noisy devices. In this work, we provide a simulation-based analysis of the performance of model-free RL for state preparation and qubit gate design in a challenging setup: indirect control of NV nuclear spins in a spin-bath. In particular, the spin-bath is modeled via the generalized cluster correlation expansion accounting for magnetic impurities and intra-bath interactions. We analyze the performance of the RL agents by performing simulations with minimally observable environments and noisy, sparse rewards as introduced in (Phys. Rev. X 12, 011059), and compare them to other state-of-the-art black-box optimization tools.
Scaling fault-tolerant quantum computing (FTQC) requires orchestrating millions of operations continuously across a tightly coupled classical-quantum control stack. A critical challenge in this orchestration is determining the optimal hardware-software boundary, i.e., the Quantum Instruction Set Architecture (QISA). We focus on cryogenic, fixed-connectivity qubit platforms, such as superconducting and topological Majorana qubits. For these, existing QISA choices either operate at too low a level, violating cryogenic thermal budgets at scale, or at too high a level, imposing unrealizable complexity on the control engine. To reason about these tradeoffs, we introduce the ARIES instruction set hierarchy, which categorizes QISAs into distinct abstraction levels. To systematically evaluate these levels, we develop an end-to-end evaluation toolflow featuring a cycle-accurate classical driver and hardware engine simulator. Using eight quantum applications across superconducting and topological qubit platforms, we measure instruction bandwidth, transceiver power dissipation, and measurement processing overheads. We demonstrate that while physical-level abstractions exceed the thermal limits of dilution refrigerators by orders of magnitude, canonical-level abstractions significantly underestimate hardware routing congestion and execution runtimes. Our Level 4 QISA (local logical operations) offers an optimal architectural balance. As quantum hardware platforms scale toward FTQC in the coming years, our findings provide concrete architectural guidance for the design of their classical control stacks and instruction interfaces.
Fault-tolerant quantum design relies on simulating noisy quantum error correction (QEC) circuits with hundreds to thousands of physical qubits and large circuit depths. High-throughput stabilizer simulators, such as Stim, are the de facto tools for this regime. However, these simulators typically support only Clifford gates and stochastic Pauli noise. As a result, more realistic device noise models-such as coherent control errors and thermal relaxation-are often approximated using Pauli Twirling. This replacement offers speed but can introduce inaccuracies. To address this, we propose QuasiStim for scalable exact QEC simulation of realistic noise, with QuasiFold as a compiler frontend and DeltaFrame as a sampling backend. QuasiFold lowers sampling overhead by merging equivalent non-Pauli sites in the quantum circuit. DeltaFrame samples the resulting stabilizer trajectories by reusing precomputed predicted references instead of resimulating the full tableau for each shot. QuasiFold can reduce the number of shots by over $100\times$ on bivariate-bicycle (BB) codes. Compared to a per-shot tableau simulator, DeltaFrame is $166\times$--$1331\times$ faster on rotated surface-code memory under coherent $R_Z$ noise as $d$ grows from 5 to 35. QuasiStim also makes the PTA bias measurable: the gap is non-negligible and varies with noise strength, decoder, and circuit schedule. QuasiStim will be open-sourced upon publication at https://github.com/isaachyw/QuasiStim
A pulse-level quantum control program is written against a device whose limits are recorded, if at all, in vendor documentation and source code. A program that exceeds them can be refused at compile time. It can also be accepted and silently altered, or compile and then fail at the board. In the last two cases the experiment runs, and the data does not correspond to the program that was written. We present qconform, a checker that decides whether a pulse program is realizable on a device, given a versioned capability descriptor for that device. Every constraint in a descriptor cites the toolchain observation that established it. The checker is design-time, offline, and deterministic, and it uses no floating point. It reports a verdict, the rules it applied, and a coverage manifest that names what it did not check. We evaluate qconform by differential testing against the QICK and Qblox toolchains, on three QICK board configurations and one Qblox cluster. Over 1263 program runs of 969 distinct programs, the checker accepted no program that a toolchain refuses. On both vendors, a descriptor pinned to one toolchain release accepts programs that older releases refuse. The evaluation also found ten defects in the checker and its descriptors, all fixed.
Classical simulation supports the development and validation of quantum algorithms through full-state inspection, controlled noise models and backpropagation, albeit for small quantum systems. Existing frameworks offer gate-level execution, differentiable pulse-level dynamics or optimised hardware execution. Just another quantum simulator (JAQSI) combines gate- and pulse-level simulation in one differentiable circuit model built upon JAX. Circuits are represented as pure functions of numerical inputs which support vectorised batches and JIT compilation. Within a single circuit, matrix-defined operations, gates synthesised from Hamiltonian time evolution and noise channels can be composed freely. For a fast simulation, gate and channel fusion reduces passes over the state, while adjoint differentiation computes expectation-value gradients with a constant number of statevectors. At pulse level, JAQSI reduces evolution under single-term Hamiltonians to a scalar pulse-area integral and reuses cached execution plans and compiled solvers. In a benchmark we compare JAQSI with PennyLane, Qiskit, Qibo, Qulacs, QuTiP and dynamiqs. At gate level, we observe performance either on par or an order of magnitude faster across statevector, density, noise and gradient simulation than the compared simulators up to 12 qubits. Beyond 18 qubits, JAQSI is on par with PennyLane Lightning in both statevector and gradient simulation. In the statevector and noisy density-matrix pulse benchmarks, it is at least 5 times faster than the other simulators, even with its closed-form solve disabled. Disabling the latter increases its runtime by at most a factor of 1.5. We provide JAQSI as open-source software on GitHub and PyPI.