Hardware-Assisted PCE for Quantum Circuits

• Hardware-Assisted PCE is a method that separates a circuit’s static pulse skeleton from its dynamic parameters, enabling real-time binding on FPGA control hardware.
• It leverages the RIP compiler pipeline and dedicated modules like Stitch and Deft to group structurally equivalent circuits, cutting classical control time by up to 85%.
• Demonstrated on superconducting and time-evolution circuits, the approach achieves up to 995× compilation speedup while maintaining high fidelity.

Hardware-Assisted Parameterized Circuit Execution (PCE) is a hardware–software co-design for executing large families of quantum circuits that share a compiled pulse skeleton but differ in numerical parameters. In the formulation introduced on the FPGA-based QubiC control stack, a circuit family is represented by a single compiled template together with parameter tables, and the control FPGA performs real-time parameter binding during execution rather than requiring per-circuit compilation and upload. The original implementation targets structurally equivalent pulse schedules that differ primarily in virtual-$Z$ phases, while subsequent work extended the same execution model to constant-depth Cartan time-evolution circuits whose gate layout is fixed across time points and only a subset of rotation angles changes with $t$ (Rajagopala et al., 2024, Francis et al., 17 Jul 2025).

1. Definition and conceptual basis

Hardware-Assisted PCE is defined around the distinction between a circuit’s static pulse structure and its dynamic scalar parameters. For superconducting control stacks of the type studied in QubiC, arbitrary single-qubit gates are compiled into a fixed $ZXZXZ$ pattern,

$$U_3(\phi,\theta,\lambda)=Z_{\phi-\pi/2}X_{\pi/2}Z_{\pi-\theta}X_{\pi/2}Z_{\lambda-\pi/2},$$

so the calibrated physical content is a repeated pair of $X_{\pi/2}$ pulses, while the logical variability is carried by virtual-$Z$ phase updates. This makes large circuit families pulse-level identical even when they implement different logical operations (Rajagopala et al., 2024).

The central abstraction is structural equivalence. Two circuits are structurally equivalent when, after compilation into QubiC native gates using the $ZXZXZ$ rule, their DAG representations have the same gate topology and ordering, the same gate types and qubit targets, and differ only in parameter values. In the original study, this pattern arises in variational circuits, randomized compiling, randomized benchmarking, cycle benchmarking, and gate set tomography; in the later time-evolution study, it arises because Cartan-based constant-depth simulations share a fixed entangling scaffold and differ only in single-qubit rotation angles associated with the Cartan $\mathfrak{h}$-part (Rajagopala et al., 2024, Francis et al., 17 Jul 2025).

This execution model differs from software-only symbolic parameter binding. In Qiskit- or PennyLane-style parameterized circuits, parameter substitution typically remains a software-layer concern. In Hardware-Assisted PCE, the FPGA stores parameter tables, distributed pulse sequencers issue parameter-fetch micro-operations, and the control hardware returns phase values in two $500\,\text{MHz}$ cycles, i.e. $4\,\text{ns}$, so the final specialization step occurs inside the control plane itself (Rajagopala et al., 2024).

2. Static templates, parameter peeling, and circuit classes

The compiler front-end for Hardware-Assisted PCE is the RIP pipeline—Read–Identify–Peel. RIP preprocesses circuits from openQASM3, Qiskit, True-Q, or pyGSTi, transpiles them to QubiC-native gates, constructs DAGs, groups structurally equivalent instances, and extracts the varying parameters into compact tables. The grouping step compares DAGs with complexity $t$0 in the number of circuits, maintains equivalence-class sublists of the form $t$1, and can operate either out of order or in order. Out-of-order scheduling is particularly important for GST, where structurally equivalent circuits are dispersed through the batch rather than adjacent (Rajagopala et al., 2024).

RIP’s “peeling” stage traverses the compiled DAGs and extracts the virtual-$t$2 phases that differ across instances. The resulting parameter dictionary is keyed by target qubit index and circuit index within each equivalence class, and is then binarized; the reported host-to-RFSoC transfer is up to $t$3 faster for the binarized representation than for Python data structures (Rajagopala et al., 2024).

The unique circuit that remains after peeling is not a fixed-phase program. RIP rewrites each virtual-$t$4 action into a runtime parameter request using QubiC’s function processor instruction alu_fproc. The rewritten circuit declares a per-qubit phase variable, binds it to the appropriate frequency, initializes it, and then replaces fixed virtual-$t$5 gates with alu_fproc requests that update that phase variable. A $t$6 delay is inserted so that Stitch’s response overlaps with the schedule rather than extending it (Rajagopala et al., 2024).

The static–dynamic separation can be expressed as an equivalence-class model: $t$7 In the paper’s formalization, the compiled representative $t$8 consists of a static pulse skeleton and placeholder alu_fproc instructions, while the dynamic part is the parameter table consumed by Stitch at runtime. The later Cartan time-evolution work preserves exactly this separation: for

$t$9

the $ZXZXZ$0 and $ZXZXZ$1 blocks and the Pauli-gadget entangling pattern are fixed, while only the angles $ZXZXZ$2 vary across time points (Rajagopala et al., 2024, Francis et al., 17 Jul 2025).

3. Control-hardware realization on QubiC

The reference implementation combines three layers: RIP on the host PC, the Deft scheduler on the RFSoC ARM processor, and the Stitch module in FPGA programmable logic. The hardware platform is an AMD Zynq UltraScale+ RFSoC ZCU216; the FPGA PL runs at $ZXZXZ$3, the ARM PS at $ZXZXZ$4, and the AXI full-power-domain bus at $ZXZXZ$5 (Rajagopala et al., 2024).

Deft receives the binarized parameter dictionary and the modified unique circuits through RPC, reconstructs the flattened execution order, writes per-qubit parameter arrays into FPGA BRAMs, loads each unique circuit only once into distributed processor instruction memories, and then executes the batch in the RIP-generated order. Existing QubiC infrastructure is reused for envelopes, frequencies, compiled instructions, run triggering, and measurement readout; the new logic is the driver path for Stitch BRAM and the alignment between parameter tables and compiled templates (Rajagopala et al., 2024).

Stitch is the hardware-resident binding engine. It contains a memory controller, per-qubit parameter memories, and real-time stitching logic. In the reported eight-qubit design, parameter memory is implemented as eight parallel true-dual-port BRAM banks, one per physical qubit, each of capacity $ZXZXZ$6-bit values or $ZXZXZ$7. The top three address bits select one of eight per-qubit memories, while the remaining $ZXZXZ$8 bits select a local address. On an alu_fproc with func_id=10, Stitch interprets the request as “fetch next parameter for this qubit’s current circuit instance,” uses internal counters to track circuit index, parameter index, and shot count, and returns the requested $ZXZXZ$9-bit phase in two FPGA cycles. Prefetching is used in practice to hide latency further (Rajagopala et al., 2024).

The module also supports automatic repetition across shots. For a circuit executed many times, Stitch can replay a parameter subsequence using modest control metadata from Deft rather than requiring explicit host traffic per shot. The same function-processor infrastructure coexists with mid-circuit feed-forward; Stitch disambiguates use cases via core_id. In the eight-qubit implementation, reported resource utilization is $$U_3(\phi,\theta,\lambda)=Z_{\phi-\pi/2}X_{\pi/2}Z_{\pi-\theta}X_{\pi/2}Z_{\lambda-\pi/2},$$0 LUTs ($$U_3(\phi,\theta,\lambda)=Z_{\phi-\pi/2}X_{\pi/2}Z_{\pi-\theta}X_{\pi/2}Z_{\lambda-\pi/2},$$1), $$U_3(\phi,\theta,\lambda)=Z_{\phi-\pi/2}X_{\pi/2}Z_{\pi-\theta}X_{\pi/2}Z_{\lambda-\pi/2},$$2 registers ($$U_3(\phi,\theta,\lambda)=Z_{\phi-\pi/2}X_{\pi/2}Z_{\pi-\theta}X_{\pi/2}Z_{\lambda-\pi/2},$$3), and $$U_3(\phi,\theta,\lambda)=Z_{\phi-\pi/2}X_{\pi/2}Z_{\pi-\theta}X_{\pi/2}Z_{\lambda-\pi/2},$$4 BRAMs ($$U_3(\phi,\theta,\lambda)=Z_{\phi-\pi/2}X_{\pi/2}Z_{\pi-\theta}X_{\pi/2}Z_{\lambda-\pi/2},$$5 of $$U_3(\phi,\theta,\lambda)=Z_{\phi-\pi/2}X_{\pi/2}Z_{\pi-\theta}X_{\pi/2}Z_{\lambda-\pi/2},$$6 available), while still meeting $$U_3(\phi,\theta,\lambda)=Z_{\phi-\pi/2}X_{\pi/2}Z_{\pi-\theta}X_{\pi/2}Z_{\lambda-\pi/2},$$7 timing (Rajagopala et al., 2024).

4. Demonstrated workloads and measured performance

The original PCE study targets quantum characterization, validation, and verification workloads that naturally generate large structurally equivalent batches. A representative motivation is that on the AQT system, single-qubit randomized benchmarking on eight qubits with a $$U_3(\phi,\theta,\lambda)=Z_{\phi-\pi/2}X_{\pi/2}Z_{\pi-\theta}X_{\pi/2}Z_{\lambda-\pi/2},$$8 idle per shot took about $$U_3(\phi,\theta,\lambda)=Z_{\phi-\pi/2}X_{\pi/2}Z_{\pi-\theta}X_{\pi/2}Z_{\lambda-\pi/2},$$9, and more than $X_{\pi/2}$0 of the wall time was purely classical—compilation, assembly, upload, and related control overheads. Hardware-Assisted PCE attacks this classical fraction by compiling one representative pulse program per equivalence class and shifting the remaining specialization step into Stitch (Rajagopala et al., 2024).

The measured speedups track the ratio of total circuits to unique templates. The paper reports $X_{\pi/2}$1 to $X_{\pi/2}$2 compilation speedup, $X_{\pi/2}$3 to $X_{\pi/2}$4 classical-time reduction, and $X_{\pi/2}$5 to $X_{\pi/2}$6 classical speedup across its benchmark suite. The later time-evolution study shows that the same architecture extends from QCVV to algorithmic workloads: structurally equivalent Cartan time-evolution circuits for TFXY and Heisenberg spin models achieve about $X_{\pi/2}$7 reduction in total classical time and up to roughly $X_{\pi/2}$8 compilation speedup for $X_{\pi/2}$9-circuit batches (Rajagopala et al., 2024, Francis et al., 17 Jul 2025).

Workload	Structural compression	Reported effect
RC20	$Z$0 circuits, $Z$1 unique templates	$Z$2 compilation speedup; $Z$3 classical-time reduction; $Z$4 classical speedup
FRC	$Z$5 circuits, $Z$6 unique templates	$Z$7 compilation speedup; $Z$8 classical-time reduction; $Z$9 classical speedup
2-qubit GST	$ZXZXZ$0 circuits, $ZXZXZ$1 unique templates	$ZXZXZ$2 compilation speedup; $ZXZXZ$3 classical-time reduction; $ZXZXZ$4 classical speedup
Simultaneous single-qubit RB	$ZXZXZ$5 total circuits, $ZXZXZ$6 unique templates, $ZXZXZ$7 parameters	compile speedup $ZXZXZ$8; assemble speedup $ZXZXZ$9; load circuits $\mathfrak{h}$0 faster
TFXY, 6 sites, 500 circuits	one constant-depth template across time points	$\mathfrak{h}$1 compilation speedup; $\mathfrak{h}$2 time reduction; $\mathfrak{h}$3 saved
Heisenberg, 3 sites, 500 circuits	one constant-depth template across time points	$\mathfrak{h}$4 compilation speedup; $\mathfrak{h}$5 time reduction; $\mathfrak{h}$6 saved

The results also quantify the hardware cost of runtime binding itself. For 2-qubit GST, Stitch served about $\mathfrak{h}$7 billion parameter fetches—$\mathfrak{h}$8 parameters repeated over $\mathfrak{h}$9 shots—with only about $500\,\text{MHz}$0 of Stitch overhead, or about $500\,\text{MHz}$1 of total runtime. This is the critical systems result: once parameter fetch latency is pushed into the nanosecond regime and overlapped with execution, the end-to-end bottleneck becomes template count and host scheduling rather than parameter binding (Rajagopala et al., 2024).

5. Correctness, fidelity, and operational constraints

The correctness claim of Hardware-Assisted PCE is narrow and explicit: the technique does not change physical pulse shapes or scheduling semantics relative to a conventional workflow. Unique circuits are compiled exactly as before; the only difference is that virtual-$500\,\text{MHz}$2 phase arguments cease to be compile-time constants and become runtime variables updated by Stitch. Since virtual $500\,\text{MHz}$3 is implemented as a phase-frame update, replacing a constant $500\,\text{MHz}$4 with a fetched $500\,\text{MHz}$5 preserves the same frame evolution provided the fetched value is the intended one (Rajagopala et al., 2024).

Empirically, the reported fidelity comparisons do not indicate degradation from runtime stitching. In single-qubit RB, the process infidelity is $500\,\text{MHz}$6 for software execution and $500\,\text{MHz}$7 for PCE. In two-qubit cycle benchmarking of a CZ gate, the reported process infidelities are $500\,\text{MHz}$8 for software and $500\,\text{MHz}$9 for PCE. In GST, differences in entanglement infidelities are of order $4\,\text{ns}$0 for one-qubit gates and $4\,\text{ns}$1 for CZ, within uncertainties. The GST model-violation metric at $4\,\text{ns}$2 is $4\,\text{ns}$3 for software GST and $4\,\text{ns}$4 for PCE GST; the paper states that the lower model violation is likely due to reduced drift from shorter total experiment time (Rajagopala et al., 2024).

The constraints are equally specific. PCE requires batches with stable structural equivalence after transpilation, so compiler passes that rewrite circuit structure aggressively can destroy the very equivalence classes the system depends on. The Cartan time-evolution study therefore avoids aggressive optimizations that could alter structure across time points. RIP’s equivalence detection is $4\,\text{ns}$5 in the number of circuits, which is workable for the demonstrated workloads but identified as a target for better graph hashing. The current implementation parameterizes primarily virtual-$4\,\text{ns}$6 phases; this is powerful for superconducting control because virtual $4\,\text{ns}$7 is a frame update, but it also means the technique is most natural when logical variability is concentrated in those phase degrees of freedom (Rajagopala et al., 2024, Francis et al., 17 Jul 2025).

6. Related directions and broader generalizations

Hardware-Assisted PCE sits within a wider parameterized-execution landscape. A direct compiler-side precursor is OpenQL Parameterized Compilation, which introduces explicit typed parameters (INT, REAL, ANGLE) and preserves them through compilation so that the circuit structure is compiled once and later rebound to new values. For the MAXCUT benchmark, the paper reports that OpenQL_PC reduces compilation time considerably and that compilation of hybrid algorithms is up to two times faster than with PyQuil or Qiskit (Krol et al., 2022). This establishes the same static-versus-dynamic separation, but at compiler IR level rather than inside FPGA control hardware.

A complementary line concerns hardware-native continuously parameterized gates and noise-aware compilation. On QSCOUT, the native entangling gate is

$4\,\text{ns}$8

implemented at fixed duration $4\,\text{ns}$9 with angle control via Raman-beam amplitude. The associated compiler optimizations—continuous-angle KAK decomposition, swap mirroring, gate ranking on the best-performing pairs, and angle-threshold circuit approximation—treat total entangling angle $t$00 as a first-class compilation cost (Yale et al., 2024). Crosstalk-aware ansatz reconstruction on ibmq_guadalupe provides another related variant: SRB-characterized conditional EPCs are incorporated into the XtalkSched objective to trade gate-error and decoherence, and the resulting Xtalk_pqcs improve VQE performance while reducing runtime and two-qubit gate count (Ibrahim et al., 2023). These works are not the same protocol as Hardware-Assisted PCE, but they share the principle that parameter values, hardware characterization, and execution infrastructure must be co-designed rather than layered independently.

A broader generalization is suggested by recent homomorphic-computing hardware. The FPGA-based TFHE processor described in “Towards a Functionally Complete and Parameterizable TFHE Processor” executes homomorphic circuits as instruction streams whose semantics depend on runtime-supplied addresses, LUT contents, key indices, extraction indices, and opcodes, rather than on fixed-function hardware. That processor is designed so that “the circuit is a parameterized program” running on a reusable datapath (Häusler et al., 27 Oct 2025). This suggests that Hardware-Assisted PCE can be understood more generally as a systems pattern: compile and store the static structure once, externalize the variable semantics into compact parameter streams, and perform the final specialization in hardware close to the execution substrate.