{"id":"bb8c8c54-9319-4fca-b343-d2b1cf8adb9c","arxiv_id":"1908.04226","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A timing- and resource-aware quantum-circuit mapper reduces circuit latency overhead by up to 47.3% and operation overhead by up to 28.6% compared with a baseline mapper on the Surface-17 processor.","lead":"This paper presents Qmap, a compiler that maps quantum circuits onto a 17-qubit superconducting chip while respecting gate durations and shared-control-electronics constraints to shorten execution time. It reports up to 47% lower latency overhead than a baseline operation-count-minimizing mapper across 56 benchmarks.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"MOVE operations require a |0> destination (Sec. II.A), but Sections III-IV never enforce or track this precondition, so the many MOVEs in Table IV may make the compared circuits invalid.","rationale":"The reader's weakest assumption concerns the undisclosed classical-control configuration tables (Tg1, Tgm, Tg2f, Tg2d). That is a real reproducibility and validity concern: if the tables omit real restrictions, the scheduled circuits may not be executable. My concern is adjacent but distinct: even if the configuration tables are perfectly accurate, the paper's own stated MOVE precondition (destination in |0>) is not represented in the resource-constrained scheduler or in the movement-set selection. The machine state S has no notion of quantum state or ancilla occupancy, and the routing procedure does not describe how it restricts MOVE targets to physical qubits that are guaranteed to be |0>. Since Table IV shows pervasive MOVE usage, this is not a marginal edge case; it directly affects the executable correctness of the outputs being compared. This is an omitted invariant/proof rather than a demonstrated bug, so the appropriate disposition remains conditional: the authors should clarify or prove the MOVE handling, ideally with a simulation check, and disclose the configuration tables. I therefore keep the reader's CONDITIONAL verdict unchanged. My agreement is partial because the reader identified the hardware-model tables as the weakest point, while I see the unmodeled |0>-state precondition for MOVE as at least as load-bearing for the central claim.","tokens_in":20924,"tokens_out":12817,"duration_ms":142336,"concrete_test":"Reimplement Algorithms 1-3 exactly as described (or obtain the authors' generated eQASM for a small benchmark from Table IV that uses MOVEs, such as cuccaroAdder1b or decod24bdd). Simulate the mapped circuit with a state-vector simulator, initializing all unused physical qubits to |0>. Before each MOVE, check that the destination qubit has zero amplitude on |1>. Also compare the final state against the same circuit with every MOVE replaced by a three-CNOT SWAP, which is unconditionally valid. If any MOVE-target assertion fails, or the MOVE-based output differs from the SWAP-replaced output, the router's MOVE handling is unsound and the evaluation does not support the headline claim.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section II.A states that a MOVE operation is a two-CNOT state transfer and 'requires that the destination qubit where the quantum state needs to be moved to, is in the |0> state.' This precondition is a quantum-state condition, not a classical-control timing restriction. However, the scheduler in Section III.B defines the machine state S only over resources from Tg1, Tgm, Tg2f, and Tg2d: AWGs, feedlines, CZ-concurrency conflicts, and detuned qubits. There is no resource or predicate representing 'this physical qubit is currently |0>.' Algorithm 3 enumerates movement sets over all shortest paths and selects the one that minimally extends latency after ASAP interleaving with previously mapped gates, but that interleaving cannot detect a MOVE whose target is occupied by a non-|0> state, because no such constraint is encoded in the resource model. Table IV reports substantial MOVE counts for both MinPath and Qmap outputs. If the mapper ever emits a MOVE into a data qubit or reuses an ancilla that was occupied by an earlier MOVE, the generated eQASM is not a correct implementation of the input circuit. In that case, the claimed latency improvements up to 47.3% and operation improvements up to 28.6% would be comparisons of invalid scheduled circuits, and the central claim would not hold. The paper does not state an invariant such as 'MOVE destinations are always physical qubits not currently in the virtual-to-physical map and hence initialized to |0>,' nor does it describe how Algorithm 3 maintains such an invariant.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"This paper presents Qmap, a mapping/compilation framework that transforms hardware-agnostic quantum circuits into executable circuits for the 17-qubit Surface-17 superconducting processor, respecting the primitive gate set, gate durations, qubit connectivity, and restrictions from shared classical control electronics (AWGs for single-qubit gates, feedlines for measurement, and frequency-detuning rules for CZ gates). The mapper combines an ILP-based initial placement, a resource-constrained list scheduler (Algorithm 1) that models classical-control limits as resource conflicts, a routing heuristic (Algorithms 2-3) that evaluates multiple shortest-path SWAP/MOVE movement sets and selects the one that minimally extends an ASAP partial schedule, and a global ALAP rescheduling pass. Using 56 benchmarks from RevLib and QLib, the authors compare Qmap with two self-implemented baselines, Trivial and MinPath, and report that Qmap reduces latency overhead by up to 47.3% and gate-count overhead by up to 28.6% relative to MinPath, with average reductions of 22% and 3.0%, at the cost of substantially longer compilation times.","tokens_in":21246,"tokens_out":21617,"duration_ms":209685,"significance":"Assuming the reported results hold, this is a useful contribution to the quantum-compilation literature: it is among the first mappers to fold classical control-electronics restrictions (shared AWGs, shared feedlines, CZ detuning rules) directly into a polynomial-complexity list scheduler, and the latency-aware movement-set selection is a clean, well-motivated improvement over operation-count-only routing. The evaluation uses external benchmark circuits (RevLib and QLib), and no parameters are fitted to the reported outcomes, so the comparison is not circular; the pseudocode for the three algorithms is clear, and the authors are honest about limitations (sub-exponential routing complexity, qubit counts below 20, deferred external comparison). The strength of the central latency-improvement claim, however, is conditional on the two load-bearing points in the major comments: the |0>-precondition for MOVE must be demonstrably enforced, and the randomized self-implemented baseline must be reported with variance and, ideally, anchored by an external comparison.","major_comments":[{"comment":"Section II.A states that a MOVE operation 'requires that the destination qubit where the quantum state needs to be moved to, is in the |0⟩ state.' This precondition is a quantum-state condition, yet none of the three algorithms in Sections III-IV tracks it: the machine state S in Algorithm 1 (Section III.B) covers only the classical resources in Tg1, Tgm, Tg2f, and Tg2d, and the routing state in Algorithms 2-3 (Section IV.C) is the VP-map plus the QODG, with no predicate recording which physical qubits are currently in |0>. The manuscript also states no invariant of the form 'MOVE destinations are chosen only among physical qubits not currently holding a computational state.' Because Table IV reports large MOVE counts for both MinPath and Qmap (e.g., hundreds of MOVEs for several benchmarks), the reader has no basis to conclude that the generated eQASM circuits are equivalent to the input circuits: a MOVE into a data qubit, or into an ancilla that is not guaranteed to be |0>, entangles rather than transfers the state. Since the claimed gate-overhead reductions rely in part on MOVE usage (Sections I and V.E), this is load-bearing for the central claim. I ask the authors to (i) state the precise invariant under which MOVE destinations are known to be |0>, (ii) show where and how Algorithms 2 and 3 enforce it during movement-set enumeration, scheduling, and VP-map updates, and (iii) verify, preferably by instrumenting the compiler or checking the output eQASM for the 56 benchmarks, that every MOVE reported in Table IV satisfies the precondition.","section":"§II.A, §III.B, §IV.C"},{"comment":"Section V.C reports only the minimum of five mapping runs for each benchmark, and Section V.B describes the MinPath router as randomly selecting one movement set along a shortest path; since MinPath is therefore a random baseline, the reported 47.3% (latency) and 28.6% (gates) reductions are comparisons against the best-of-five outcome of a randomized procedure, with no measure of spread, so the reader cannot tell whether these reductions exceed run-to-run variation of the baseline. The paper should report the mean and standard deviation (or all five runs) per benchmark and per mapper, and should state the direction of the bias: because Qmap selects the latency-minimal movement set (Algorithm 3) and is only randomized on ties, reporting the minimum plausibly favors the random MinPath baseline, making the comparison conservative. Furthermore, MinPath is an author-constructed representative rather than a published prior mapper: Section VII concedes that comparison with prior works is future work, so the abstract's phrase 'a prior mapping strategy' overstates the external validity of the comparison. I recommend either benchmarking against at least one published mapper (e.g., a Qiskit/OpenPulse-style flow or the mapper of Ref. [17]) on the same benchmark set, or explicitly presenting MinPath as an ablation baseline and adjusting the claims and abstract accordingly.","section":"§V.B, §V.C"},{"comment":"Sections II.D and III.B define the scheduler's resource model entirely through the configuration tables Tg1, Tgm, Tg2f, and Tg2d, but the paper lists only their sizes (|Tg1|=3, |Tgm|=3, |Tg2f|=48, |Tg2d|=48) and neither includes the tables nor states where the configuration file can be obtained. Because the validity of the scheduled circuits on actual Surface-17 hardware — and hence the correctness of the comparison in Table IV — depends on these tables faithfully capturing the classical-control restrictions (e.g., the detuning rules from Ref. [27]), the omission makes the central modeling contribution unverifiable and the experiments non-reproducible. Please include the full configuration file as supplementary material (or specify all 48-entry tables in the paper) and indicate where the Qmap implementation can be obtained.","section":"§II.D, §III.B"}],"minor_comments":[{"comment":"In Section I, final bullet, 'respectivel' should read 'respectively'.","section":"§I"},{"comment":"Benchmark names are used inconsistently ('gray6 47', 'decod24 b', 'bestein vazirani') relative to the names in Table II ('graycode647', 'decod24bdd', 'bensteinvazirani16'); please use consistent labels throughout.","section":"§V.C"},{"comment":"Section V.D states 'the two-qubit gate number from 5 to 62483', but Table II's largest two-qubit-gate count is 28084 and its largest total gate count is 64283; 62483 matches neither and appears to be a typo.","section":"§V.D"},{"comment":"In the version of the manuscript I reviewed, the table columns run together (e.g., 'alu bdd 288 7 84 38 48 169' and entries such as '0.06365286'), making several rows unreadable; please ensure the published tables have clearly separated columns and unambiguous cell boundaries.","section":"Tables II and IV"},{"comment":"The notation 'O(g√n4√n)' is ambiguous; it should be typeset as O(g·√n·4^√n) (or equivalent) to make the sub-exponential dependence on the qubit count clear.","section":"§IV.C, §V.B"},{"comment":"The statement that MinPath 'can reduce the latency overhead and gate overhead up to 140% and 360%' is ambiguous, since an overhead reduction is itself a percentage; the authors should define whether this is a relative reduction of the overhead values or a percentage-point difference, and give the corresponding formula.","section":"§V.C"}],"recommendation":"major_revision","confidential_remarks":"Overall this reads as a genuine systems contribution from the QuTech group, and the issues I raise are, in my judgment, fixable within a revision rather than fatal: the MOVE precondition needs a documented invariant plus verification, and the evaluation needs variance reporting and a more honest framing of MinPath. I would ask the editor to also weigh the disclosure question: the configuration tables are the empirical heart of the paper, and the authors should be encouraged to make them (and ideally the Qmap code, which is part of the OpenQL compiler) available. One scope point: the MOVE primitive and the target microarchitecture originate in the authors' earlier work (Refs. [27], [42], [38]); the paper should state crisply in the introduction that its distinct contribution is the resource-constrained scheduling formulation and the latency-aware routing, so the novelty is unambiguous."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Qmap is a useful, practical compiler paper. The genuinely new piece is treating classical control restrictions (shared AWGs, feedlines, detuning rules) as resource constraints inside a polynomial list scheduler, and picking movement sets by estimated latency extension rather than operation count. That's a real step past the usual connectivity-only mappers, and the benchmark work is substantial—56 circuits, clear tables, and a sensible comparison to a MinPath baseline that also respects timing. The 47.3% latency reduction headline is plausible given the design, and the routing heuristic's complexity is honestly stated.\n\nThe soft spots are mostly about verification and reporting. First, the MOVE issue: the paper explicitly says a MOVE requires the destination in |0>, but the scheduler and router as described track only classical resources (AWGs, feedlines, detuning) and the VP-map. Nothing in Algorithm 2 or 3 maintains an invariant that a MOVE target is an empty |0> ancilla, and Table IV shows many MOVEs. Either this is an implicit invariant that the authors should state and prove, or the emitted eQASM could be invalid. That's a correctness question, not a style one, and it needs an explicit answer.\n\nSecond, evaluation: best-of-five without variance, a self-implemented baseline, and no external comparison to published mappers make the headline numbers hard to trust as exact, though the direction is credible. The 48-entry constraint tables are not disclosed, and no code is released, so nothing is independently reproducible yet.\n\nNone of this kills the core idea. The resource-constrained scheduling formulation is coherent and the complexity argument is sound. For a reader building a NISQ compiler, this is directly useful. For a reviewer, I'd want the MOVE invariant clarified, the tables released or at least summarized, and variance reported across the five runs. It deserves a serious referee; I'd send it out with those requests.","headline":"Useful and practical NISQ compilation paper with a real contribution, but the MOVE precondition is unaddressed in the writeup and the evaluation is not yet independently reproducible.","tokens_in":21711,"tokens_out":3464,"would_cite":true,"duration_ms":38683,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Qmap maps quantum circuits onto the Surface-17 processor with timing and resource awareness, reducing latency overhead by up to 47.3% and operation overhead by up to 28.6% compared with an operation-count-minimizing mapper.","keywords":["quantum circuit mapping","timing-aware compilation","resource-constrained scheduling","classical control constraints","superconducting qubit processor","qubit routing","Surface-17","NISQ compilation"],"falsifier":"Execute a Qmap-generated schedule for a benchmark such as decod24bdd on an actual Surface-17 device and compare the measured output distribution with the ideal simulated one; a missed control constraint—for example, two same-frequency single-qubit gates issued in the same cycle or a CZ executed while a qubit that should be parked is busy—would produce a characteristic error signature on the affected qubits.","tokens_in":20751,"feed_emoji":"⚛️","tokens_out":7071,"duration_ms":72953,"temperature":0.7,"pith_summary":"This paper argues that mapping a quantum circuit onto a superconducting processor should optimize for execution time under the real hardware constraints, not merely for the number of added gates. It presents Qmap, a mapper that treats shared classical control electronics as resource constraints in a list scheduler, and routes qubits by choosing, among equal-length shortest-path movement sets, the one that least extends the scheduled latency. On 56 benchmarks mapped to the Surface-17 processor, Qmap produces circuits whose latency overhead is up to 47.3% smaller and whose operation overhead is up to 28.6% smaller than those of a prior mapper that minimizes operation count and schedules later, with average reductions of 22% and 3.0%. This matters because NISQ processors have short coherence times, so shorter latency can directly improve the chance that a computation succeeds.","feed_headline":"Timing-aware mapper cuts quantum circuit latency by up to 47%","feed_subtitle":"Routing qubits around shared control electronics beats counting gates on the Surface-17 processor.","key_machinery":"The central mechanism is a resource-constrained list scheduler built on a weighted Quantum Operation Dependency Graph (QODG), in which every gate is a node and every dependency edge carries the duration of the preceding gate. A machine state S records, for each resource in four configuration tables—Tg1 for single-qubit drive sources, Tgm for measurement feedlines, Tg2f for CZ-versus-CZ concurrency, and Tg2d for qubits that must be detuned during a CZ—the occupying operation and the half-open cycle interval [t0, t1) during which it is busy. A gate can be issued at cycle t only if all its resources are free for its full duration; among available gates the scheduler picks the one with the longest remaining path to the sink. The router reuses this scheduler in a look-back mode, generating all shortest-path movement sets, scheduling each against the already mapped prefix, and keeping the set that minimally extends latency.","core_discovery":"The paper's central claim is that classical control restrictions—shared microwave sources for single-qubit gates, shared measurement feedlines, and frequency-detuning exclusions during two-qubit gates—can be encoded as resource occupations in a conventional list scheduler, making timing- and resource-aware mapping practical at polynomial scheduling cost. Qmap schedules gates using real durations (single-qubit rotations and measurement take 1 and 15 cycles, CZ gates take 2 cycles) and its router evaluates all shortest-path movement sets for each non-nearest-neighbor gate, interleaves each candidate set with already mapped gates using the same scheduler, and selects the set that minimally extends total latency. Against a MinPath mapper that randomly picks a minimum-operation movement set and only applies timing and control constraints in a later scheduling pass, Qmap achieves lower or equal latency overhead for 96.4% of benchmarks and lower or equal gate overhead for 87.5%, with the largest latency improvement at 47.3% and the largest gate-count improvement at 28.6%. The paper also shows that using MOVE operations (two CNOTs, requiring a destination qubit in |0⟩) instead of SWAPs (three CNOTs) cuts gate overhead by up to 38.9% and latency by up to 29%.","pith_inferences":["The same resource-table formulation could absorb noise information, such as gate error rates and decoherence decay, as additional costs; if it did, latency-minimizing schedules might also become success-probability-minimizing schedules, which the paper did not test.","The 47.3% latency gap was measured on a 17-qubit processor; as processors grow, shared-control constraints become denser, so timing-aware routing is likely to matter even more relative to operation-count minimization.","A natural stress test is to map the same benchmarks onto other processors with different shared-control arrangements, using only the configuration file, to see whether the resource-table model transfers and how much latency it recovers.","The MOVE-versus-SWAP savings suggest a hardware-design consequence the paper leaves implicit: placing dedicated |0⟩ ancilla storage near frequently interacting qubits could reduce mapping overhead further."],"forward_implications":["Qmap's output circuits carry precise per-cycle timing and already respect classical-control restrictions, so the separate pulse-level scheduling pass that earlier mappers require can be reduced or eliminated.","Optimizing for gate count alone leaves substantial execution time on the table: Qmap matched or beat the operation-count-minimizing mapper on latency for 96.4% of the benchmarks, and the largest gap was 47.3%.","MOVE operations are preferable to SWAPs whenever a qubit known to be in |0⟩ is available, reducing the number of gates by up to 38.9% and latency by up to 29% in the paper's tests.","The scheduler's worst-case complexity is polynomial—O(min(g, n)·(n+|R|)·g) in the number of gates, qubits, and resources—so timing-aware mapping is feasible for large gate counts, even though the routing heuristic still scales sub-exponentially with qubit count.","Because all hardware characteristics are read from a configuration file, the same mapper can be retargeted to other processors by replacing the topology, duration, and resource tables."],"supporting_citations":[{"why":"Supplies the Surface-17 hardware model: topology, frequency groups, detuning restrictions, measurement feedlines, and classical control constraints the mapper must satisfy.","marker":"[27]"},{"why":"Provides the primitive-gate durations used in scheduling, including single-qubit gates at 1 cycle, CZ at 2 cycles, and measurement at 15 cycles.","marker":"[31]"},{"why":"Defines the critical-path list-scheduling technique that the resource-constrained scheduler generalizes.","marker":"[32]"},{"why":"Establishes that resource-constrained scheduling is NP-hard in the strong sense, motivating the paper's polynomial heuristic.","marker":"[33]"},{"why":"Represents prior timing- and crosstalk-aware mapping work that uses exact optimization with exponential complexity, which Qmap is contrasted against.","marker":"[24]"},{"why":"Shows that prior mappers' output circuits require a later pulse-level scheduling pass, the step Qmap aims to make unnecessary.","marker":"[10]"},{"why":"Is the compiler Qmap is embedded in, giving the mapper its circuit input and its executable QASM-like output path.","marker":"[28]"},{"why":"Supplies part of the benchmark circuits used to measure mapping overhead.","marker":"[29]"},{"why":"Supplies the remaining benchmarks in the 56-circuit evaluation.","marker":"[30]"}],"fun_headline_variants":["Qmap: latency-aware routing beats gate-counting on quantum chips","Respecting shared control cuts quantum latency 47% on Surface-17","Quantum mapper: schedule real gate times, not just counts","Shared microwaves? Qmap routes qubits to cut latency up to 47%","Timing and resource-aware mapping slashes quantum circuit overhead"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The load-bearing premise is that the configuration tables for Surface-17's classical control—shared single-qubit drive sources, measurement feedlines, and two-qubit detuning exclusions—completely capture the hardware's real restrictions; if a real constraint is missing, the scheduled circuits may not execute correctly.","fun_headline_variants_meta":{"raw":{"variants":["Qmap: latency-aware routing beats gate-counting on quantum chips","Respecting shared control cuts quantum latency 47% on Surface-17","Quantum mapper: schedule real gate times, not just counts","Shared microwaves? Qmap routes qubits to cut latency up to 47%","Timing and resource-aware mapping slashes quantum circuit overhead"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000783,"raw_usage":{"total_tokens":3514,"prompt_tokens":1058,"completion_tokens":2456,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":674,"completion_tokens_details":{"reasoning_tokens":2364}},"tokens_in":674,"tokens_out":2456,"duration_ms":19170,"temperature":1.0,"reasoning_tokens":2364,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-14T13:47:17.729665+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Execute a Qmap-generated schedule for a benchmark such as decod24bdd on an actual Surface-17 device and compare the measured output distribution with the ideal simulated one; a missed control constraint—for example, two same-frequency single-qubit gates issued in the same cycle or a CZ executed while a qubit that should be parked is busy—would produce a characteristic error signature on the affected qubits.","supporting_citations":[{"cited_title":"Venturelli, M","cited_arxiv_id":null,"evidence_quote":"Supplies the Surface-17 hardware model: topology, frequency groups, detuning restrictions, measurement feedlines, and classical control constraints the mapper must satisfy."},{"cited_title":"OpenQL : A Portable Quantum Programming Framework for Quantum Accelerators","cited_arxiv_id":"2005.13283","evidence_quote":"Provides the primitive-gate durations used in scheduling, including single-qubit gates at 1 cycle, CZ at 2 cycles, and measurement at 15 cycles."},{"cited_title":"Wille, D","cited_arxiv_id":null,"evidence_quote":"Defines the critical-path list-scheduling technique that the resource-constrained scheduler generalizes."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Establishes that resource-constrained scheduling is NP-hard in the strong sense, motivating the paper's polynomial heuristic."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Represents prior timing- and crosstalk-aware mapping work that uses exact optimization with exponential complexity, which Qmap is contrasted against."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Shows that prior mappers' output circuits require a later pulse-level scheduling pass, the step Qmap aims to make unnecessary."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Is the compiler Qmap is embedded in, giving the mapper its circuit input and its executable QASM-like output path."},{"cited_title":"Venturelli, M","cited_arxiv_id":null,"evidence_quote":"Supplies part of the benchmark circuits used to measure mapping overhead."},{"cited_title":"Versluis, S","cited_arxiv_id":null,"evidence_quote":"Supplies the remaining benchmarks in the 56-circuit evaluation."}],"review_version":1}