Tackling the Challenges of Adding Pulse-level Support to a Heterogeneous HPCQC Software Stack: MQSS Pulse

TL;DR

The paper addresses the challenge of adding native pulse-level control to heterogeneous HPCQC software stacks, using MQSS as a case study. It proposes a cross-layer design that introduces three pulse abstractions—$ports$, $frames$, and $waveforms$—and extends interfaces across programming, intermediate representation, and backend to support pulse-level workflows. Key contributions include a C/C++ pulse API to reduce runtime overhead, a pulse dialect within LLVM-MLIR for integrated gate- and pulse-level compilation, and an extension to the Quantum Device Management Interface (QDMI) plus a portable pulse exchange format (Pulse Profile) for hardware-agnostic pulse payloads. The work enables end-to-end pulse-aware compilation and runtime execution in HPCQC environments, bridging classical workflows with hardware-level control to unlock calibrations, custom waveforms, and hardware-informed optimizations in heterogeneous quantum accelerators.

Abstract

We study the problem of adding native pulse-level control to heterogeneous High Performance Computing-Quantum Computing (HPCQC) software stacks, using the Munich Quantum Software Stack (MQSS) as a case study. The goal is to expand the capabilities of HPCQC environments by offering the ability for low-level access and control, currently typically not foreseen for such hybrid systems. For this, we need to establish new interfaces that integrate such pulse-level control into the lower layers of the software stack, including the need for proper representation. Pulse-level quantum programs can be fully described with only three low-level abstractions: ports (input/output channels), frames (reference signals), and waveforms (pulse envelopes). We identify four key challenges to represent those pulse abstractions at: the user-interface level, at the compiler level (including the Intermediate Representation (IR)), and at the backend-interface level (including the appropriate exchange format). For each challenge, we propose concrete solutions in the context of MQSS. These include introducing a compiled (C/C++) pulse Application Programming Interface (API) to overcome Python runtime overhead, extending its LLVM support to include pulse-related instructions, using its C-based backend interface to query relevant hardware constraints, and designing a portable exchange format for pulse sequences. Our integrated approach provides an end-to-end path for pulse-aware compilation and runtime execution in HPCQC environments. This work lays out the architectural blueprint for extending HPCQC integration to support pulse-level quantum operations without disrupting state-of-the-art classical workflows.

Figures (3)

• Figure 1: A top-down approach to : tracing the flow from quantum algorithms and their circuit representations to pulse-level control, i.e., electromagnetic waveforms on target hardware.
• Figure 2: MQSS architecture overview: MQSS Adapters (e.g., Qiskit, CUDAQ, PennyLane, and its native C-based QPI) submit gate- and pulse-based jobs to the MQSS Client, which handles automatic routing for both local HPC jobs and remote submissions. The encompasses MQSS's second-level scheduler, its JIT LLVM-based compiler, and supporting libraries. QDMI exposes device capabilities (ports, frames, waveforms, timing/granularity and constraints) to during JIT compilation and to the MQSS Adapters via the MQSS Client during runtime execution. Example QDMI Devices shown for illustrating target diversity: classical simulators, databases, ISVs, data centers, and superconducting, neutral atom, and trapped-ion quantum accelerators.
• Figure 3: An overview of the QDMI interface, its components, and how they are connected across the three QDMI entities. Adding pulse-specific device, site, and operation properties will enable clients to retrieve information---such as the level of pulse access, available channels, and more---via the existing 'Query' interface. Note that submitting jobs with pulse-payload does not require modifications to the 'Job' interface; it only requires adding a single enumeration value.