Hardware-Assisted Parameterized Circuit Execution
Abhi D. Rajagopala Akel Hashim Neelay Fruitwala Gang Huang Yilun Xu Jordan Hines Irfan Siddiqi Katherine Klymko Kasra Nowrouzi





    Applied Math and Computational Research Division, Lawrence Berkeley National Lab, Berkeley, CA 94720, USA

    Applied Math and Computational Research Division, Lawrence Berkeley National Lab, Berkeley, CA 94720, USA
    Quantum Nanoelectronics Laboratory, Department of Physics, University of California at Berkeley, Berkeley, CA 94720, USA

    Accelerator Technology and Applied Physics Division, Lawrence Berkeley National Lab, Berkeley, CA 94720, USA

    
    Accelerator Technology and Applied Physics Division, Lawrence Berkeley National Lab, Berkeley, CA 94720, USA

    Accelerator Technology and Applied Physics Division, Lawrence Berkeley National Lab, Berkeley, CA 94720, USA

    Department of Physics, University of California at Berkeley, Berkeley, CA 94720, USA

    Quantum Nanoelectronics Laboratory, Department of Physics, University of California at Berkeley, Berkeley, CA 94720, USA
    Applied Math and Computational Research Division, Lawrence Berkeley National Lab, Berkeley, CA 94720, USA
    Materials Sciences Division, Lawrence Berkeley National Lab, Berkeley, CA 94720, USA

    National Energy Research Scientific Computing Center, Lawrence Berkeley National Lab, Berkeley, CA 94720, USA

    Applied Math and Computational Research Division, Lawrence Berkeley National Lab, Berkeley, CA 94720, USA

 


§ ABSTRACT 
Standard compilers for quantum circuits decompose arbitrary single-qubit gates into a sequence of physical X_π/2 pulses and virtual-Z phase gates. Consequently, many circuit classes implement different logic operations but have an equivalent structure of physical pulses that only differ by changes in virtual phases. When many structurally-equivalent circuits need to be measured, generating sequences for each circuit is unnecessary and cumbersome, since compiling and loading sequences onto classical control hardware is a primary bottleneck in quantum circuit execution. In this work, we develop a hardware-assisted protocol for executing parameterized circuits on our FPGA-based control hardware, . This protocol relies on a hardware-software co-design technique in which software identifies structural equivalency in circuits and “peels” off the relevant parameterized angles to reduce the overall waveform compilation time. The hardware architecture then performs real-time “stitching” of the parameters in the circuit to measure circuits that implement a different overall logical operation. This work demonstrates significant speed ups in the total execution time for several different classes of quantum circuits.




Hardware-Assisted Parameterized Circuit Execution
    Kasra Nowrouzi
    September 9, 2024
=================================================





§ INTRODUCTION


A quantum processing unit (QPU) is defined by its topology (i.e., qubit-to-qubit connectivity) and its native gate set. A gate set consists of a set of native state preparations (usually chosen to be |0⟩ for all qubits), a set of native single-qubit gates for all qubits, a set of native two-qubit gates between all qubit pairs, and a set of native positive operator-valued measures (POVMs; native measurements are usually chosen to be in the computational basis). Quantum compilers decompose all quantum circuits (using a set of ordered instructions) according to the QPU's topology and gate set. Most quantum circuits are designed with a restricted set of multi-qubit gates (e.g., using only CX or CZ gates). However, generally single-qubit gates in a circuit are allowed to be arbitrary. In order to implement arbitrary rotations in 𝖲𝖴(2), quantum compilers typically decompose single-qubit gates in terms of discrete physical X_π/2 pulses (implemented via resonant Rabi-driven pulses) and arbitrary virtual-Z phase gates <cit.>, which are performed in software as a change the phase of the subsequent physical pulse. Thus, arbitrary single-qubit gates are often termed U_3 gates, as they are decomposed as unitaries that are parameterized by three distinct phases:

    U_3(ϕ, θ, λ) = Z_ϕ - π/2 X_π/2 Z_π - θ X_π/2 Z_λ - π/2 .

This ZXZXZ-decomposition reduces the time needed to implement arbitrary single-qubit gates (only a single X_π/2 needs to be calibrated per qubit), but comes at the cost of requiring two physical pulses per single-qubit gate (for most gates). Importantly, in this manner, all single-qubit gates are parameterized by three phases, such that implementing different single-qubit gates equates to changing the phases of the physical pulses, without needing to change any of the physical parameters of the X_π/2 pulses themselves (e.g., amplitude, frequency, pulse envelope, etc.).

Many classes of quantum circuits are designed to be structurally-equivalent — i.e., they contain the same structure of physical pulses, but the virtual phases in the single-qubit gates might differ. In some cases, structurally-equivalent circuits implement a different overall logic operation, as is the case for many variational quantum algorithms <cit.>, such as the variational quantum eigensolver <cit.>, the quantum approximate optimization algorithm <cit.>, and the circuits used for quantum machine learning <cit.>. On the other hand, some structurally-equivalent circuits are instead designed to be logically-equivalent, as is the case for noise tailoring methods such as randomized compiling (RC) <cit.>, Pauli frame randomization <cit.>, and equivalent circuit averaging <cit.>. Similarly, many circuits used for quantum characterization, verification, validation (QCVV) are by design structurally-equivalent (for a given circuit depth). For example, state tomography, quantum process tomography <cit.>, gate set tomography (GST) <cit.>, randomized benchmarking (RB) <cit.>, cycle benchmarking (CB) <cit.>, and many others. 

All of the aforementioned protocols require generating, compiling, and measuring a large (∼100 – 10000) number of circuits. The naive strategy for doing so is to compile and measure sequences for each circuit independently, creating a large bottleneck on the classical side of the control hardware. However, in many cases, this is both unnecessary and time-consuming, since the waveform for structurally-equivalent circuits has already been loaded onto the hardware. In this work, we introduce a co-designed hardware-software technique that addresses the classical-bound bottlenecks for parameterized circuit execution. The technique involves two protocols — Read-Identify-Peel (RIP) and Stitch with Deft scheduling — which universally applies to any set of structurally-equivalent quantum circuits to improve their execution efficiency. Our approach identifies circuits with equivalent pulse structures, selectively compiles unique circuits (one from each batch of structurally-equivalent circuits), peels and stores the variable parameters for each circuit, and re-attaches at run time while executing on the control system. This technique reduces the compilation time by a constant factor and adds minimal runtime overhead on resource-constrained control systems. We demonstrate significant temporal gains for the overall run time for several commonly-used protocols, including RC, RB, CB, and GST.



§ PARAMETERIZED CIRCUIT EXECUTION
 



In this work, we design a hardware-assisted parameterized circuit execution (PCE) protocol by introducing two techniques — Read-Identify-Peel (RIP) and Stitch with Deft Scheduling — to improve the execution efficiency for classes of structurally-equivalent circuits. As shown in Fig. <ref>, the process is a hardware-software co-designed protocol involving a general purpose computer, referred to as Host Computer, an embedded software computer, referred to as  Software on ARM, and a hardware design on the FPGA that runs on the control system. The software, done in Python, identifies structurally-equivalent circuits, separates the phase parameters in single-qubit gates, and orchestrates the circuit execution; the hardware performs the parameterized execution in real time. The control system in this work uses AMD (formerly Xilinx) Zynq UltraScale+ RFSoC ZCU216 evaluation kit <cit.>, consisting of ARM processors and an FPGA. The deft scheduler runs on the ARM processor, and the Stitch design, written in Verilog/System Verilog, is implemented on the FPGA. The design integrates with the  2.0 control system <cit.>, an open-source FPGA-based quantum control system developed at Lawrence Berkeley National Laboratory.




 §.§ Read-Identify-Peel (RIP)




RIP is a software process written in Python and runs on a general-purpose computer (i.e., Host Computer). Figure <ref> shows the process that prepares the circuits for parameterized execution and provides the necessary information to the control system's deft scheduler and the Stitch process. The RIP technique is generic and can be adapted (with minimal changes) to any circuit abstraction. Currently, the process integrates to the native control system gate format, QubiC, and has been tested with circuits written/compiled in  <cit.>,  <cit.>,  <cit.>,  <cit.>, and -native gate abstraction. As shown in Fig. <ref>a, the circuit abstraction-specific compiler (e.g., a compiler for , , , or  circuits) compiles the circuit into native single- and two-qubit gates, where the single-qubit gates are decomposed according to Eq. <ref>. The  transpiler converts these compiled circuits into  instructions, which is the input to the RIP stage.

The Read-Identify method identifies the structural equivalency in a batch of circuits. The process reads each circuit in the list of circuits and creates a set of graphs for each circuit. Each graph consists of a root node for the target qubits and the gates associated with it in the same timing order. After constructing the graph for a circuit, the process compares the graph for structural equivalency in the previous circuit graph. If the graph does not match any prior graph, the circuit is unique. Each unique circuit is added as a new sublist in the list of circuit indices and marked for circuit modification. If there is equivalency, then the circuit index is appended to the sublist of the equivalent circuit index. After reading all the circuits in the batch, the process identifies structurally-equivalent circuits as a list of circuit indices, where each sublist has all the structurally-equivalent circuits and the first index depicting the unique circuit. The flattened list of lists will provide the circuit execution order for the deft scheduler. The computational complexity of finding equivalency is 𝒪(n^2), where n is the number of circuits. Depending on the algorithm, similar circuits can be next to each other (for RC, RB, and CB circuits) or in a random order in the batch (in the case of GST). The read-identify process can automatically identify the structural equivalency in both scenarios.

The Peel method extracts the parameters from the circuits. The process uses the graph from the Read-Identify process to extract the parameters from each of the circuits. The extraction identifies the graph nodes with desired parameters (e.g., virtual-Z phases) and creates a dictionary based on the circuit and the target physical qubit. The entire dictionary is then binarized and transmitted to the deft scheduler. The binarization is a performance method and provides up to 15× speed up compared to transmitting a non-binarized dictionary.

Modification of circuits is the final method in the RIP process. The unique circuits marked during the Read-Identify phase are modified to request the phase in real time. This process replaces the parameter instructions (), from where the peel method has extracted the phases, into a phase request instruction, . These instructions are specific to the  distributed processor and request the phase from the Stitch module in FPGA. In  terms, the Stitch module acts as a Function Processor <cit.>, or .



 §.§ Stitch

The Stitch process re-attaches the parameters from the RIP process in the FPGA. The Stitch module consists of three subcomponents: the memory controller, parameter memory, and the stitch logic. The memory controller interfaces with the ARM processor for the read/write of the parameters, the parameter memory holds the parameter values, and the stitch logic interacts with the  distributed processor for parameterized circuit execution. The Stitch modules are highly modularized and extensible for several qubits. The current design is written in a combination of Verilog and System Verilog, and runs at the clock speed of 500 MHz, supporting parameterization of up to eight physical qubits.

The  control system uses the Zynq UltraScale+ RF-SoC ZCU216 evaluation kit as the hardware platform. The development board consists of ARM processors and FPGA running in different frequency domains. The ARM processor runs up to 1.33 GHz and connects to the extensible parameter memory on FPGA running at 500 MHz (design choice) via an AXI bus running at 100 MHz (the Full Power Domain bus). The memory controller is a cross-clock domain module interacting with the single AXI bus and the parallel parameter memory interface. Within the controller lies a single-stage switch that translates the AXI memory map to the parameter memory map. The current mapping is a 32-bit AXI to a 14-bit parameter memory; of the 14-bit, the first 3 bits map the eight parallel memories of 2^11 bytes. 

The parameter memory is an FPGA Block RAM (BRAM) containing parallel memories for each physical qubit (eight memories in the current implementation). Each parallel memory is 8 kilobytes and holds up to 2048 32-bit parameters per circuit. Each memory is a true dual-port (TDP) design, with one interface to the controller and the other to the stitch logic. In a normal parameterized circuit execution, the memory controller interface writes the parameter to the memory, and the stitch logic reads from the memory. The rest of the read and write bus, i.e., read from memory controller and write from stitch logic, are only used for debugging.

The stitch logic block is the heart of the hardware-assisted parameterization and interacts with the parameter memories and the  control system's distributed processor. The current design hosts eight parallel interfaces for the memory and eight  interfaces for the processor. The  interface requests the parameters, and the stitch logic pulls them from the parameter memory and provides them back to the . Since the request pulls are sequential, the logic uses prefetch functionality to improve performance and completes a parameter request within 4 ns. Further, each quantum circuit typically runs for N times (shots), and the stitch logic tracks the number of parameters in a circuit and repeats itself for N times. Also, the architecture supports the existing mid-circuit measurement functionality. The request type between a parameter and a mid-circuit measurement from the control processor is distinguished using the  parameter in the  interface. Additionally, the logic can repeat a partial set of the parameters and switch to a different set. The control codes set by the deft scheduler before circuit execution facilitate these functionalities.




 §.§ Deft Scheduler


Deft Scheduling orchestrates the circuit execution by interacting with the RIP and the Stitch layer. The scheduler is Python software running on the ARM processor on the control hardware. It integrates with the existing  software API infrastructure by adding methods to the  class. The integration allows users to use the PCE functionality with the existing  API infrastructure. On the control side, the scheduler creates new methods (low-level memory drivers) for circuit and parameter loading. It reuses the  load definitions for writing the envelope and frequency parameters, run-circuit to trigger the circuit run, and get-data methods for collecting the data.

The deft scheduler receives a dictionary of parameters and the modified unique circuits from the host computer via a remote procedure call (RPC). The scheduler de-binarizes the parameter dictionary to read the circuit order and parameters. It takes the index from the circuit order and loads the parameters to the parameter memory in the FPGA. It loads the circuit only if the index belongs to the unique circuit list. Once the parameters and circuits are loaded, the scheduler continues the standard software operations by loading the definitions (controlled by user flags), running the circuits, receiving the data from the FPGA, and transferring data to the host computer.


§ TIME PROFILING


The PCE protocol should reduce the execution time of quantum circuits. As seen in Sec. <ref>, a quantum circuit execution consists of multiple steps over different computational domains, such as the host computer and the control system. Understanding the efficacy of PCE requires detailed time profiling of each step in the execution process. Thus, we added a time profiling infrastructure to  to measure the time at different stages.



 §.§ Time Profiling Infrastructure




The time profiling presented here occurs at three layers: the application, the host computer software, and the control system software. Each layer has multiple classical computation stages; in some cases, each stage has sub-stages of operations. During a circuit execution, these stages and sub-stages may run for varying iterations. For example, to run a single circuit for 100 shots, the compilation and the circuit load stage run once, whereas the run circuit stage has 100 iterations (1 per shot). The profiler captures the time spent on all the stages and sub-stages at different layers for varying iterations, and collects them into a Python dictionary. For ease of use, the profiling infrastructure integrates with the control software layer and allows the user to control the time profiling for all layers from the application layer.

Application Layer: this layer is the front end of the circuit execution. The experiments in this manuscript run as a Jupyter Notebook on an Intel i9-11900K desktop processor. Typically, this layer is responsible for circuit creation, pre-compilation, parameterization and control software initiation, and result display. The different profiling stages in this layer are as follows:


    
  * Pre-compile creates or reads circuits, compiles, and transpiles to a native control system gate format. This stage refers to the process described in Section <ref> and Fig. <ref>(a). Even though this is a compilation stage, the word `Pre-Compile' is chosen to differentiate the compile stage in the host computer software layer, which converts the circuits into pulse definition. The pre-compile stage has the following sub-stages:
    
        
  * Get circuit provides the circuit by generating or reading a pre-generated circuit from the file.
        
  * Transpile converts the circuit shown in Eq. <ref> into the native control software gate format.
    
    
  * RIP is the software parameterization stage identifying the structural equivalency, extracting the phases, and modifying the circuit for PCE.
    
  * Active is an optional stage to convert a circuit from a passive reset (500 μ s in current QPU) to an active reset circuit.
    
  * Build Run transfers the control from the application layer to the host computer software layer and receives the quantum data from the control system.
    
  * Total is the complete execution time from the start of circuit creation to the display of the result for an experiment.


Host Computer Software Layer: the application layer initiates this layer for circuit execution. Like the application layer, this layer also runs on the desktop as a Python module. This layer initiates the circuit execution by compiling and assembling the circuit and transferring the output to the software running on the control hardware by acting as a client in a remote procedure call (RPC). After the circuit execution, it reads the data from the RPC server running on the control hardware and passes it to the application layer. This layer has the following stages and sub-stages:


    
  * Compile converts the circuit from the native control software gate format into control hardware-specific assembly instructions.
    
  * Assemble converts the assembly language instructions into a machine code.
    
  * RunAll on Host covers the time to run the circuits and get the result data.
    
        
  * Run on Host measures the run time of the circuits from the host computer.
        
  * Data Sort converts the raw IQ data into a distribution of bit strings.
    
    
  * Client/Server is a post-processing calculation for measuring the time taken for data transmission between the RPC client and server.


Control Software Layer: the control software layer runs on the ARM processor of the control hardware platform (AMD ZCU216 RFSoC) as a Python module. The control software receives the circuits and the execution parameters from the host computer software layer via the RPC protocol. The control software interacts with the control hardware FPGA to load all the circuit elements, run the circuits, and collect the data. This process has the following stages:


    
  * Load Batch transfers all the circuit parameters from the ARM processor to different memories in the FPGA. This stage has the following sub-stages:
    
        
  * Load circuit transfers the quantum circuits from the ARM processor to the command memory in FPGA.
        
  * Load definition is a multi-stage loading of circuit parameters such as signal envelope and frequencies.
        
  * Load env. transfers the signal envelope.
        
  * Load freq. transfers the frequency parameters.
        
  * Load zero clears the command buffer.
    
    
  * Load para transfers the parameters peeled in RIP to the parameter memory in FPGA.
    
  * Run Batch starts with the run trigger to start the circuit execution and ends with getting the quantum data.
    
        
  * Start Run measures the run time of the circuit on the FPGA.
        
  * Get data is the time to read the quantum measurement data from the FPGA.
    
    
  * Stitch is a post-processing measurement for the stitch module to serve the stitch request inside FPGA.





 §.§ Randomized Compiling


To benchmark the runtime improvements of PCE for classes of equivalent circuits, we profile the total execution time of random circuits at varying depths (from 1 – 100, defined by the number of two-qubit gate cycles) and widths (2 – 8 qubits) measured with randomized compiling (RC), shown in <ref>. We measure each circuit under RC with N=20 randomization (50 shots/randomization) and N=1000 randomization (1 shot/randomization). The latter case is called the fully randomly compiled (FRC) limit <cit.>, since each randomization is measured a single time. We generate RC circuits using  <cit.> for both the software and parameterized protocols. The software implementation follows the existing  software infrastructure to generate sequences and upload them to the control hardware for each randomization. The PCE implementation follows the RIP and Stitch protocols. The experiment details for the different RC cases are listed in Appendices <ref> and <ref>.

In <ref>(a) and (b), we plot the profiling results for the software and parameterized RC results with N=20 randomization, respectively. In <ref>(c) and (d), we plot the profiling results for the software and parameterized RC results with N=1000 randomization, respectively. We observe that parameterized RC provides a ∼3× and ∼5× speedup over software RC for N = 20 and N = 1000 randomizations, respectively. For software RC, the main temporal bottleneck is compile and assemble due to the need to compile many different circuits from  to the low-level machine code. For parameterized RC, the main temporal bottleneck is pre-compile, stemming from the compilation of circuits into the native gates.




§ VALIDATION, BENCHMARKING, AND CHARACTERIZATION




The PCE protocol applies to many classes of circuits and is primarily beneficial in the regime in which a large number of structurally-equivalent circuits need to be measured. A prototypical example of this is benchmarking and characterization circuits. For example, the circuits to perform quantum process tomography (QPT) are identical, except for a change in preparation and measurement basis. Basis rotations can be expressed in terms of combinations of a single physical gate (e.g., X_π/2) and virtual Z gates; in this case, many QPT circuits will have the same structure of physical pulses which differ only by a change in virtual phase. Here, we validate the performance of our PCE protocol against the standard protocols for randomized benchmarking (RB) <cit.>, cycle benchmarking (CB) <cit.>, and gate set tomography (GST) <cit.>.







 §.§ Randomized Benchmarking


A depth m RB circuit consists of m randomly sampled Clifford gates and a single inversion gate at the end rotates the system back to the starting state. For single-qubit RB, all single-qubit Cliffords can be decomposed into native gates and virtual phases via <ref>. Thus, a depth m single-qubit RB circuit consists of 2(m + 1) physical X_π/2 gates, and 3(m + 1) virtual Z gates. This makes RB an ideal candidate for PCE since all waveforms for a given circuit depth are structurally equivalent. In <ref>, we plot single-qubit RB results measured using the standard “software”-based procedure, whereby all circuits are independently sequenced and measured, and compare the results to the same circuits executed using PCE. We observe perfect agreement between the two (up to the uncertainty), with a process infidelity (i.e., error per Clifford) of 1.7(2) × 10^-3 and 1.5(1) × 10^-3 for the software and PCE results, respectively.



In Figs. <ref>(c) and (d), we profile the time it takes to perform RB on the host and control systems, respectively using the experiment parameters described in Appendix <ref>. We observe that PCE provides a 27× speedup for the compile stage and a 13× speedup for the assemble stage on the host computer. On the control side, we observe a 7× speedup for loading the circuits, but we have an additional cost of loading the parameters onto the FPGA. Altogether, we observe a 4× speedup in the classical side of performing RB, and a 2.5× speedup for the overall run time, as shown in <ref>(e) (here, the quantum measurement time is the same in both cases, since the total number of shots is the same). Also shown in <ref>(e) is a comparison of the total execution time for software-based and PCE-based RB when the number of qubits is scaled from 1 to 8. The speed up in <ref>(e) is lower compare to <ref>(c) and (d) for two reasons. First, the data read back time, which are constant for both software and PCE adds 22 seconds which 10% of the overall classical time as given in Table <ref>. Second, the circuit runtime with a passive reset of 500 ns, which adds to 23% of runtime. We observe that while the classical cost of both the software and PCE protocols scales linearly in the number of qubits, this cost grows much more rapidly for the software-based protocol than for PCE, demonstrating that PCE gives us a larger relative speedup as the number of qubits grows.

It should be noted that PCE might not provide drastic improvements for all protocols. For example, for two-qubit RB, one must decompose a two-qubit Clifford gate to native gates, which does not always result in the same number of native operations (any two-qubit unitary can be expressed in as little as one native two-qubit gate or as much as three native two-qubit gates). Therefore, not all circuits at a given circuit depth will be structurally-equivalent, limiting the effectiveness of the protocol.




 §.§ Cycle Benchmarking


A depth m CB circuit consists of m interleaved cycles of n random Pauli gates followed by an n-qubit gate cycle, as well as a single cycle of Paulis at the end of the sequence which rotates the system back to the Pauli eigenstate in which it started. Thus, all CB circuits of a given depth are structurally-equivalent and can be implemented with PCE, since the single-qubit Pauli gates are decomposed according to <ref> and the n-qubit gate cycle is decomposed in a manner which depends on the gates in the cycle. Here, our interleaved gate is a two-qubit CZ gate, a native gate in our system, and is directly compiled down to the pulse definition of the gate. In Figs. <ref>(a) – (b), we plot the exponential decays for CB measured using the standard “software”-based procedure, whereby all circuits are independently sequenced and measured, and compare the results to the same circuits executed using PCE. In <ref>(c) – (d), we plot the individual Pauli infidelities (which define the different bases in which the system is prepared and measured), as well as the average process infidelity; we find that the software and PCE results are in perfect agreement (up to the uncertainty), with a (dressed) CZ process infidelity of 2.1(1) × 10^-2 and 2.19(9) × 10^-2 for the software and PCE results, respectively.

In Figs. <ref>(c) and (d), we profile the time it takes to perform CB on the host and control systems based on experiment parameters described in Appendix <ref>. We observe that PCE provides a 252× speedup for the compile stage and a 187× speedup for the assemble stage on the host computer. These values are greater than for RB because CB typically requires more circuits than RB (due to the need to prepare and measure different bases). On the control side, we observe a 100× speedup for loading the circuits, but we have the additional cost of loading the parameters onto the FPGA. Altogether, we observe a 5× speedup in the classical side of performing CB and a 1.8× speedup for the overall run time, as shown in <ref>(g). As mentioned in RB, the CB is also affected by the read which is 28% of the overall classical time as given in Table <ref>, and the runtime which constitutes for 44% of the total execution time. Moreover, similar to RB, the classical run time improvement gets larger as we scale the number of qubits from 2 – 8.




 §.§ Gate Set Tomography








Tomographic reconstruction methods, such as QPT and GST, scale exponentially in the number of qubits and are thus typically a very costly form of gate characterization. While PCE cannot change the poor scaling of tomography, it can improve their runtime performance, since there is a high degree of degeneracy in circuit structures, particularly for long-sequence GST. To demonstrate this, we perform two-qubit GST with and without PCE (Appendix <ref> describes the experiment parameters), and summarize some of the relevant performance metrics in Table <ref>. We observe that the estimated entanglement infidelities for all of the gates in the gate set (except Y_π/2 on Q2) are equal up to 10^-3 (10^-2) for the single-qubit gates (two-qubit CZ gate). However, we observe that the model violation (N_σ) is significantly lower for PCE (411) than for the standard case (2672), suggesting that the GST model for the PCE data is more trustworthy. This could be, in part, due to the fact that PCE reduces the total execution time (see Table <ref>), and thus would be less susceptible to any kind of parameter drift during the execution of the circuits.

In Figs. <ref>(a) and (b), we profile the time it takes to perform GST on the host and control systems, respectively. We observe that PCE provides an 89× speedup for the compile stage and a 37× speedup for the assemble stage on the host computer. On the control side, we observe a 22× speedup for loading the circuits, but we have the additional cost of loading the parameters onto the FPGA. Altogether, we observe a 6.86× speedup in the classical side of performing GST. Even though, as shown in Table <ref>, the classical time for GST is about 13.34%.



§ CONCLUSIONS


In this work, we develop a protocol for implementing parameterized circuits on our FPGA-based control hardware, . Our protocol — PCE — incorporates both software and hardware components for identifying structurally-equivalent circuits, determining the parameterized rotation phases and storing them in memory on the FPGA, and stitching these phases back into a physical waveform loaded onto the FPGA for measuring different circuits. We demonstrate significant time savings for a number of different benchmarking and characterization protocols, highlighted in Table <ref>. Depending on the protocol, we observe a reduction of classical time by 64% to 80% and a speedup of between 2.55× and 6.86×.

PCE can be applied to many different classes of circuits, and the examples shown here are only representative of typical workflows in QCVV. However, many classes of — for example variational circuits <cit.> — are parameterizable, and future work could explore other applications that could benefit from PCE. Additionally, calibrating quantum gates often requires sweeping a pulse definition over many different pulse parameters, and adapting PCE to gate calibration could lead to significant time savings in processor bring-up. Finally, we believe that PCE is an important example of how classical control hardware can be utilized to reduce the overhead in quantum workflows, and, in addition to related co-designed protocols developed for  <cit.>, we plan to explore more ways in which classical resources can be utilized to improve the efficiency of quantum computations.



  
*
The majority of this work was supported by the Laboratory Directed Research and Development Program of Lawrence Berkeley National Laboratory under U.S. Department of Energy Contract No. DE-AC02-05CH11231. Y.X., I.S., and G.H. acknowledge financial support for the primary development of the  hardware from the U.S. Department of Energy, Office of Science, Office of Advanced Scientific Computing Research Quantum Testbed Program under Contract No. DE-AC02-05CH11231 and the Quantum Testbed Pathfinder Program.



  
*
A.D.R. designed the RIP and Stitch method and performed the experiments. A.D.R. and A.H. performed the data analysis.  N.F., Y.X., and G.H. developed the classical control hardware  used in this work. J.H. assisted in the design and analysis of the GST data. A.D.R. and A.H. wrote the manuscript with input from all coauthors. I.S., K.K., and K.N. supervised all work.



  
*
The hardware-assisted parameterized circuit execution presented in this work is protected under the U.S. patent application no. 63/651,049 (patent pending), filed by Lawrence Berkeley National Laboratory on behalf of the following inventors: A.D.R., N.F., A.H., K.N., G.H., Y.X., and I.S.




  
*
All data are available from the corresponding author upon reasonable request.











§ EXPERIMENT PARAMETERS


Below are the experiment parameters used for profiling in Sections <ref> and <ref>. Each circuit uses a delay of 500ns per shot to ensure starting at the ground state (passive reset).



 §.§ Randomized Compiling - RC 20


    
        
  * depths : [1, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100]
        
  * widths : [(0,1), (0,1,2), (0,1,2,3), (0,1,2,3,4),
        
   (0,1,2,3,4,5),  (0,1,2,3,4,5,6), (0,1,2,3,4,5,6,7)]
        
  * randomization per depth and width : 20
        
  * Total number of circuits : 
        
   randomization*depth*width 20*11*7 = 1540
        
  * shots per depth and width : 
        
   50 per randomization = 50×20 = 1000
    


 §.§  RC Fully Randomly Compiled - RC FRC



    
  * depths : [1, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100]
    
  * widths : [(0,1), (0,1,2), (0,1,2,3), (0,1,2,3,4), 
    
   (0,1,2,3,4,5), (0,1,2,3,4,5,6), (0,1,2,3,4,5,6,7)]
    
  * randomization per depth and width : 1000
    
  * Total number of circuits
    
   randomization*depth*width = 1000*11*7 = 7700
    
  * shots per depth and width 
    
   1 per randomization = 1×1000 = 1000




 §.§ Cycle Benchmarking - CB



    
  * widths : [(0,1), (0,1,2,3), (0,1,2,3,4,5), 
    
   (0,1,2,3,4,5,6,7)]
    
  * randomization : [[4, 16, 64], [4, 8, 32], [2, 4, 8], 
    
   [2, 4, 8]]
    
  * number of circuits per width : [540, 660, 960, 1080]
    
  * Total number of circuits : 540+640+960+1080 = 3240
    
  * shots per circuit : 100
    
  





 §.§ Randomized Benchmarking - RB




    
  * widths : [(0),(0,1), (0,1,2), (0,1,2,3), (0,1,2,3,4), 
    
   (0,1,2,3,4,5), (0,1,2,3,4,5,6), (0,1,2,3,4,5,6,7)]
    
  * randomization : [(16,128,384), (16,96,384), 
    
   (16,64,256), (16,64,192), (8,64,192), (8,32,160),  
    
   (4,32,160), (4,32,128)]
    
  * number of circuits per width : 
    
   (randomization * number of circuit per randomization) + read circuits = 3×30 + 2 = 90 + 2 = 92
    
  * Total number of circuits : circuit per width * width = 92*8 = 736
    
  * shots per circuit : 100



 §.§ Gate Set Tomography - GST



    
  * depths : [2, 4, 8, 16, 32, 64, 128]
    
  * widths : [(0,1)]
    
  * Total number of circuits : 19488
    
  * shots per circuit : 1000


