QASMTrans: Quantum Circuit Transpiler Framework

• QASMTrans is a quantum circuit transpiler framework that converts hardware-agnostic OpenQASM into device-specific circuits using a multi-stage pipeline.
• It employs classical compiler techniques, qudit-adapted methods, and transformer-based models to optimize gate decomposition, mapping, and scheduling.
• It integrates into quantum software stacks by enabling efficient qubit mapping, routing, and simulation preprocessing for various hardware platforms.

QASMTrans is a family of quantum circuit transpiler frameworks and algorithms designed to map high-level, hardware-agnostic quantum assembly representations (notably OpenQASM) to physically realizable, backend-specific, or even alternative formal (e.g., qudit-based or binary-encoded) quantum circuits. Under the umbrella of this term, multiple architectures exist, ranging from hand-coded compiler pipelines in C++/TypeScript to transformers-based deep learning models, each targeting efficient device mapping, basis decomposition, and fidelity preservation across a wide array of quantum hardware platforms, including NISQ, FTQC, and emerging qudit processors (Hua et al., 2023, Banfi et al., 10 Dec 2025, Drozhzhin et al., 2024, Li, 21 Jan 2026).

1. Architectural Variants and Transpilation Pipeline

QASMTrans frameworks generally instantiate the transpilation process as a pipeline organized into discrete passes, handling the transformation of logical circuits into device-executable forms. The canonical stages are:

1. Parsing & Intermediate Representation: Leveraging robust front-end parsers, such as Lexertk for C++ or hand-built lexers in TypeScript, QASMTrans parses OpenQASM (.qasm) files into a custom intermediate Gate IR or AST. This abstraction records each gate’s name, operand qubits, parameters, and—in some implementations—full matrix representations.
2. Device and Basis Configuration: Via external JSON “device description” files, QASMTrans incorporates specifications of a device’s coupling graph, basis gate set, scheduling constraints, and—optionally—noise properties and readout fidelities.
3. Gate Decomposition: All non-native gates, including multi-control gates, are decomposed into 1- and 2-qubit primitives compatible with the target basis (e.g., {U, CX} for IBMQ). This process may use pattern-based expansion rules, lookup tables, or, in ML-based versions, data-driven mappings.
4. Logical-Physical Qubit Mapping & Routing: Employing algorithms such as Sabre, QASMTrans heuristically assigns logical qubits to physical qubits to minimize total SWAP overhead, then routes two-qubit gates to satisfy the device’s connectivity using SWAP insertion and front-layer update mechanics.
5. Scheduling: For latency-sensitive targets, QASMTrans orders the resulting gate list subject to gate durations and resource conflicts, aiming to minimize makespan and preserve data dependencies.
6. Code Emission/Serialization: The mapped and lowered circuit is emitted in OpenQASM, eQASM binaries, qudit-native JSON, or another IR as specified by downstream consumers. Simulation-specific features (e.g., routing constraint restricting the active device subgraph) may be optionally enforced (Hua et al., 2023, Drozhzhin et al., 2024, Fu et al., 2018, Edwards, 29 Jun 2025, Li, 21 Jan 2026).

2. Algorithmic Strategies and Formal Cost Functions

QASMTrans implements a variety of algorithms—analytically and empirically optimized—to ensure fast, scalable transpilation without fidelity loss:

• Sabre Front-Layer Routing: Maintains a working set of gates with all dependencies satisfied (front-layer), scoring candidate SWAPs within a restricted radius to minimize mapping cost. The per-step complexity reduces from $O(G)$ (total gates) to $O(n)$ (qubit count) (Hua et al., 2023).
• Heuristic Qubit Mapping: The cost function for mapping logical to physical qubits is formalized as

$$C_\text{map}(\ell) = \sum_{(i,j)\in E_\text{logical}} \text{dist}_G(\ell(i),\ell(j)),$$

where $E_\text{logical}$ is the set of two-qubit gates and $\text{dist}_G$ queries the physical connectivity graph (Li, 21 Jan 2026).

• SWAP Insertion and Routing: For each two-qubit gate on unconnected qubits, QASMTrans inserts minimal SWAP sequences along the shortest hardware path, updating logical–physical mapping in real time (Li, 21 Jan 2026).
• Resource-Aware Scheduling: Each instruction is assigned a start time $t_i$ satisfying dependency constraints and optimizing

$$\text{minimize}\;\max_i(t_i+\tau_i), \qquad t_j \geq t_i + \tau_i$$

for all dependency edges $i\to j$ (Li, 21 Jan 2026).

• Gate Count and Depth Metrics: Post-transpilation, QASMTrans reports gate-type counts, circuit depth, gate density, entanglement variance, and measurement density. These are central for hardware benchmarking and simulator coupling (Hua et al., 2023, Li, 21 Jan 2026).

3. Implementation Modalities: Traditional, Qudit, and Transformers-Based

Three primary implementation paradigms are substantiated in the QASMTrans literature:

A. Classical C++/TypeScript Pipelines

Reference implementations use minimal dependencies (e.g., header-only JSON/Lexertk parsers), contiguous array-based data structures, and arena allocators for IRs. Platform portability is demonstrated across x86, ARMv8, and HPC clusters. Optional multithreading is incorporated for parsing and statistics collection (Hua et al., 2023, Edwards, 29 Jun 2025). Performance benchmarks show 10–369× speedup over Qiskit, with circuit quality (CX count, depth) within 5% of competitive toolchains (Hua et al., 2023).

B. Qubit-to-Qudit Transpilation

For hardware where $d>2$ (qutrit/ququart), QASMTrans implements a pipeline to map qubit circuits into qudit-native gate sets. Logical qubits are assigned to qudit subspaces (e.g., $n$th qubit $\rightarrow$ $(Q_n,I_n)$), and standard gates are replaced by higher-level qudit operations with explicit resource analysis:

• MCZ gates decompose with minimal ancilla and circuit depth in the qutrit regime, reducing two-qudit gate count significantly vs. traditional qubit implementations (Drozhzhin et al., 2024).

C. Transformers-Based Models

A neural QASMTrans architecture formulates transpilation as a sequence translation task, using a 6-layer encoder–decoder transformer ($d_\text{model}=768$, 8 heads/layer, max sequence=768 tokens). The tokenizer discretizes gates and rotation angles. Training is supervised via paired source/target QASM data (IBM$\to$IonQ), with cross-entropy and fidelity objectives. Achieved unitary fidelity exceeds $99.98\%$, validating suitability up to 5-qubit circuits (Banfi et al., 10 Dec 2025).

4. Integration in Quantum Software and Hardware Stacks

QASMTrans serves as the compilation/transpilation layer in multiple quantum software ecosystems:

• NWQWorkflow Stack: QASMTrans forms the core NISQ compiler, ingesting logical or NWQASM-formatted circuits and outputting device-compliant QASM2, feeding into NWQSim (simulation) or NWQControl (pulse scheduling). It is complementary to NWQEC, which handles FTQC regimes (Li, 21 Jan 2026).
• Simulation Preprocessors: By generating hardware-routed, device-prioritized QASM, QASMTrans enhances distributed simulation efficiency, reducing communication overhead by up to $10\times$ in SV-Sim simulation (Hua et al., 2023).
• Cloud and Embedded Deployment: As a header-only, dependency-light C++ library, QASMTrans is suitable for both embedded hardware control planes and cloud orchestration layers (Hua et al., 2023).
• Transformer-based Workflows: The model can be deployed as a Qiskit/Cirq compiler pass or as a REST/gRPC microservice operating on quantum program workloads in cluster or cloud settings (Banfi et al., 10 Dec 2025).

5. Theoretical Complexity, Empirical Performance, and Scalability

QASMTrans’s time and space complexity reflects both algorithmic efficiency and code-level optimization. For $n$ qubits and $m$ gates:

• Parsing and IR construction: $O(L)$ in token length $L$.
• DAG/coupling graph construction: $O(m + n^2)$.
• Mapping and Routing: Empirically $O(mk)$ with $k \lesssim n$ due to Sabre optimization and SWAP candidate pruning.
• Gate Decomposition: $O(m')$ post-routing, with multi-qubit gates $O(10m)$ in worst-case output expansion (Hua et al., 2023).

Empirical results (Perlmutter, Summit, Jetson) confirm sub-100s runtimes for million-gate circuits, and performance within $2\times$ across ARM, Intel, and HPC hardware (Hua et al., 2023). Fidelity on hardware is within 1% of classical Qiskit pipelines.

For transformer-based methods, context length ($\leq768$ tokens) is the bottleneck under Solovay-Kitaev expansion, but complexity scales polynomially in token count and qubit number:

$O\Bigl(nf(n)\log^c(t/\varepsilon)\Bigr)$

with improvements possible via sparse-attention models (Banfi et al., 10 Dec 2025).

6. Interoperability, Language Bridging, and Categorical Best Practices

QASMTrans, as considered in both practical implementations and formal studies (Wesley, 2024), embraces the categorical specification of transpilers:

• Each reader–writer–transformer stage must form idempotent, invertible mappings with semantic preservation.
• Correctness and round-trip stability are enforced, e.g., OpenQASM $\leftrightarrow$ Quipper with precise ancilla management and no semantically disallowed decompositions.
• Best practices include pipeline modularity, explicit rotation ADTs, shadow memory for qubit–cbit transitions, and full documentation of gate-mapping tables.

This philosophy ensures extensibility (e.g., for alternative IRs like QIR/Quil or QASM3.0), robustness under repeated recomposition, and interoperability across quantum software tooling (Wesley, 2024, Edwards, 29 Jun 2025).

7. Limitations and Prospective Enhancements

QASMTrans frameworks exhibit several known limits and open development targets:

• Incomplete support for dynamic circuits (mid-circuit measurement, reset), although future versions are targeting OpenQASM 3.0 (Hua et al., 2023).
• Transformer model context-window limitations, suggesting work on linear-time attention or chunked/hierarchical representations (Banfi et al., 10 Dec 2025).
• Partial coverage of the full Q# language (in the Q#→QASM3.0 branch) due to missing features such as imports, higher-order functions, or rich type inference (Edwards, 29 Jun 2025).
• Qudit transpilation presently applies to circuits with natural qudit hardware analogues; broader gate sets and multi-qudit operations may require further pattern generalization (Drozhzhin et al., 2024).

In all implementations, ongoing improvements involve additional optimization passes (cancellation, commutation reordering), parallel mapping, and plugin architectures for backend extensibility (Hua et al., 2023, Edwards, 29 Jun 2025).

---

References:

• "QASMTrans: A QASM based Quantum Transpiler Framework for NISQ Devices" (Hua et al., 2023)
• "Transpiling quantum circuits by a transformers-based algorithm" (Banfi et al., 10 Dec 2025)
• "Transpiling quantum assembly language circuits to a qudit form" (Drozhzhin et al., 2024)
• "NWQWorkflow: The Northwest Quantum Workflow" (Li, 21 Jan 2026)
• "Compiling a Q# Subset to QASM 3.0 in TypeScript via a JSON Based IR" (Edwards, 29 Jun 2025)
• "LinguaQuanta: Towards a Quantum Transpiler Between OpenQASM and Quipper (Extended)" (Wesley, 2024)
• "eQASM: An Executable Quantum Instruction Set Architecture" (Fu et al., 2018)