QuPort: Topology-, Port-, and Congestion-Aware Compilation for Modular Multi-QPU Quantum Systems

This paper introduces QuPort, a compilation framework for modular multi-QPU systems that employs a three-level model and the TPCCAP algorithm to jointly optimize qubit mapping, port allocation, and interconnect congestion, thereby minimizing cross-QPU traffic and communication bottlenecks.

The Gist

Imagine you are trying to organize a massive, complex party where the guests are "quantum bits" (qubits) and the rooms they hang out in are small, separate quantum computers called QPUs.

In the old days, all the guests were in one giant ballroom. The job of the "party planner" (the compiler) was just to make sure guests who needed to talk to each other were standing next to each other. If they weren't, the planner would have to shuffle people around (a process called "routing") until they could chat.

But now, we are building modular quantum computers. Instead of one giant ballroom, we have a building with many small, separate rooms (QPUs). Some rooms are connected by hallways, but the hallways are narrow and expensive to use.

This paper introduces a new party planner named QuPort. Here is how it works, using simple analogies:

1. The Three Maps

To plan the party, QuPort looks at three different maps at the same time:

• The Guest List (Logical Graph): Who needs to talk to whom, and how much? (Some guests are best friends and need to talk constantly; others just say "hi" once).
• The Room Layout (Physical Map): Inside each small room, which chairs are next to each other?
• The Building Blueprint (Interconnect Graph): How are the rooms connected? Are there direct hallways, or do you have to walk through three other rooms to get to the next one?

2. The Big Problem: The "Doorway" Bottleneck

If you put two best friends in different rooms, they have to shout across the hallway. But there are two big problems:

1. Too much shouting: If too many pairs of friends are in different rooms, the hallways get clogged.
2. Too few doors: Each room only has a few "communication doors" (ports). If you put 100 guests in a room but only 5 of them need to shout to the outside, you can only let 5 out at a time. The rest get stuck.

3. The Solution: The TPCCAP Strategy

QuPort uses a special strategy called TPCCAP to decide who goes in which room. It tries to balance three things:

• Distance: It tries to keep best friends in the same room. If they must be in different rooms, it puts them in rooms that are close neighbors (short hallways).
• Door Pressure: It makes sure no room is forced to use more "doors" than it actually has. It won't put 10 shouting guests in a room with only 5 doors.
• Hallway Traffic: It spreads the shouting out so that no single hallway gets jammed with too much traffic.

4. How QuPort Plans the Party (The Algorithms)

QuPort doesn't just guess; it uses a few clever tricks to find the best arrangement:

• Heavy-Edge Clustering: It looks at the strongest friendships first and locks those pairs together in the same room before worrying about the rest.
• Balanced Greedy: It fills the rooms one guest at a time, always picking the room that makes the most sense for that guest without making the room too crowded.
• Simulated Annealing: This is like a "second guess" phase. After the initial plan, it tries random small changes (like swapping two guests) to see if the party runs smoother. If a change makes things better, it keeps it. If it makes things worse, it might still keep it for a moment to avoid getting stuck in a "good enough" but not "perfect" plan.

5. The "Remote Event" List

Once the guests are assigned to rooms, QuPort creates a special instruction list.

• Local Instructions: "Guest A and Guest B are in Room 1. They can talk normally."
• Remote Events: "Guest A is in Room 1 and Guest B is in Room 2. They need to talk."

QuPort does not figure out how they talk across the hall (whether they use lasers, wires, or magic). It simply marks the spot where that conversation needs to happen and tells the hardware engineers, "You need to build a protocol here to handle this specific shout."

6. The Schedule

Finally, QuPort estimates how long the party will take. It counts how many "shouts" can happen at the same time without clogging the hallways or running out of doors. It gives a rough estimate of the total time (makespan) based on these abstract rules.

What QuPort Is NOT

The paper is very clear about what this tool is not:

• It is not a physical machine.
• It does not know the specific physics of your quantum computer (like how long a battery lasts or how much error a laser makes).
• It doesn't actually perform the "shouting" across rooms.

In summary: QuPort is a smart traffic controller for a modular quantum computer. It figures out the best way to split up the work among different small computers so that they don't get stuck waiting for each other, while making sure they don't try to use more doors or hallways than actually exist. It prepares the instructions so that the actual hardware engineers can later figure out the best way to build the "shouting" technology.

Technical Summary

Technical Summary: QuPort - Topology-, Port-, and Congestion-Aware Compilation for Modular Multi-QPU Quantum Systems

1. Problem Statement

Modular quantum architectures, which connect multiple Quantum Processing Units (QPUs) via interconnects, present a unique compilation challenge distinct from monolithic devices. In single-device compilation, the primary constraint is the local coupling map; non-local interactions are resolved via SWAP insertion. However, in modular systems, interactions between qubits on different QPUs are not merely "longer" local gates but depend on scarce communication resources: interconnect topology, communication ports, and link capacity.

Existing compilers often treat inter-QPU communication as a secondary concern or hide it within standard routing. This approach is insufficient for modular systems because a mapping acceptable on a single coupling graph may fail in a modular setting if it:

1. Creates excessive cross-QPU traffic.
2. Concentrates traffic on a small number of interconnect links (causing congestion).
3. Assigns too many boundary qubits (qubits interacting with other QPUs) to a QPU with insufficient communication ports.

The paper addresses the need for a compiler framework that explicitly reasons about local device connectivity and cross-QPU communication simultaneously, prior to the selection of a specific physical remote-gate protocol (e.g., photonic links, entanglement generation).

2. Methodology

QuPort is a Python-based compilation framework built on top of Qiskit. It introduces a three-level system model and a specific partitioning algorithm to optimize resource usage.

2.1 System Model

The framework abstracts the compilation problem into three distinct graphs:

1. Logical Interaction Graph ($G_L$): A weighted undirected graph where nodes are logical qubits and edge weights represent the frequency or temporal importance of two-qubit interactions.
2. Physical Coupling Map: A directed graph representing the connectivity within each individual QPU (e.g., grid, ring, clique).
3. QPU Interconnect Graph ($G_Q$): An undirected graph representing the topology connecting the QPUs (e.g., mesh, ring, Clos, fat-tree). This graph is used to calculate hop distances and link loads.

The system assumes $N$ QPUs, each with $C$ compute qubits and $P$ communication qubits. A logical-to-QPU partition ($\pi$) must respect the capacity constraint ($C+P$) per QPU.

2.2 The TPCCAP Objective

The core of QuPort is the TPCCAP (Topology-, Port-, and Congestion-Aware Partitioning) objective function, $J(\pi)$, which minimizes a weighted sum of three cost terms:

1. Weighted Cut Distance: $\sum w_{ij} \cdot d(\pi(i), \pi(j))$. This penalizes interactions between qubits assigned to QPUs that are far apart in the interconnect graph, where $d$ is the shortest-path distance.
2. Communication-Port Overflow: $\sum \max(0, b_q - P)^2$. This penalizes QPUs where the number of boundary qubits ($b_q$) exceeds the available communication ports ($P$).
3. Routed Link-Load Congestion: $\sum L_e^2$. This penalizes the squared load on interconnect edges ($e$), discouraging traffic concentration on specific links.

2.3 Algorithms

QuPort implements a pipeline of heuristics to solve the partitioning and layout problem:

• Heavy-Edge Clustering: Merges high-weight logical pairs into clusters as long as the cluster size does not exceed QPU capacity.
• Balanced Greedy Partitioning: Assigns logical qubits one by one based on weighted degree, balancing the load across QPUs while rewarding placement near already-assigned neighbors.
• TPCCAP Local Search: Refines the initial partition by moving qubits to reduce the $J(\pi)$ objective while maintaining capacity constraints.
• TPCCAP-SA (Simulated Annealing): Adds a stochastic refinement stage to escape local minima by occasionally accepting moves that increase the objective function.
• Communication-Port-Aware Layout: After partitioning, selects specific logical qubits to occupy communication ports based on their "external score" (total weight of interactions with other QPUs).
• Distributed Program Construction: In distributed mode, the framework extracts cross-QPU two-qubit operations as explicit remote events and inserts synchronization barriers, while routing local operations only within their respective QPU coupling maps.

2.4 Scheduling and Cost Estimation

QuPort includes a topology-aware estimator that approximates the execution time (makespan) using abstract cost parameters:

• Local Costs: Gate execution times for single-qubit, two-qubit, and SWAP operations.
• Remote Costs: A model combining entanglement generation cost ($\tau_E$), classical round-trip cost ($\tau_C$), and remote overhead ($\tau_R$).
• Scheduling: Remote operations are packed into "rounds" based on available communication ports and link capacities, respecting the interconnect topology.

3. Key Contributions

1. Explicit Three-Level Abstraction: The paper proposes a compiler-level abstraction that separates the logical interaction graph, the physical coupling map, and the QPU interconnect graph. This separation allows for the optimization of modular-specific costs (distance, ports, congestion) that are invisible to standard monolithic compilers.
2. The TPCCAP Objective: A novel objective function that jointly optimizes for QPU distance, communication port scarcity, and link congestion, rather than treating these as separate or secondary concerns.
3. Distributed Compilation Path: A mechanism that produces an intermediate representation where local circuits and remote events are explicitly separated. This enables the compiler to generate modular-aware schedules without committing to a specific hardware implementation of remote gates.
4. Open-Source Framework: The implementation of these algorithms in Python/Qiskit, providing a reproducible environment for studying modular compilation strategies.

4. Results and Validation

The paper focuses on the algorithmic structure and correctness of the framework rather than reporting calibrated hardware runtime results.

• Correctness: The authors provide formal proofs (Propositions 1 and 2) demonstrating that their partitioning algorithms (Heavy-edge, Greedy, TPCCAP, TPCCAP-SA) strictly satisfy per-QPU capacity constraints and that their multi-path routing routines conserve traffic weight.
• Validation: The framework enforces validation checks on partition inputs, layout construction, and traffic matrices to ensure finite, non-negative, and symmetric values.
• Scope of Results: The paper does not claim to outperform specific hardware protocols or provide calibrated error rates. Instead, it demonstrates that the framework successfully generates valid partitions and distributed programs that respect the defined abstract constraints.

5. Significance and Claims

The paper positions QuPort as a compiler-level abstraction rather than a hardware implementation. Its significance lies in:

• Decoupling Compilation from Hardware Protocols: By separating the logical partitioning and remote-event extraction from the physical realization of remote gates, QuPort allows researchers to study the algorithmic structure of modular compilation before a specific interconnect technology (e.g., photonic vs. microwave) is finalized.
• Resource-Aware Mapping: It highlights that modular compilation requires a shift from minimizing SWAPs to minimizing "cut distance," "port overflow," and "link congestion."
• Modesty in Claims: The authors explicitly state that the framework does not claim calibrated hardware runtime, nor does it implement a physical remote-gate protocol. The "remote events" are intermediate representations indicating where a backend must supply a protocol. The scheduling estimator is described as a "layer-based greedy model," not a verified network-control scheduler.

In summary, QuPort provides a structured, heuristic-driven approach to the complex resource allocation problem inherent in modular quantum computing, offering a tool to explore the trade-offs between topology, port availability, and congestion in a platform-agnostic manner.