Marol: DSL for Qubit Mapping

• Marol is a domain-specific language designed for encoding qubit mapping and routing problems via a unified device state machine abstraction.
• It abstracts diverse quantum architectures, such as superconducting and trapped ion devices, into a common model to automatically generate QMR compilers.
• Its concise syntax and formal semantics enable competitive performance while reducing manual engineering for scalable quantum compilation.

Marol is a domain-specific language (DSL) designed for succinctly specifying qubit mapping and routing (QMR) problems in quantum compilation. It enables automatic generation of QMR compilers for arbitrary quantum architectures by abstracting architectural details into a unified device state machine model. Marol and its associated parametric solver address the diversity and complexity of quantum hardware—such as superconducting devices, trapped ions, surface-code processors, and reconfigurable atom arrays—by isolating their common structural patterns. By expressing architecture-specific rules compactly within Marol, any QMR problem can be encoded and then compiled using a problem-agnostic, generic solver, facilitating rapid deployment of competitive compilation pipelines across evolving hardware platforms (Molavi et al., 14 Aug 2025).

1. Motivation and Context

Qubit mapping and routing is a critical step in quantum compilation, involving the transformation of an architecture-independent quantum circuit into a sequence of hardware-executable steps while respecting real-world device constraints. Each quantum hardware family offers unique connectivity, native gate sets, and error models, prompting the traditional approach of hand-crafting a dedicated compiler or QMR pass for each architecture variant. Marol emerges as a response to both the inefficiency of repeated manual design and the recognition that a variety of architectures can be reduced to a common abstraction: the device state machine. This approach provides a robust foundation for compiler generation as quantum technologies advance and diversify (Molavi et al., 14 Aug 2025).

2. Device State Machine Abstraction

The core abstraction underlying Marol is the device state machine. A device state is formally specified as a pair $(\mathit{map}, \mathit{routes})$, where:

• $\mathit{map}$ is a partial injective mapping from circuit qubits to device locations.
• $\mathit{routes}$ is a partial injective assignment from circuit instructions to device instructions.

A QMR solution is modeled as a sequence of such states

$$s_1 \xrightarrow{c_1} s_2 \xrightarrow{c_2} \dots \xrightarrow{c_{k-1}} s_k$$

where each state is physically valid, respects dependency constraints, collectively covers the entire gate set, and minimizes the aggregate transition cost $\sum_i c_i$. The device state machine architecture is determined by two principal components:

• State Realizability Predicate ($\Phi$): Determines whether a given state can be physically realized under the device’s constraints.
• Transition Relation ($\to_c$): Defines how the qubit map can evolve between time steps and the associated transition cost.

Distinct QMR problems, such as NISQ mapping-and-routing (nisqmr) or surface-code mapping-and-routing (scmr), instantiate this abstraction with different realizability and transition definitions, but share the fundamental structure formalized by Marol (Molavi et al., 14 Aug 2025).

3. Structure and Semantics of Marol

Marol programs comprise mandatory and optional blocks that collectively define the architecture-specific QMR semantics:

• RouteInfo (required): Specifies valid gate realizations in a state using the realize_gate function.
• TransitionInfo (required): Specifies allowable transitions between states through get_transitions, apply, and cost.
• ArchInfo (optional): Annotates the device graph with metadata such as edge reliabilities or hardware-specific labels.
• StateInfo (optional): Enables direct specification of state costs when more natural than transition costs.

The Marol language adopts a concise functional expression syntax. Built-in types include basic types (Int, Float, Bool, List[τ]) and domain types (Loc, QubitMap, InstrT, StateT, ArchT). Core operations span:

• List processing (map, fold, concat, push)
• Graph traversal and analysis ([edges](https://www.emergentmind.com/topics/tool-relationships-edges), edges_between, all_paths, steiner_trees)
• Utility functions relevant to QMR (e.g., value_swap, horizontal_neighbors)

The semantics of a Marol program $P$ with an architecture graph $A$ yield a set $\llbracket P \rrbracket$ of tuples $\mathit{map}$0, where $\mathit{map}$1 is a state-sequence solution for circuit $\mathit{map}$2 respecting $\mathit{map}$3’s realizability and transition logic. Key constructive inference rules include:

• RealEmpty: States with empty routes are realizable if the qubit map is valid.
• RealIns: States extended with a realizable gate (as determined by realize) remain realizable.
• Transition: Valid transitions update the map and accrue the appropriate cost, as dictated by get and apply.

Programs are written constructively to enumerate algorithmically all valid choices, rather than merely specifying constraints declaratively (Molavi et al., 14 Aug 2025).

4. Example: NISQ Mapping and Routing in Marol

A canonical demonstration of Marol’s succinctness is the nisqmr problem, which specifies the gate mapping and swap transitions for NISQ-era quantum devices. The entire specification is approximately 12 lines:

$\mathit{map}$5

This program specifies that CX gates can be routed only along device adjacency edges, and only swaps on such edges (plus the identity) are allowed as transitions, each nontrivial swap incurring unit cost. This demonstrates Marol’s capacity to concisely capture full QMR problem formulations that traditionally required bespoke compiler pipelines (Molavi et al., 14 Aug 2025).

5. Parametric Solver and Compiler Generation

The generic parametric solver, termed MaxState, is automatically instantiated from the Marol program for a given architecture, producing a tailored QMR compiler $\mathit{map}$4. MaxState operates by iteratively constructing device state sequences, where each step:

1. Selects an initial qubit mapping.
2. Identifies the front layer of dependency-ready gates.
3. Maximally routes as many gates in parallel as possible in the current state.
4. Applies a transition to a new mapping according to the architecture’s rules.
5. Repeats until all gates have been routed.

This “maximal-state construction” approach is approximate, suitable for scalable compilation, as exact QMR is generally NP-hard. The solver leverages Marol’s programmatic enumeration of realizable gates and allowable transitions to instantiate its logic for arbitrary architectures. Key to this automation is that Marol provides explicit instructions for realization, transition generation, and cost evaluation—the precise hooks required for solver instantiation (Molavi et al., 14 Aug 2025).

6. Formal Properties: Monotonicity and Non-Interference

The correctness and efficiency of the maximal-state construction depend on two formal properties of realizability predicates:

• Monotonicity: Any sub-state of a realizable state is itself realizable. This ensures constructive assembly of maximal states is sound.
• Non-interference: For states sharing the same mapping and with disjoint routed gates, their union is also realizable. Uniqueness of maximal states (for routed gates) follows under this property.

The study reports that all practical quantum processing unit (QPU) families assessed exhibit monotonicity, while some, notably nisqmr, also exhibit non-interference. In non-non-interfering cases (e.g., scmr), interactions among gate routing paths necessitate additional search. MaxState uses simulated annealing to search over instruction orderings and initial mappings, utilizing an “incremental isomorphism” heuristic to warm-start the initial mapping by embedding prefixes of the circuit’s interaction graph into the device graph (Molavi et al., 14 Aug 2025).

7. Evaluation and Significance

Extensive case studies spanning seven representative QMR problems demonstrate Marol’s generality and the competitiveness of generated compilers:

QMR Problem	Marol Lines	Notable Experimental Results
nisqmr	12	Competitive with qiskit/SABRE; matches SAT-optimal qsynth2 in 66/74 cases, solves more when SAT times out.
nisq-ve	30	Roughly on par with qiskit; quality varies by swap count vs edge reliability.
tiqmr	51	Reduces cost by ≥50% relative to shaper and solves more benchmarks.
raa	116	Outperforms enola on 97% of benchmarks (median 75% improvement).
scmr	40	Outperforms dascot on 57% of cases; dascot wins 35%.
ilq	44	Better on 76% of circuits where both terminate.
mqlss	56	Included in suite, details as per main text.

Ablation results indicate initial-map search is beneficial in nearly all cases (substantially for NISQ-like architectures), while maximal-state ordering is critical in interference-heavy settings such as scmr. This supports the conclusion that Marol, coupled with the generic solver, provides a practical, systematic approach to compiler generation for future quantum devices, eliminating much of the historical manual engineering without sacrificing runtime or solution quality (Molavi et al., 14 Aug 2025).