CUDA-Q Logical: Retargetable Compilation for Fault-Tolerant Quantum Computing

AI summary

Overview

Research area: Quantum computing systems — fault-tolerant compilation, quantum error correction (QEC) tooling, compiler intermediate representations, and resource estimation.

Technical level: Advanced. The paper assumes familiarity with stabilizer codes, detectors/decoders, MLIR-style compiler infrastructure, and quantum resource estimation, though its central argument (one program, many architectures, traceable costs) is stated in accessible terms.

Scope (one sentence): The paper presents CUDA-Q Logical, an MLIR-based, extensible compiler infrastructure from NVIDIA that progressively lowers a logical quantum program through five verified semantic profiles (P0 logical intent, P1 logical architecture, P2 QEC binding, P3 physical materialization, P4 real-time control), and derives every resource estimate directly from the compiled artifacts so that architectures can be compared and costs attributed to specific design choices.

What This Paper Is About

Building a fault-tolerant quantum computer requires connecting many separate pieces: logical programs, error-correcting codes, fault-tolerant operation ("gadget") definitions, physical scheduling, decoding, and real-time classical feedback. Today these are handled by specialized tools that are stitched together by hand, which discards the assumptions and provenance linking a resource estimate to the compilation step that produced it. CUDA-Q Logical's goal is a single retargetable compiler stack in which each layer preserves the meaning of the layer above, verification checks every step, and all resource numbers are reports over compiler artifacts rather than standalone calculations.

Key Contributions

1. A five-level verified lowering pipeline (P0–P4). Using MLIR dialects, the authors express target-independent logical intent (P0), a code-independent logical architecture (P1), a QEC binding (P2), physical materialization and scheduling (P3), and real-time control (P4). Each lowering preserves established meaning, adds only the commitments owned by its destination profile, and verifies the result. Compilation can stop at any verified profile the selected target accepts.

2. A logical virtual machine (LVM) for code-independent placement. P1 introduces regions (typed pools of logical capacity, e.g., compute or memory), streams (abstract non-Clifford resource supply backed later by a factory or external source), and channels (allowed logical movement and interaction). Encodings and physical routes are deliberately absent at this level, so the same machine model can be reused across workloads and codes.

3. A typed QEC object model with composable detector semantics. P2 represents codes, code presentations, encodings, patches, gadgets, gadget detector contracts, protocols, and extended detector error models (EDEMs) as compiler artifacts. A builtin verify_gadget operation uses a single Choi-state probe to check both the detector contract and the declared logical action, and DetectorModelBuilder composes gadget EDEMs by contracting boundary data to produce the exact detector error model of the composite circuit.

4. Resource analysis unified with compilation. Every estimate is a report over an immutable compiler build, tied to that build's lineage: LogicalProfile at P0, witness-backed placement/capacity evidence at P1, FabricCounts and FabricEstimate at P2, ScheduleEstimate at P3, and SampleResult/RunResult/TwinEstimate from provenance-bound samples and runs at P3/P4. Because artifacts share a lineage, an analytical P2 cost and a scheduled P3 cost can be compared and any difference traced to work introduced during physical compilation.

5. Typed extensibility for external contributors. Independently developed codes, gadgets, detector contracts, decoders, architectures, and QPU providers enter through versioned typed interfaces below P0, so an application never has to be rewritten around a new code or a proprietary machine.

Main Findings

• Schedule-derived estimates reconcile with established independent models. Across workloads spanning application-architecture studies, qLDPC surgery, and detector-error-model composition, estimates derived from compiled schedules agree with established independent resource models. The paper does not report specific numerical agreement figures in the provided content.

• Compiler-visible structure exposes hidden cost drivers. Costs that aggregate analytical formulas obscure — the synthesis and scheduling decisions behind a resource count — become visible and attributable once the program is materialized through the profiles.

• QEC artifacts survive into simulation intact. Detector models and related QEC artifacts flow from compilation into simulation without being reconstructed by hand; record identities are preserved through inlining and lowering.

• Gadget and detector semantics compose exactly. Wiring gadget EDEMs through matching code presentations reproduces the detector error model of the composite circuit, and detector contracts are independently selectable objects separate from gadget bodies.

• Retargeting works without touching the application. One unchanged P0 program was compiled through four QEC routes spanning two codes and two providers, demonstrating cross-target comparison with the workload held fixed.

• External code families can be imported as verified typed data. Externally supplied surgery gadgets compile and verify against their logical actions, though the paper states they cannot yet participate in EDEM composition because they lack complete boundary detector contracts.

• A full compilation pipeline is demonstrated. The paper reports a complete path from application-level logical program through to physical schedules and control plans, with a device-construction example binding a logical compute region to the Pinnacle GB30 high-rate qLDPC architecture and compiling through P2.

• Later estimates are narrower, not automatically better. The authors explicitly caution that a P3 or P4 report has a more concrete scope but is still conditional on the supplied physical error rates, operation times, scaling laws, and producer models until those are calibrated or measured.

Methodology in Plain English

The authors treat fault-tolerant compilation as a compiler-engineering problem rather than a collection of scripts. They borrow the standard MLIR approach — dialects define typed operations, types, attributes, and verifiers; passes transform within a level; lowerings translate between levels — and apply it to the fault-tolerance stack. A logical program starts as target-independent intent, then gets placed on a code-independent "virtual machine" describing where logical data can live and how it can move, then gets bound to specific codes and gadgets, then gets mapped onto physical qubits, topology, timing, and noise, and finally gets bound to instruction delivery, syndrome transport, decoding, and feedback. At every boundary the compiler checks the new artifact against the old one.

Around this spine they built an object model where builds are immutable (passes derive new builds rather than mutating existing ones), handles preserve identity across stages, and every report is explicitly tied to the build and parameters it analyzed. Evaluation is organized along those same boundaries: two architecture studies test whether schedule-based analysis reproduces known resource models and reveals their cost drivers; two QEC studies test whether gadget semantics and detector models compose exactly and whether an outside code family can enter as verified typed data; and a final study compiles one unchanged P0 program through four QEC routes across two codes and two providers.

Why This Matters

Impact on research. The framework makes resource estimates auditable: because each number is derived from a specific compiler artifact under stated assumptions, researchers can compare architectures under identical workloads and metric definitions, and attribute a cost difference to a particular design decision instead of to an unrecorded rewrite. It also sets out seven explicit requirements for any cross-target fault-tolerant compiler stack (semantic separation without disconnection, compilation toward execution, validation and reproducibility, scalable representation, open typed contracts, controlled comparison, and estimates that survive refinement).

Real-world applications:

• Comparing QEC code families (surface codes versus high-rate qLDPC codes such as Pinnacle GB30) on a fixed application workload to decide which architecture to build.
• QPU providers describing their own topology, native operations, noise, timing, and control capabilities so customers can evaluate real hardware against alternatives.
• Co-designing decoders and real-time control by exposing detector-production bandwidth, decoder throughput, queueing, and deadlines as compile-time quantities.
• Producing reproducible, provenance-carrying resource estimates for large repeated computations, where feasibility depends on both quantum and classical rates.

Industry relevance. The work comes from NVIDIA and is positioned as a standalone, modular component within the CUDA-Q platform, interoperable with CUDA-Q and other mainstream front-ends (Qiskit, Guppy, and PennyLane are cited as related program representations). It targets the practical gap between vendor-specific fault-tolerant toolchains and application-level quantum SDKs, and it is written as a working draft for a 2026 venue.

Future Directions

• Complete boundary detector contracts for external gadgets. The externally supplied surgery gadgets verify against their logical actions but cannot yet join EDEM composition; closing that gap would let third-party code families participate fully in detector-error-model analysis.
• Calibrating assumptions into evidence. Physical error rates, operation times, scaling laws, and factory/producer models remain assumptions until measured; the P3/P4 sampling and run-measurement path (SampleResult, RunResult, TwinEstimate) is the mechanism proposed for turning them into evidence with confidence bounds.
• Real-time control and decoding co-design. P4 work on instruction delivery, syndrome transport, decoding, and feedback is described as the newest boundary, with decoder throughput and latency treated as system constraints when later operations depend on decoder output.
• Broader retargeting and cross-architecture studies. The four-route, two-code, two-provider experiment is a template; extending code, execution model, decoder, and provider extensions is framed as the intended growth path for the framework.

Target Audience

Compiler engineers building quantum intermediate representations and lowering pipelines; QEC researchers who want to test new codes, gadgets, and detector models on realistic application workloads without building a full compiler; quantum architecture and resource-estimation researchers who need controlled cross-architecture comparison; and QPU providers or tool developers who need stable, typed integration points for proprietary codes, decoders, machines, and control systems. Readers seeking quantitative benchmark tables will not find them in the material summarized here — the paper's reported evidence is qualitative agreement with established models plus the structure of the compilation pipeline.

Authors’ abstract

Realizing fault-tolerant quantum computing requires mapping logical programs to heterogeneous quantum error correction (QEC) codes and diverse fault-tolerant execution models, scheduling physical resources, and coupling to real-time classical control and feedback. Specialized tools exist for each step but rely on manual composition and translation that discard assumptions and provenance, separating resource estimates from the compiler artifacts they describe, and making it difficult to validate correctness, compare architectures, or attribute costs to specific design choices. We present CUDA-Q Logical, an extensible compiler infrastructure for retargetable fault-tolerant compilation, analysis, and execution. Interoperable with CUDA-Q and other mainstream front-ends, CUDA-Q Logical progressively lowers target-independent logical programs through a constrained logical virtual machine, QEC microcode, physical gate schedules, and real-time control plans, with each layer preserving semantics and provenance, while verifying composition and resource constraints. By deriving every resource estimate directly from compiler artifacts, the framework unifies compilation and resource analysis, enabling successively refined estimates and principled cross-architecture comparison while permitting QEC codes, execution models, decoders, and hardware architectures to be introduced as modular extensions. Across workloads ranging from application-architecture studies to qLDPC surgery and detector-error-model composition, we show that schedule-derived estimates reconcile with established independent models. Crucially, this compiler-visible structure exposes cost drivers hidden by aggregate analytical formulas, carries QEC artifacts intact into simulation, and demonstrates a complete compilation pipeline for fault-tolerant quantum computing.