Patent Description:
<CIT> discloses a method of testing a variable digital delay line that comprises multiple taps.

Methods and systems are provided for syncing multiple FPGA ports in a quantum system, as set forth in the claims.

Classical computers operate by storing information in the form of binary digits ("bits") and processing those bits via binary logic gates. At any given time, each bit takes on only one of two discrete values: <NUM> (or "off") and <NUM> (or "on"). The logical operations performed by the binary logic gates are defined by Boolean algebra and circuit behavior is governed by classical physics. In a modern classical system, the circuits for storing the bits and realizing the logical operations are usually made from electrical wires that can carry two different voltages, representing the <NUM> and <NUM> of the bit, and transistor-based logic gates that perform the Boolean logic operations.

Logical operations in classical computers are performed on fixed states. For example, at time <NUM> a bit is in a first state, at time <NUM> a logic operation is applied to the bit, and at time <NUM> the bit is in a second state as determined by the state at time <NUM> and the logic operation. The state of a bit is typically stored as a voltage (e.g., <NUM> Vdc for a "<NUM>" or <NUM> Vdc for a "<NUM>"). The logic operation typically comprises of one or more transistors.

Obviously, a classical computer with a single bit and single logic gate is of limited use, which is why modern classical computers with even modest computation power contain billions of bits and transistors. That is to say, classical computers that can solve increasingly complex problems inevitably require increasingly large numbers of bits and transistors and/or increasingly long amounts of time for carrying out the algorithms. There are, however, some problems which would require an infeasibly large number of transistors and/or infeasibly long amount of time to arrive at a solution. Such problems are referred to as intractable.

Quantum computers operate by storing information in the form of quantum bits ("qubits") and processing those qubits via quantum gates. Unlike a bit which can only be in one state (either <NUM> or <NUM>) at any given time, a qubit can be in a superposition of the two states at the same time. More precisely, a quantum bit is a system whose state lives in a two dimensional Hilbert space and is therefore described as a linear combination α|<NUM>〉 + β|<NUM>〉, where |<NUM>) and |<NUM>) are two basis states, and α and β are complex numbers, usually called probability amplitudes, which satisfy |α|<NUM> + |β|<NUM> = <NUM>. Using this notation, when the qubit is measured, it will be <NUM> with probability |α|<NUM> and will be <NUM> with probability |β|<NUM>. The basis states |<NUM>〉 and |<NUM>) can also be represented by two-dimensional basis vectors <MAT> and <MAT>, respectively. The qubit state may represented by <MAT>. The operations performed by the quantum gates are defined by linear algebra over Hilbert space and circuit behavior is governed by quantum physics. This extra richness in the mathematical behavior of qubits and the operations on them, enables quantum computers to solve some problems much faster than classical computers. In fact, some problems that are intractable for classical computers may become trivial for quantum computers.

Unlike a classical bit, a qubit cannot be stored as a single voltage value on a wire. Instead, a qubit is physically realized using a two-level quantum mechanical system. For example, at time <NUM> a qubit is described as <MAT>, at time <NUM> a logic operation is applied to the qubit, and at time <NUM> the qubit is described as <MAT>. Many physical implementations of qubits have been proposed and developed over the years. Some examples of qubits implementations include superconducting circuits, spin qubits, and trapped ions.

<FIG> illustrates an example quantum system comprising multiple FPGA ports that are synced in accordance with various example implementations of this disclosure. The quantum system comprise a quantum programming subsystem (QPS) <NUM>, a quantum controller (QC) <NUM>, and a quantum processor <NUM>.

The QPS <NUM> is capable of generating a quantum algorithm description which configures the QC <NUM> and includes instructions the QC <NUM> can execute to carry out the quantum algorithm (i.e., generate the necessary outbound quantum control pulse(s)) with little or no human intervention during runtime. In an example implementation, the QPS <NUM> is a personal computer comprising a processor, memory, and other associated circuitry (e.g., an x86 or x64 chipset). The QPS <NUM> compiles the high-level quantum algorithm description to a machine code version of the quantum algorithm description (i.e., series of binary vectors that represent instructions that the QC <NUM> can interpret and execute directly).

The QPS <NUM> may be coupled to the QC <NUM> via an interconnect which may, for example, utilize a universal serial bus (USB), a peripheral component interconnect (PCle) bus, wired or wireless Ethernet, or any other suitable communication protocol.

The QC <NUM> comprises circuitry operable to load the machine code quantum algorithm description from the QPS <NUM> via the interconnect. Execution of the machine code by the QC <NUM> causes the QC <NUM> to generate the necessary outbound quantum control pulse(s) that correspond to the desired operations to be performed on the quantum processor <NUM> (e.g., sent to qubit(s) for manipulating a state of the qubit(s) or to readout resonator(s) for reading the state of the qubit(s), etc.). The machine code may also cause the QC <NUM> to perform an analysis on an input signal. The analysis result may be used to determine the state of the qubit or the quantum register (quantum measurement). Depending on the quantum algorithm to be performed, outbound pulse(s) for carrying out the algorithm may be predetermined at design time and/or may need to be determined during runtime. The runtime determination of the pulses may comprise performance of classical calculations and processing in the QC <NUM> during runtime of the algorithm (e.g., runtime analysis of inbound pulses received from the quantum processor).

A QC <NUM> generates the precise series of external signals, usually pulses of electromagnetic waves and pulses of base band voltage, to perform the desired logic operations (and thus carry out the desired quantum algorithm).

During runtime and/or upon completion of a quantum algorithm performed by the QC <NUM>, the QC <NUM> may output data/results to the QPS <NUM>. In an example implementation these results may be used to generate a new quantum algorithm description for a subsequent run of the quantum algorithm and/or update the quantum algorithm description during runtime. Additionally, the QC <NUM> may output the raw or processed inbound pulses received from the quantum processor <NUM>, representing qubits state estimation, or metadata representing the quantum program control flow and branching information, as well as internal variables computations during the program execution.

A QC <NUM> comprises a plurality of pulse processors, which may be implemented in a field programmable gate array (FPGA), an application specific integrated circuit or the like. A pulse processor is operable to control analog outbound pulses that drive a quantum element (e.g., one or more qubits and/or resonators) or allow interaction between quantum elements and digital outbound pulses that can control auxiliary equipment required for the program execution (e.g., gating the analog outbound pulses or controlling external devices like photon detectors).

Quantum algorithms are performed in the quantum processor <NUM> when one or more qubits interact with quantum control pulses. These quantum control pulses are electromagnetic RF signals or pulses that are generated digitally at baseband in the QC <NUM>, converted to an analog waveform via a plurality of DACs <NUM>-<NUM>, <NUM>-<NUM>, <NUM>-<NUM> and <NUM>-<NUM>, and upconverted by an RF circuit <NUM>. The desired signals may generated according to a known set of instructions, involving various operations such as arithmetical or logical calculations, communication with various components and classical control flow operations (jump, branch, etc.). An application layer (APP) in the QC <NUM> controls a physical layer (PHY) to digitally generate (and further modify) samples of this analog waveform. Inbound pulses are also received by the QC <NUM>, from the quantum processor <NUM>, via the RF circuit <NUM> and a plurality of ADCs <NUM>-<NUM> and <NUM>-<NUM>.

A qubit may have a life in the range of hundreds of microseconds, causing a very low program execution runtime. Also, in data centers where a quantum computer is acting as a co-accelerator for specific computations there may be thousands of programs that are queuing to use the designated quantum processor <NUM>.

As the process, voltage and temperature (PVT) changes, a periodic recalibration may be in order. Therefore, a fast, robust and independent approach to recalibration may facilitate a much better usage of the quantum computer while minimizing dead time between programs.

<FIG> illustrates an example system for training a quantum system to sync multiple FPGA ports in accordance with various example implementations of this disclosure.

The quantum controller <NUM> in <FIG> may comprise a PCB <NUM>-<NUM> and an FPGA <NUM>-<NUM>. FPGA <NUM>-<NUM> may have numerous ports <NUM>-<NUM> and <NUM>-<NUM> which need to be synced to one another. Furthermore, the PCB <NUM>-<NUM> and FPGA <NUM>-<NUM> may have design variations <NUM>-<NUM> and <NUM>-<NUM>, respectively, such that transmission via ports <NUM>-<NUM> and <NUM>-<NUM> of FPGA <NUM>-<NUM> may not be aligned with transmission via ports <NUM>-<NUM> and <NUM>-<NUM> of FPGA <NUM>-<NUM>. Synchronization is required for the outputs, driven from FPGA <NUM>-<NUM> or <NUM>-<NUM>, to arrive at all DACs <NUM>-<NUM> and <NUM>-<NUM> simultaneously and independently, without skews regardless of the design variations between similar system components. Any delay or misalignment of one of the signals that are being output from the FPGA <NUM>-<NUM> or <NUM>-<NUM> can drastically impair the reliability of the quantum computer.

The hardware path from the FPGA <NUM>-<NUM> to the ports <NUM>-<NUM> and <NUM>-<NUM> may change because of variants in FPGAs <NUM>-<NUM> (e.g., same PCB <NUM>-<NUM> revision, but an FPGA <NUM>-<NUM> from a different batch). The various characteristics of the FPGA <NUM>-<NUM> can influence the time that it takes the signal to arrive at a DAC <NUM>-<NUM> and <NUM>-<NUM> and ruin the sync that was calibrated for a different PCB <NUM>. For the purpose of training this machine learning model, several FPGA designs <NUM>-<NUM> and <NUM>-<NUM>, each with a different layout, as well as several quantum control units with different PCBs <NUM>-<NUM> and <NUM>-<NUM> are used for training.

Syncing ports <NUM>-<NUM> and <NUM>-<NUM> in the FPGA <NUM>-<NUM> and/or <NUM>-<NUM> incorporates delay lines <NUM>-<NUM> and <NUM>-<NUM> for each port <NUM>-<NUM> and <NUM>-<NUM>. This allows the signal driven from the FPGA <NUM>-<NUM> and/or <NUM>-<NUM> to be programmatically and digitally "shifted," in constant and discrete steps such that all signals are aligned at their destinations as required by the quantum control application.

A machine learning approach is disclosed for syncing all quantum FPGA ports <NUM>-<NUM> and <NUM>-<NUM>, without having to save, load and maintain previously acquired data per quantum control unit (i.e., without using external storage). The machine learning approach also eliminates the need for long and repetitive calibrations on the quantum control platform, along with eliminating the need to calibrate using external input/output devices.

To train the machine learning model, information from different PCBs <NUM>-<NUM> and/or <NUM>-<NUM> and different FPGA logic designs <NUM>-<NUM> and/or <NUM>-<NUM> is collected per port <NUM>-<NUM> and <NUM>-<NUM>. Training is required only once.

Test signals may be generated by generator <NUM>-<NUM> and <NUM>-<NUM>. The test signals may be sinusoidal signals or any other signals with a deterministic phase. For each PCB <NUM>-<NUM> or <NUM>-<NUM>, per FPGA design <NUM>-<NUM> or <NUM>-<NUM>, the span of possible delays (<NUM> to N) are programmed in the delay lines <NUM>-<NUM> and <NUM>-<NUM>. The phase of the test signal at each DAC <NUM>-<NUM> and <NUM>-<NUM> is measured. This provides the information of which tap/delay is required for each port <NUM>-<NUM> and <NUM>-<NUM>. Test signals at the DACs <NUM>-<NUM> and <NUM>-<NUM> are synchronized when they have the same phase. A formula for determining the tap/delay, as a function of a port's setup and hold time, may be derived from the measured phase values using linear regression. Alternatively, a nonlinear equation for determining the tap/delay may be derived to account for delay lines that are non- linear.

<FIG> illustrates a flowchart of an example method for syncing multiple FPGA ports in accordance with various example implementations of this disclosure.

Each of the FPGA logic designs is characterized by setup-and-hold (S/H) times which also serves as part of the input to the training phase. At <NUM>, the S/H times are determined for each port of an FPGA. The FPGA ports may be asynchronous.

A test signal is generated. At <NUM>, the test signal is sent, via each of the FPGA ports, to a destination. The destination may be a DAC. Each FPGA port is coupled to a multi-tap delay line. Each of the plurality of multi-tap delay lines is initiated by setting a tap (i.e., a selectable delay).

At <NUM>, a phase of the test signal, as received at the destination from every port, is measured. For example, if each of <NUM> ports sends a sinusoidal test signal to each of <NUM> DACs, the test signals, received at each DAC, are processed to determine the phase values.

At <NUM>, it is determined whether all taps have been used. If more taps are available, at <NUM>, the next tap is chosen, the test signal is resent at <NUM> and the phase values of the test signal, as received at the destination from every port, is measured at <NUM>.

Once each tap/delay is chosen and the data collection stage is done, an application is operable, at <NUM>, to select an ideal tap/delay, from the plurality of phase values, for each of the plurality of ports. The ideal tap/delay for every ports will correspond to the same phase.

At <NUM>, it is determined whether more PCBs are available for training. If more PCBs are available, at <NUM>, a new PCB is used, the tap/delay is reinitialized for each delay line, the test signal is resent at <NUM> and the phase values of the test signal, as received at the destination from every port, is measured at <NUM>.

At <NUM>, it is determined whether more FPGAs are available for training. If more FPGAs are available, at <NUM>, a new FPGA is used, the tap/delay is reinitialized for each delay line, the test signal is resent at <NUM> and the phase values of the test signal, as received at the destination from every port, is measured at <NUM>.

<FIG> illustrates an example graph of phase values measured over a range of delays in accordance with various example implementations of this disclosure.

The horizontal axis is the delay-line value (i.e., the amount of time units the test signal is delayed). The vertical axis is the measured phase. A graph like this can be generated for each port.

As illustrated, the tap setting in each delay line may be from <NUM> to <NUM>. This range is an example, as any range may be used. Ideally, each tap would correspond to an exact delay. For example, a range of <NUM> to <NUM> nsec with a <NUM> psec resolution. However, an exact delay is sometimes not possible, and a linear relationship between time and taps is not a requirement for this method.

As illustrated, the test signal is a sinusoidal wave, although any test signal with a deterministic phase may be used. The ideal tap/delay is selected as <NUM>, as <NUM> corresponds to center of a period of constant phase. The selected ideal tap, for a particular port of the plurality of asynchronous ports, may, therefore, be determined according to a point halfway between <NUM> phase changes. In other embodiments, the test signal may comprises a pulse. For a test signal pulse, the selected ideal tap, may be based on a phase transition (i.e., on to off or vice versa).

Turning back now to <FIG>, at <NUM>, a tap estimate function is generated according to the selected/ideal taps, as well as a setup-and-hold time, for each of the plurality of ports.

<FIG> illustrates an example tap/delay estimate function as a linear fit to the ideal phase values (as discussed regarding <FIG>) for different ports having different setup-and-hold times in accordance with various example implementations of this disclosure.

Using linear regression on the training data, coefficients a and b may be determined such that the following function fits the collected data: <MAT> where S/H is the setup-and-hold time of a port (this can change per FPGA logic design), and Delay is the required delay for the port, such that all ports in a specific PCB are synchronized.

This machine learning approach may determine an optimal delay for different logic designs, different PVT, different batches of FPGA chips. This optimal delay may achieved without repeated calibration using external wiring and persistent storage.

The present method and/or system may be realized in hardware, software, or a combination of hardware and software. A typical implementation may comprise one or more application specific integrated circuit (ASIC), one or more field programmable gate array (FPGA), and/or one or more processor (e.g., x86, x64, ARM, PIC, and/or any other suitable processor architecture) and associated supporting circuitry (e.g., storage, DRAM, FLASH, bus interface circuits, etc.). Each discrete ASIC, FPGA, Processor, or other circuit may be referred to as "chip," and multiple such circuits may be referred to as a "chipset. " Another implementation may comprise a non-transitory machine-readable (e.g., computer readable) medium (e.g., FLASH drive, optical disk, magnetic storage disk, or the like) having stored thereon one or more lines of code that, when executed by a machine, cause the machine to perform processes as described in this disclosure. Another implementation may comprise a non-transitory machine-readable (e.g., computer readable) medium (e.g., FLASH drive, optical disk, magnetic storage disk, or the like) having stored thereon one or more lines of code that, when executed by a machine, cause the machine to be configured (e.g., to load software and/or firmware into its circuits) to operate as a system described in this disclosure.

As used herein the terms "circuits" and "circuitry" refer to physical electronic components (i.e. hardware) and any software and/or firmware ("code") which may configure the hardware, be executed by the hardware, and or otherwise be associated with the hardware. As used herein, "and/or" means any one or more of the items in the list joined by "and/or". As used herein, the term "exemplary" means serving as a non-limiting example, instance, or illustration. As used herein, the terms "e.g.," and "for example" set off lists of one or more non-limiting examples, instances, or illustrations. As used herein, circuitry is "operable" to perform a function whenever the circuitry comprises the necessary hardware and code (if any is necessary) to perform the function, regardless of whether performance of the function is disabled or not enabled (e.g., by a user-configurable setting, factory trim, etc.). As used herein, the term "based on" means "based at least in part on. " For example, "x based on y" means that "x" is based at least in part on "y" (and may also be based on z, for example).

Claim 1:
A method comprising:
setting a tap, of a plurality of taps, for each of a plurality of multi-tap delay lines;
sending (<NUM>) a test signal, via each of a plurality of asynchronous ports, to a destination, wherein each of the plurality of asynchronous ports is operably coupled to a multi-tap delay line of the plurality of multi-tap delay lines;
measuring (<NUM>) a phase of the test signal at the destination corresponding to each of the plurality of asynchronous ports;
repeating (<NUM>) the phase measurement after setting each tap of the plurality of taps;
selecting (<NUM>) one tap, for each of the plurality of asynchronous ports, according to the phase measurements for each of the plurality of asynchronous ports; and
generating (<NUM>) a tap estimate function according to the selected taps for the plurality of asynchronous ports.