Adjoint data compression for quantum computing devices

Abstract

A quantum computing device includes at least one quantum register including a plurality of logical qubits. A compression engine is coupled to each of the plurality of logical qubits. Each compression engine is configured to compress companion data. A decompression engine is coupled to each compression engine. Each decompression engine is configured to receive compressed companion data, decompress the received compressed companion data, and route the decompressed companion data to a decoder block.

Description

Background Art

[0001] Qubits are prone to high error rates and thus benefit from active error correction. Quantum error correction codes can be used to encode logical qubits into a collection of physical qubits. Errors can then be detected using measurements and corrected using an error decoder. Qubits are typically operated at very low temperatures and data is transmitted to the error decoder at a higher operating temperature. Summary of the invention

[0002] This summary is provided to introduce a selection of concepts further described below in the detailed description in a simplified form. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to implementations that address any or all of the disadvantages mentioned in any part of this disclosure.

[0003] A quantum computing device includes at least one quantum register, the at least one quantum register including a plurality of logical qubits. A compression engine is coupled to each of the plurality of logical qubits. Each compression engine is configured to compress concomitant data. A decompression engine is coupled to each compression engine. Each decompression engine is configured to receive compressed concomitant data, decompress the received compressed concomitant data, and route the decompressed concomitant data to a decoder block. This reduces bandwidth overhead and supports high-throughput transmission of concomitant data from a quantum register. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] Figure 1 An example of a quantum computing organization is schematically shown.

[0005] Figure 2 Aspects of an example quantum computer are schematically illustrated.

[0006] Figure 3 Illustration of a Bloch sphere, which graphically represents the quantum state of a quantum bit in a quantum computer.

[0007] Figure 4 Schematically illustrated are logical qubits in a lattice with alternating data qubits and parity qubits.

[0008] Figure 5 Two consecutive rounds of concomitant measurements are schematically shown.

[0009] Figure 6 is a graph indicating the memory capacity required to store accompanying measurement data under varying conditions.

[0010] Figure 7 An example compression scheme is schematically shown.

[0011] Figure 8 Schematically illustrated are multiple regions on a surface code lattice for geometry-based compression.

[0012] Fig. 9 An example method for compressing adjoint data within a quantum computing device is shown.

[0013] Fig.10 An example method for compressing adjoint data within a quantum computing device using a geometry-based compressor is shown.

[0014] Fig.11 An example decoder design is schematically shown.

[0015] Fig.12 An example decoder is schematically shown.

[0016] Fig.13 An example graph generator module is schematically illustrated.

[0017] Fig.14 The states of the main components in the graph generator module during graph generation are schematically shown.

[0018] Fig.15 Example cluster and root table entries are schematically shown.

[0019] Fig.16 A depth-first search engine and an example graph for error correction are schematically shown.

[0020] Fig.17 An example of peeling performed in the correction engine for an example error map is shown.

[0021] Fig.18 An example method for implementing a pipelined version of a hardware parallel-check decoder is shown.

[0022] Fig.19 A baseline organization of L logical qubits is schematically shown.

[0023] Fig. 20 shows an example design of a decoder module.

[0024] Fig.21 An example microarchitecture for a scalable, fault-tolerant quantum computer is schematically illustrated.

[0025] Fig. 22 An example method for routing concomitant data within a quantum computing device is shown.

[0026] Fig.23 The Monte Carlo simulator framework is schematically shown.

[0027] Fig.24 is a graph indicating the mean compression ratio for different error rates across code lengths.

[0028] Fig.25 is a graph indicating the average cluster diameter for different error rates and code distances of logical qubits.

[0029] Fig.26 is a graph indicating the total memory capacity required to implement the spanning tree memory.

[0030] Fig. 27 is a graph indicating the distribution of the number of edges in a cluster for a fixed code distance and physical error rate.

[0031] Fig.28 is a graph showing the average number of edges in a cluster for different code distances and error rates.

[0032] Fig.29 is a graph indicating the correlation between the graph generator module and the execution time in the depth-first search engine.

[0033] Fig.30 is a graph indicating the distribution of execution time for decoding a 3D picture.

[0034] Fig.31 A schematic diagram of an example classical computing device is shown. DETAILED DESCRIPTION

[0035] Qubits, the basic unit of information in a quantum computer, are prone to high error rates. To support fault-tolerant quantum computing, active error correction can be applied to these qubits. Quantum error correction codes (QECC) encode logical qubits using redundant data and parity qubits. Error correction is performed through a process called error decoding, which diagnoses errors on data qubits by analyzing measurements on parity qubits. Currently, most decoding methods target qubit errors at the algorithmic level and do not take into account the underlying device technology that will be used to design them.

[0036] In this paper, the architectural challenges involved in designing these decoders are targeted, and a 3-stage pipeline microarchitecture for hardware implementation of a checksum decoder is described. An error correction algorithm is designed to be suitable for hardware implementation. The feasibility of data compression for different noise regimes is evaluated with respect to the amount of storage and bandwidth required for the implementation. An architecture is disclosed that scales the proposed decoder design for a large number of logical qubits and supports practical fault-tolerant quantum computing. Such a design can reduce the total cost of each of the three pipeline stages by 2x, 4x, and 4x, respectively, through resource sharing across multiple logical qubits, without compromising decoder correctness and error threshold. As an example, for a code distance of 11 and 10 -3The physical error rate is of the order of magnitude, and the logical error rate is 10 -8 .

[0037] Quantum computing uses quantum mechanical properties to support calculations for specific applications, and on conventional (i.e., non-quantum) state-of-the-art computers, it is not feasible to perform such applications in a reasonable amount of time. Example applications include prime factorization, database search, physical and chemical simulations. The basic unit of calculation on a quantum computer is a qubit. Qubits inevitably interact with the environment and lose their quantum states. Imperfect quantum gate operations exacerbate the problem, because quantum gates are unitary transformations selected from continuous possible values, which cannot be achieved with perfect accuracy. In order to protect quantum states from noise, QECC has been developed. In any QECC, logical qubits are encoded with several physical qubits to support fault-tolerant quantum computing. Fault tolerance generates resource overhead (usually 20-100x per logical qubit) and is actually not feasible on currently available small prototypes. However, in order to run useful applications on fault-tolerant quantum computers, quantum error correction is considered to be very valuable, if not completely necessary.

[0038] QECC differs from classical error correction techniques such as triple mode redundancy (TMR) or single error correction and double error detection (SECDED). These differences stem from the fundamental nature of quantum bits and the high error rate (typically in the order of 10 -2 For example, qubits cannot be copied (no cloning theorem) and lose their quantum state when measured. QECC uses redundant qubits to create a coding space by using ancillary qubits that interact with the data qubits. By measuring the ancillary qubits, errors on the data qubits can be detected and corrected using a decoder.

[0039] The error decoding algorithm specifies how the syndrome (the result of the auxiliary measurement) will be processed to detect errors in the encoded block of data qubits. The design and performance of the decoder depends on the decoding algorithm, QECC, physical error rate, noise model, and implementation technology. For practical purposes, the decoder must process the syndrome measurement faster than the rate at which errors occur. They must also take into account specific technical constraints for working in cryogenic environments and scaling to large numbers of qubits.

[0040] Perfect error decoding is NP-hard (non-deterministic polynomial-time) with exponential time complexity. Therefore, the optimal decoding algorithm trades off error correction capability for reduced time complexity. Although decoders are groundbreaking for fault-tolerant quantum computing, most decoding techniques have only been studied at the algorithmic level and have not considered the underlying implementation techniques. Other approaches such as lookup table-based decoders or deep neural decoders are not scalable to a large number of qubits. The Union-Find decoder algorithm is simple and its time complexity is nearly linear, making it a suitable candidate for scalable fault-tolerant quantum computing. Here, a microarchitecture for hardware implementation of a Union-Find decoder is disclosed, in which the algorithm is redesigned to reduce hardware complexity and allow expansion to a large number of logical qubits.

[0041] To support faster processing and reduce transmission delays, the decoder is designed to operate at a temperature very close to that of the physical qubits (77K or 4K), rather than at room temperature (300K). Figure 1 An example quantum computing system 100 indicating a temperature gradient 105 is shown in FIG. The quantum computing system 100 includes one or more qubit registers 110 operating at 20 mK, a decoder 115 and a controller 120 that typically operate at 4 K or 77 K, and a host computing device 125 and an end-user computing device 130 that operate at 300 K (room temperature). Depending on whether the decoder 115 operates at 77 K or 4 K, the underlying implementation techniques and design constraints provide different trade-offs. Superconducting logic designs at 4 K are very close to physical qubits and have significant energy efficiency, but are limited by device density and memory capacity. Conventional CMOS operating at 77 K can drive complex designs for applications with larger memory footprints, but it is less energy efficient than superconducting logic and incurs data transfer overhead in moving data back and forth from physical qubits that reside at 15-20 mK.

[0042] In this paper, a microarchitecture for the hardware implementation of a checksum decoder is disclosed. Implementation challenges associated with memory capacity and bandwidth for cryogenic operation are discussed. Surface codes are used as examples for underlying QECC and various noise models, although other implementations have been considered. Surface codes are promising QECC candidates that arrange a set of qubits in a 2-dimensional layout with alternating data qubits and auxiliary qubits. Any error in a data qubit may be detected by its neighboring auxiliary qubits, thus requiring only nearest neighbor connections. The feasibility and scalability of such a design for large-scale fault-tolerant quantum computers are described.

[0043] Here, systems and methods are disclosed to solve many problems in the field of quantum computing. For example, the design of QEC decoders is analyzed, including their placement in the thermal domain and design complexity. A microarchitecture for the hardware implementation of a checksum decoder is proposed, which proves that it is more practical to operate the decoder at 77K.

[0044] The memory capacity required to store the adjoint measurements is calculated and it is shown that storing them in superconducting memories at 4K may not be feasible. However, transferring the data to 77K requires a large bandwidth. To overcome these two challenges, techniques that can be used to compress the adjoint measurement data are proposed. The implementation of dynamic zero compression and sparse representation is described. In addition, a geometry-based compression scheme is proposed that takes into account the underlying structure of the surface code lattice. In addition, the compression scheme and its applicability are described for different noise mechanisms.

[0045] The join-check decoder algorithm is refined to reduce hardware cost and for improved implementation in enhanced noise models. The original join-check decoder algorithm only considers gate errors on data qubits that are paired in space. The hardware microarchitecture described in this paper also considers measurement errors that are paired in time and decodes them using several rounds of adjoint measurements.

[0046] In addition, a hardware system architecture is described to scale these decoders for large numbers of logical qubits. Such an implementation can take into account differences in the utilization of pipeline stages in individual decoding units and support optimized resource sharing between multiple logical qubits to reduce hardware cost.

[0047] A qubit is the basic unit of information on a quantum computer. The foundation of quantum computing relies on two quantum mechanical properties: superposition and entanglement. A qubit can be represented as a linear combination of its two ground states. If the ground states are |0> and |1>, then the qubit |ψ> can be represented as |ψ>=α|0>+β|1>, where And |α| 2 +|β| 2 =1. When the amplitude or / and phase of the probability amplitude α, β changes, the state of the quantum bit changes. For example, an amplitude flip (or, a bit flip) changes the state of |ψ> to β|0>+α|1>. Alternatively, a phase flip changes its state to α|0>-β|1>. Quantum instructions use quantum gate operations to modify the probability amplitude, and quantum gate operations are represented using the identity matrix (I) and the Pauli matrix. The Pauli matrices X, Z, and Y represent the effects of a bit flip, a phase flip, or both, respectively.

[0048] In some embodiments, the methods and processes described herein may be associated with a quantum computing system of one or more quantum computing devices. Figure 2Aspects of an example quantum computer 210 configured to run quantum logic operations are shown (see below). Conventional computer memory stores digital data in a bit array and performs bit-by-bit logic operations, while a quantum computer stores data in a qubit array and performs quantum mechanical operations on the qubits in order to achieve the desired logic. Accordingly, Figure 2 The quantum computer 210 includes at least one register 212 including a qubit array 214. The illustrated register is eight qubits in length; registers including longer and shorter qubit arrays are also contemplated, as are quantum computers including two or more registers of arbitrary lengths.

[0049] The qubits of register 212 may take various forms depending on the desired architecture of quantum computer 210. As non-limiting examples, each qubit 214 may include: a superconducting Josephson junction, a trapped ion, a trapped atom coupled to a high-fineness cavity, an atom or molecule confined within a fullerene, an ion or neutral doped atom confined within a host lattice, a quantum dot presenting a discrete spatial state or spin electronic state, an electron hole in a semiconductor junction entrained via an electrostatic trap, a coupled quantum wire pair, an atomic nucleus accessible by magnetic resonance, a free electron in helium, a molecular magnet, or a metalloid carbon nanosphere. More generally, each qubit 214 may include any particle or particle system that is capable of existing in two or more discrete quantum states that can be measured and manipulated experimentally. For example, a qubit may also be implemented in multiple processing states corresponding to different light propagation modes through linear optical elements (e.g., mirrors, beam splitters, and phase shifters), as well as in states accumulated within a Bose-Einstein condensate.

[0050] Figure 3 is an illustration of a Bloch sphere 216 that provides a graphical description of some quantum mechanical aspects of each qubit 214. In this description, the north and south poles of the Bloch sphere correspond to the standard basis vectors |0> and |1>, respectively—for example, the spin-up and spin-down states of an electron or other fermion. The set of points on the surface of the Bloch sphere includes all possible pure states of the qubit |ψ>, while the points on the interior correspond to all possible mixed states. Mixed states for a given qubit may be caused by decoherence, which may occur due to undesired coupling with external degrees of freedom.

[0051] Now back to Figure 2, the quantum computer 210 includes a controller 218. The controller may include conventional electronic components, including at least one processor 220 and an associated storage machine 222. The term "conventional" is applied herein to any component that can be modeled as a collection of particles, without regard to the quantum state of any individual particle. For example, conventional electronic components include integrated micro-engraved transistors, resistors, and capacitors. The storage machine 222 may be configured to store program instructions 224 that cause the processor 220 to perform any of the processes described herein. Additional aspects of the controller 218 are described below.

[0052] The controller 218 of the quantum computer 210 is configured to receive a plurality of inputs 226 and provide a plurality of outputs 228. The inputs and outputs may each include digital and / or analog lines. At least some of the inputs and outputs may be data lines through which data is provided to and extracted from the quantum computer. Other inputs may include control lines through which the operation of the quantum computer may be regulated or otherwise controlled.

[0053] The controller 218 is operably coupled to the register 212 via an interface 230. The interface is configured to exchange data bidirectionally with the controller. The interface is also configured to exchange signals corresponding to the data bidirectionally with the register. Depending on the architecture of the quantum computer 210, such signals may include electrical signals, magnetic signals, and / or optical signals. Via the signal transmitted through the interface, the controller can query or otherwise affect the quantum state stored in the register, as defined by the collective quantum state of the quantum bit array 214. To this end, the interface includes at least one modulator 232 and at least one demodulator 234, each modulator and each demodulator being operably coupled to one or more quantum bits of the register 212. Each modulator is configured to output a signal to the register based on the modulated data received from the controller. Each demodulator is configured to sense a signal from the register and output data to the controller based on the signal. In some scenarios, the data received from the demodulator may be an estimate of an observable value of a measurement of a quantum state stored in the register.

[0054] More specifically, a suitably configured signal from the modulator 232 can physically interact with one or more qubits 214 of the register 212 to trigger a measurement of the quantum state held in the one or more qubits. The demodulator 234 can then sense the resulting signal released by the one or more qubits in response to the measurement, and can provide data corresponding to the resulting signal to the controller. In other words, the demodulator can be configured to reveal an estimate of an observable value reflecting the quantum state of one or more qubits of the register based on the received signal, and provide the estimate to the controller 218. In one non-limiting example, the modulator can provide an appropriate voltage pulse or pulse sequence to the electrodes of the one or more qubits based on the data from the controller to initiate the measurement. In short, the demodulator can sense the photon emission from the one or more qubits, and can assert a corresponding digital voltage level on the interface line entering the controller. In general, any measurement of a quantum mechanical state is performed by an operator corresponding to the observable value to be measured. defined; the measured result R is guaranteed to be permissible In quantum computer 210, R is statistically related to the register state before measurement, but is not uniquely determined by the register state.

[0055] Based on appropriate input from controller 218, interface 230 may also be configured to implement one or more quantum logic gates to operate on the quantum states stored in register 212. The function of each logic gate of a conventional computer system is described according to a corresponding truth table, while the function of each quantum gate is described by a corresponding operator matrix. The operator matrix operates (i.e., multiplies) the complex vector representing the register state and implements a specific rotation of the vector in Hilbert space.

[0056] continue Figure 2 , a suitably configured signal from modulator 232 of interface 230 can physically interact with one or more qubits 214 of register 212 to assert any desired quantum gate operation. As described above, the desired quantum gate operation is a specifically defined rotation of the complex vector representing the register state. To achieve the desired rotation One or more modulators of interface 230 may be configured to provide a predetermined duration T i Apply a predetermined signal level S i .

[0057] In some examples, multiple signal levels can be applied to multiple sequences or other associated durations. In more specific examples, multiple signal levels and durations are arranged to form a composite signal waveform that can be applied to one or more qubits of a register. Typically, each signal level Si and each duration T i is a control parameter adjustable by appropriate programming of the controller 218. In other quantum computing architectures, different sets of adjustable control parameters may control the quantum operations applied to the register states.

[0058] Qubits inevitably lose their quantum states through interactions with different degrees of freedom around them. Even if qubits can be perfectly isolated from environmental noise, quantum gate operations are imperfect and cannot be applied with precise accuracy. This imposes various limitations on running any application on a quantum computer. Therefore, the quantum states manipulated by a quantum computer must be corrected using quantum error correction codes (QECC). QECC encodes logical qubits into a collection of physical qubits so that the error rate of the logical qubits is lower than the physical error rate. As long as the physical error rate is below an acceptable threshold, QECC can support fault-tolerant quantum computing at the expense of an increase in the number of physical qubits. In recent years, several error correction protocols have been proposed. In this paper, surface codes are applied, which are considered to be the most promising QECC for fault-tolerant quantum computing. QEC models arbitrary noise as a superposition of quantum operations. Therefore, QECC uses Pauli matrices to capture the effects of errors as bit flips, phase flips, or a combination of both.

[0059] Surface codes are widely considered suitable for scalable, fault-tolerant quantum computing. They encode logical qubits in a lattice with alternating data qubits and parity qubits. Figure 4 A schematic representation of such a lattice is shown at 400 of , which has a 2D distance-3 (d=3) surface code. Each X stabilizer 402 and Y stabilizer 404 is coupled to its neighboring data qubit 406. Each data qubit 406 interacts only with its nearest neighbor parity qubit 408, so that by measuring the locally supported operator, errors on the data qubit 406 can be diagnosed, as shown at 410. In this example, a Z error 412 on data qubit A 414 is captured by parity qubits P0 416 and P1 418. Similarly, an X error 420 on data qubit B 422 is captured by parity qubits P2 424 and P3 426. In the simplest implementation, the surface code for distance d uses a (2d-1) 2 The code length is 1000 physical qubits to store a single logical qubit, where d is a measure of redundancy and fault tolerance. A larger code length leads to greater redundancy and increased fault tolerance.

[0060] The logical operators consist of a string of single-qubit operators between two opposite sides. The encoding space is the space of all stabilizer generators (e.g. Figure 4) has a subspace with +1 eigenvalues. By construction, the logic state is invariant under the application of the stabilizer generator. Any closed loop to which the Pauli operator is applied will leave the logic state unchanged. The measurement of the stabilizer generator detects the endpoints of a series of errors. Error correction is based on this information, and the stabilizer measurement is called an adjoint.

[0061] In QEC, the effects of errors are reversed by applying the appropriate Pauli gates. For example, if a qubit experiences a bit-flip error, a Pauli X-gate is applied to flip it back to the expected state. It has been shown previously that as long as Clifford gates are applied to the qubits, there is no need to perform active error correction. Instead, it is sufficient to keep track of the Pauli frames in software. Therefore, the main focus of quantum error correction is error decoding, not error correction. Optimal error decoding is a computationally difficult problem. A quantum error decoder takes as input an adjoint measurement and returns an estimate of the error in the data qubit. In addition to the ability to detect errors, the decoder also relies on a high speed of operation to prevent the accumulation of errors. In other words, errors must be detected faster than they occur.

[0062] Since error decoding must be fast, the decoder must provide high performance and operate close to the physical qubits. Figure 1 As described above, qubits typically operate at 15-20mK. Depending on whether the decoder is designed to operate at 4K or 77K, the implementation technology provides different trade-offs, as shown in Table 1. Due to the proximity to physical qubits, hardware designed to operate at 4K must meet strict power requirements. This is to ensure that thermal noise is controlled. In addition, these designs must be cooled using complex and expensive liquid helium coolers. The decoder can be designed using CMOS or superconducting logic at 4K. CMOS has power consumption and cannot be used for large-scale quantum computers. Superconducting logic provides low power consumption, but there are major disadvantages, such as limited device density and low storage capacity, which makes it extremely difficult to manufacture complex and large designs. Traditional CMOS operating at 77K provides the ability to design complex systems with larger memory and power budgets. The cooling overhead associated with 77K is an order of magnitude lower than that of 4K. However, decoders designed to operate at 77K must consider transmission delays and meet the bandwidth required to transmit data back and forth between 4K and 77K. The trade-offs between superconducting technology at 4K and CMOS at 77k are listed in Table 1.

[0063] parameter Superconducting Technology Traditional CMOS Operating temperature 4K 77K Operating frequency 10GHz 4GHz Memory capacity 123-512 bytes 4GB Power Budget 1W N / A Feature size 248nm 7-16nm Cooling costs 1000x / 400x 10x

[0064] Table 1

[0065] In this paper, the challenges in designing the microarchitecture of a decoder for quantum error correction under a realistic noise model are examined. Qubit errors can be roughly divided into three types: decoherence errors, gate errors, and measurement errors. Qubits only maintain their quantum states for a short duration (called the decoherence time), resulting in decoherence errors. Non-ideal gate operations lead to gate errors on qubits. Imperfections in qubit measurements lead to measurement errors. The decoder may misinterpret the adjoint measurement errors as data qubit errors and correct non-erroneous data qubits, thereby introducing errors. The decoder must take such adjoint measurement errors into account while decoding the errors. This directly affects the microarchitecture and design choices of the decoder.

[0066] Figure 5 A diagram 500 is shown indicating two consecutive rounds of adjoint measurements 502 and 504, and showing how measurement errors 506 are paired in time and data qubit errors 508 are paired in space. Diagram 500 shows that if the decoder only checks the measurement results of round 0 502, it will misinterpret the error on the parity qubit P0 510 and force a correction on the error-free D0 512. Current decoders account for adjoint measurement errors by checking d rounds of measurements, where d is the code distance. The data generated by d rounds of adjoint measurements and the error log for each data qubit must be stored for the decoder to work correctly. This requires up to several megabytes of storage space (depending on the code distance and the number of logical qubits).

[0067] Figure 6 An example graph 600 is shown indicating the memory capacity (in KB) required to store d (code distance) rounds of adjoint measurement data and error logs for N logical qubits. The required capacity is much higher than the available memory in superconducting logic at 4K. In order to perform error decoding at 77K, the measurement data must be transferred from 4K to 77K. For a given qubit plane with L logical qubits and each qubit encoded using a surface code with a code distance of d, 2d(d-1)L bits must be sent at the end of each adjoint measurement cycle. Assuming a reasonable number of logical qubits and code distances, a 4K-77K link requires a bandwidth range of the order of several Gb / s. Data transmission at a lower bandwidth reduces the remaining effective time for error decoding, since it must provide an estimate of the error within d adjoint measurement cycles (e.g., a surface code cycle can be decomposed into d adjoint measurement cycles). Therefore, the main challenge in designing any decoder at 77K is that the required bandwidth is very large.

[0068] One way to efficiently handle capacity and bandwidth requirements in cache and main memory is data compression. The sparsity of the measured data can be analyzed and estimated as described in this article. For example, let p be the probability of Z errors on a data qubit, and let u be the indicator vector of errors for n data qubits (note that the same analysis also applies to X adjoints). If there are 4 data qubits and the first two have Z errors, then u = 1100. Assuming identical and independent error distributions (iid), the upper limit of the Hamming weight of the adjoint is given by equation (1), where |u| is the Hamming weight of the error indicator vector u (e.g., the number of 1s).

[0069]

[0070] Therefore, the probability that there are m or more errors is given by Equation 2:

[0071]

[0072] Using union-bound, with the total number of bits s(Z u ) is given by Equation 3.

[0073] s(Z u )≤2|u| (Equation 3)

[0074] Assume the code distance is 11 and the error rate is 10 -3 , the probability of having 10 or more errors (a fairly large number for a given code length) is 6.2x10 -14 . Therefore, the probability of observing a companion with a large Hamming weight is extremely low. This analysis shows that it is possible to compress the companion data to reduce the storage overhead of storage and / or to meet bandwidth requirements. Different compression techniques for companion data are described in this article, this is because the usefulness of the compression technique depends on the entropy of the data. In this article, three compression techniques are described, although other techniques have been considered. Different noise mechanisms to which these techniques can be applied are analyzed. The examples described each have a compression scheme that uses a simple encoding and does not require large hardware complexity.

[0075] Dynamic Zero Compression (DZC) was originally introduced to reduce the energy required for cache accesses of zero-valued bytes. Similar techniques can be employed to compress accompanying data. Figure 7An example is shown at 700 of . The companion 705 of length L is grouped into K blocks of W bits each, where W is the compression width 710. If the number of bits of the last block is less than W bits, additional padding zeros can be added. A K-bit wide zero indicator bit (ZIB) vector 715 includes 1 bit per block. If all bits of the i-th block are 0, the corresponding bit in the ZIB (ZIB[i]) can be set to 1. Otherwise, the bit can be set to 0. The data to be transmitted 720 can be obtained by appending a non-zero block 725 at the end of the ZIB vector.

[0076] As shown at 750, the sparse representation can be considered similar to the traditional technique of storing sparse matrices, in which the non-zero elements of the sparse matrix 760 are stored by storing only the row and column indices 765. Sparse representation bits (SRBs) 755 are used to indicate whether all companion bits are zero. If there are one or more non-zero bits in the companion, the SRBs may not be set, and the index 755 of the non-zero element may be sent together with the SRB in the transmitted data 775.

[0077] Geometry-based compression (Geo-Comp) can be considered as an adaptation of DZC that also takes into account the geometry of the surface code lattice. Geometry-based compression schemes can compress the X-companion and Z-companion regions together, rather than compressing the X-companion and Z-companion separately. The entire surface code lattice can be divided into multiple regions, where each region contains approximately an equal number of companion bits (similar to the compression width of DZC). Figure 8 A surface code lattice 800 for geometry-based compression comprising a plurality of regions ( 801 , 802 , 803 , 804 ; indicated by dashed lines) is schematically shown. Figure 8 An example of how a surface code lattice with a code length of 5 can be partitioned into 4 regions is shown. Using ZIBs for each region and transmitting only the adjoint data from the non-zero regions can compress the adjoints. When a Y error occurs on the data qubit, the X and Z adjoint bits flip to indicate the error. When the two types of adjoints are compressed independently, the total number of non-zero blocks is higher for a given compression width. For example, if Figure 8 The data qubit D0 810 shown in FIG. 8 encounters a Y error, then the X companion bits X0 811 and X1 812 and the Z companion bits Z0 813 and Z1 814 flip. In a compression scheme such as DZC, (X0 811, X1 812) and (Z0 813, Z1 814) are located on different data blocks and are compressed separately. However, if the geometry of the lattice is considered, the non-zero companion bits are usually located in the same region unless the data qubit is on a region boundary (e.g., D1 815 in lattice 800).

[0078] In general, for a given noise model, the number and size of regions can be adjusted by calculating the expected number of blocks containing trivial companions (all zeros). However, larger sized regions lead to complex hardware by increasing the logic depth. Therefore, smaller region sizes (depending on the code distance) can be analyzed even for very low error rates. The regions need not be equal in size, and the size and / or number of regions can be determined based on the expected number of data blocks containing trivial companions.

[0079] Fig. 9 An example method 900 for compressing companion data within a quantum computing device is shown. In some examples, the method 900 can be implemented by hardware including a check decoder (e.g., Fig.12 A quantum computing device implementation of a decoder (schematically depicted in FIG. 4 ).

[0080] At 910, method 900 includes generating adjoint data from at least one quantum register including l logical qubits, where l is a positive integer. The generated adjoint data may include at least X adjoint data and Z adjoint data.

[0081] At 920, method 900 includes, for each logical qubit: routing the generated adjoint data to a compression engine, the compression engine being configured to compress the adjoint data. The quantum computing device may include multiple compression engines. In some examples, at least one compression engine is configured to compress the adjoint data using dynamic zero compression. In some examples, at least one compression engine is configured to compress the adjoint data using a sparse representation. In some examples, at least one compression engine is configured to compress the adjoint data using geometry-based compression. The quantum computing device may include two or more logical qubit sectors coupled to two or more types of compression engines. In some examples, method 900 may include operating the compression engine at 4K. However, higher (e.g., 8K) or lower (e.g., 2K) temperatures may be used.

[0082] Continuing at 930, method 900 includes routing the compressed companion data to a decompression engine, the decompression engine being configured to: receive the compressed companion data; and decompress the received compressed companion data. At 940, method 900 includes routing the decompressed companion data to a decoder block. In some examples, the decompressed companion data may be routed to a graph generator module of the decoder block. In some examples, method 900 may include operating the decompression engine and / or the decoder block at 77K. However, higher (e.g., 85K) or lower (e.g., 70K) temperatures may be used. In some examples, the quantum computing device includes a set of d decoder blocks, where d < 2*l.

[0083] Fig.10 An example method 1000 for compressing companion data using geometry-based compression within a quantum computing device is shown. In some examples, the method 1000 can be implemented by hardware including a checksum decoder (e.g., Fig.12 A quantum computing device implementation of a decoder (schematically depicted in FIG. 4 ).

[0084] At 1010, method 1000 includes generating adjoint data from at least one surface code lattice including l logical qubits, where l is a positive integer, for example, the surface code lattice is partitioned into two or more regions based on lattice geometry, such as Figure 8 In some examples, the number of regions can be determined based on the expected number of data blocks containing trivial companions.

[0085] At 1020, method 1000 includes, for each logical qubit: routing the generated adjoint data to a compression engine configured to compress the adjoint data using geometry-based compression. At 1030, method 1000 includes compressing the adjoint data using a zero indicator bit for each of two or more regions of the surface code lattice. At 1040, method 1000 includes transmitting the adjoint data only from non-zero regions. In other words, it can be assumed that if no data is received from a region, the region includes only trivial (e.g., all zero) data.

[0086] At 1050, method 1000 includes routing the compressed companion data to a decompression engine configured to: receive the compressed companion data; and decompress the received compressed companion data. The decompression engine may be programmed based on the geometry-based compression scheme used by the compression engine.

[0087] The decoder of the QEC is used to process the adjoint measurement data and identify errors that corrupt the data qubits. In this paper, the microarchitecture of the hardware implementation of the check decoder for surface codes is improved. In surface codes, local operators on the lattice of qubits are measured and processed with the decoder to generate an estimate of the most likely error on the data qubit. The decoder microarchitecture is designed to prevent the accumulation of errors while keeping the hardware complexity low to meet the strict power budget of operation in cryogenic environments. The architecture proposed in this paper is designed to support expansion to thousands of logical qubits to support fault-tolerant quantum computing.

[0088] Quantum error decoding is an NP-hard problem. Therefore, most decoding algorithms trade off between error threshold and low time and algorithmic complexity. A promising error decoding technique is the graph-based minimum weight perfect matching (MWPM) decoder. Although the MWPM decoder offers a high error threshold, it suffers from a high time complexity (O(n 2 )). Alternatively, a simple approach to designing a decoder is based on the use of a lookup table. The table is indexed by the adjoint bit and the corresponding entry stores the error information of the data qubit. However, lookup table decoders are not scalable and require terabytes of memory even for small code distances. Deep neural decoders are popular and learn a probability density function of possible errors corresponding to the measured adjoint sequence during the training phase. Using inference, the error pattern for a given adjoint is evaluated. However, neural decoders require more hardware for computation and are not scalable when the code distance increases. The recently proposed union-check decoder proposes an algorithm that forms clusters around non-trivial adjoints (non-zero adjoints) and performs error correction in almost linear time using graph traversal. The union-check decoder thus offers simplicity, time complexity, and a high error threshold.

[0089] And check the operation of the decoder as follows Fig.11 As shown in . At 1100, each edge on the graph 1102 represents a data qubit, and each vertex represents an even or odd qubit (e.g., 1104, 1106). Decoding begins by growing a spanning forest 1108 to cover all error-companion bits, thereby forming one or more even clusters, as shown at 1110. Data qubits A 1112 and B 1114 can be assigned unknown Pauli errors 1116 and 1118, respectively. By traversing the forest, errors can be detected, as shown at 1120. The cluster traversal steps (shown at 1122, 1124) can be used to detect, classify (e.g., Z errors), and correct errors.

[0090] like Fig.12 As shown in the block diagram 1200 of , an adaptation of the algorithm can be implemented. The compressed companion data 1210 is routed to the decompression engine 1215. The decompressed companion data 1220 is then routed to the graph generator (Gr-Gen) module 1225. The Gr-Gen module 1225 can be configured to generate spanning tree memory (STM) data. The depth-first search engine (DFS) 1230 can be configured to access the STM data and generate an edge stack based on the STM data. The correction (Corr) engine 1235 can be configured to access the edge stack, generate a memory request based on the accessed edge stack, and update the error log 1240.

[0091] If the adjoint measurement errors are ignored, decoding is performed using a 2D graph generated from a single round of adjoint measurements. In order to take into account erroneous measurements, d rounds of consecutive adjoint measurements must be decoded together, where d is the code distance, resulting in a 3D graph. A parallel-check decoder can be used for both cases. The main difference is that the amount of memory required grows quadratically (for 2D) or cubically (for 3D) with the code distance of the surface code. For simplicity, the microarchitecture of the parallel-check decoder is described in 2D and generalized to 3D. All relevant results described are obtained for the 3D graph. The decoding design includes 3 pipeline stages, supporting improved design expansion.

[0092] The Gr-Gen module takes the adjoint as input after decompression and generates a spanning forest by growing clusters around non-trivial adjoint bits (non-zero adjoint bits). A spanning forest can be constructed using two basic graph operations: Union() and Find(). Fig.13 An example Gr-Gen module 1300 is schematically shown. Module 1300 includes a spanning tree memory (STM) 1310, a zero data register (ZDR) 1315, a root table 1320, a size table 1325, a parity register 1330, and a fused edge stack 1335. This design is slightly different from the previously described parallel-check algorithm to reduce hardware resource costs. The size of each component is a function of the code distance d. STM 1310 stores 1 bit for each vertex and 2 bits for each edge. Each edge uses 2 bits because according to the original algorithm, clusters grow half the edge width around vertices or existing cluster boundaries. ZDR 1315 stores 1 bit per STM row. If the content of the row is 0, the bit stores 0, and if at least one bit in the row is 1, the ZDR bit of the corresponding row stores 1. Since the accompanying data is sparse and the total number of edges in the spanning forest will be low, ZDR 1315 speeds up the STM 1310 traversal. The FES 1335 stores newly grown edges so that they can be added to existing clusters. The root table 1320 and the size table 1325 store the root and size of the cluster, respectively. The tree traversal registers 1340 store the vertices of each cluster accessed in the Find() operation. The interface 1345 between the Gr-Gen module and the DFS engine can allow the DFS engine to access the data stored at the STM 1310.

[0093] like Fig.14As shown in , the root table entry (roottable[i]) is initialized to index (i). As shown at 1400, the size table entry for the non-trivial companion bit is initialized to 1. These tables help the Union() and Find() operations to merge clusters into a final state as shown at 1420 after the growing phase as shown at 1410. They are indexed by the cluster index. The table size is set for the maximum possible number of clusters, which is equal to the total number of vertices in the surface code lattice. A boundary list can be stored for each cluster. However, in noise regimes relevant to practical applications, the average cluster diameter is very small. The cluster diameter can be defined as the maximum distance between two vertices on the cluster boundary. Therefore, instead of storing the boundary list, the boundary index can be calculated during the cluster growing phase. The original algorithm grows all odd clusters until the parity is even. Therefore, odd clusters must be detected quickly. To do this, a parity register can be used, such as Fig.11 The parity register can store 1 bit of parity per cluster, depending on whether it is odd or even. For a reasonable code distance of 11, seven 32-bit registers may be sufficient. For larger code distances, additional parity information can be stored in memory and read in advance to hide memory delays.

[0094] The control logic can read the parity register and grow the cluster with odd parity by writing STM, ZDR and adding the newly added edges that touch the borders of other clusters to FES (called the growing phase). The STM may not be updated for edges connecting to other clusters to prevent double growth. It can be updated when clusters are merged by reading from FES. The logic can check whether the newly added edge connects two clusters by reading the root table entries of the vertices connected by the edge (these are called primary vertices). This is equivalent to the Find() operation. Fig.15 As shown at 1500 in , the vertices visited on the path to find the root of each primary vertex are stored in the tree traversal registers. As shown at 1510, the root table entries of these vertices can be updated to point directly to the root of the cluster to minimize the depth of the tree for future traversals. This operation (called path compression) is included in the union-find algorithm and allows the depth of the tree to be kept short, thereby amortizing the cost of the Find() operation. For example, at 1500, Fig.15 The state of the two clusters and the root table at a certain moment in time is shown. Assume that after the growing step, vertices 0 and 6 are connected and the two clusters must be merged. The tree traversal registers can be used to update the root of vertex 0, as shown at 1500. Since the depth of the tree is continuously compressed, only a few registers are sufficient. In one example, 5 registers are used per primary vertex, although more or fewer registers may be used. If the primary vertices belong to different clusters, the root of the smaller cluster can be updated to point to the root of the larger cluster.

[0095] The DFS engine can process the STM data generated by Gr-Gen, which stores a collection of growing even clusters. It can use the DFS algorithm to generate an edge list that forms a spanning tree for each cluster in the STM. In other examples, a breadth-first search can be used to explore, although DFS is generally more memory-efficient. Fig.16 An example DFS engine is shown at 1600 of FIG. The logic may be implemented using a finite state machine 1610 and two stacks 1620 and 1622. The stacks may be used because the order in which edges are visited in the spanning tree may be reversed to perform corrections by peeling. The edge stack 1620 may store a list of visited edges, while the pending edge stack 1622 may store edges that will be visited later in the ongoing DFS. For example, Fig.16 As shown at 1630 of , when the FSM visits vertex 1 of the spanning tree, edge a is pushed to the edge stack and edge c is pushed to the pending edge stack. When the end of the current path is reached, the pending edge can be popped and traversed. In order to support pipelining and improve performance, the microarchitecture can be designed to include an alternative edge stack 1632. When there is more than one cluster, the correction engine can work on the edge list of another cluster being traversed when the DFS engine traverses one cluster via the Corr engine interface 1640. As shown at 1630, if edges a, b, c, and d belong to cluster C0, and edges e and f belong to cluster C1, the DFS engine 1600 can traverse C1 when the Corr engine processes the correction of C0. This can help to set the size of the stack to handle the average cluster size, rather than the worst-case cluster size. In the event that the DFS engine 1600 encounters a cluster that is large enough to fit in one stack, an alternate stack 1632 may be used, and an overflow bit may be set to indicate that stacks 1620 and 1632 hold edges corresponding to a single cluster. This proposed implementation may include a number of memory reads proportional to the size of the cluster. By checking the STM 1310 row by row, the effective cost of generating the cluster is reduced. The ZDR 1315 reduces the cost of traversing the STM 1310 row by row.

[0096] The Corr engine can perform the stripping process of the decoder and can identify the Pauli correction to be applied. The Corr engine can access the edge list (which is stored on the stack) and the companion bits corresponding to the vertices along the edge list. The companion bits can be accessed by decompressing the compressed companion and / or by accessing the STM. However, the former may increase logic complexity and latency, while the latter may increase the number of memory requests that the STM needs to handle. In order to reduce memory traffic and eliminate the need for additional decompression logic, the companion information can be stored by the DFS engine along with the edge index information. The temporary companion changes caused by stripping are stored in local registers. An example of stripping of an example error graph performed in the Corr engine is shown in FIG. Fig.17 as shown in . Fig.17 An example of step 1 1700, step 2 1710, and step 3 1720 are shown with examples of saved registers, error logs, edge stacks, and error graphs. The Corr engine can also read the last surface code cycle error log and can update the Pauli correction of the current edge. For example, if the error on edge e0 was Z in the previous logic cycle, and it also encounters a Z error in the current cycle, the Pauli error of e0 can be updated to I, as shown at 1720.

[0097] Fig.18 An example decoding method 1800 for a quantum computing device is shown. In some examples, the decoding method 1800 can be implemented by hardware including a check decoder (such as, Fig.12 A quantum computing device implementation of a decoder (schematically depicted in FIG. 4 ).

[0098] At 1805, method 1800 includes receiving companion data from one or more qubits of a plurality of qubits, such as logical qubits residing in a quantum register. The received companion data may include X companion data and / or Z companion data.

[0099] At 1810, method 1800 includes decoding the received companion data using a hardware-implemented parallel-check decoder including two or more pipeline stages. As an example, this may include Fig.12 The hardware-implemented merge-lookup decoder shown in includes three pipeline stages: a graph generator module stage, a depth-first search engine stage, and a correction engine stage. However, any number or combination of two or more pipeline stages may be used.

[0100] Optionally, at 1820, decoding the companion data may include generating a spanning forest in the Gr-Gen module by growing clusters around non-trivial companion bits. In some examples, the spanning tree may be generated using Union() and Find() graph operations.

[0101] Optionally, decoding the companion data may include storing data about the spanning forest in a spanning tree memory (STM) and a zero data register at the Gr-Gen module at 1825. In some examples, the newly grown edges may be stored at a fused edge stack.

[0102] Optionally, at 1830, decoding the companion data may include accessing data stored in the STM at the DFS engine. Optionally, at 1835, decoding the companion data may include generating one or more edge stacks at the DFS engine based on the data stored in the STM. For example, Fig.16As shown in , generating one or more edge stacks based on data stored in the STM may include generating a primary edge stack, which includes a list of visited edges. Additionally or alternatively, generating one or more edge stacks based on data stored in the STM may include generating a pending edge stack, which includes a list of edges to be visited. Additionally or alternatively, generating one or more edge stacks based on data stored in the STM may include generating an alternative edge stack, which is configured to save the remaining edges from the clusters of the generated forest.

[0103] Optionally, at 1840, decoding the companion data may include accessing one or more generated edge stacks at the Corr engine. Optionally, at 1845, decoding the companion data may include generating a memory request at the Corr engine based on the accessed edge stacks. Optionally, at 1850, decoding the companion data may include performing iterative strip decoding at the Corr engine for each accessed edge stack. Optionally, at 1855, decoding the companion data may include updating an error log of the decoder at the Corr engine based on the results of the iterative strip decoding.

[0104] As discussed in this article, decoding based on a single round of measurement will not take into account the accompanying measurement errors. In order to cope with measurement errors, the decoder checks the d (code distance) round measurement. This type of error correction can be coped with with minimal changes to the design. For example, the decoder can analyze a 3D graph instead of forming a graph on a 2D plane. Each vertex can be connected to up to 4 neighbors. However, for a 3D graph, each vertex can now have up to two additional edges corresponding to the previous round of measurement and the next round of measurement. In order to reduce storage overhead, the STM of each round of accompanying measurement can be stored. The STM can be optimized so that each row of the STM stores the vertex of a row of the surface code lattice, the edge information of the vertex of the next row, and the edge information of the corresponding vertex in the surface code lattice connecting the next round.

[0105] The compression techniques described in this paper can reduce the amount of memory required to store the accompanying data and error logs of the data qubits. However, the microarchitecture of the parallel-check decoder also uses memory, and the total capacity required is far from that provided by superconducting memory. Therefore, the design can be implemented by operating at 77K using conventional CMOS. This can also reduce the thermal noise generated in the low temperature environment close to the quantum substrate, which is due to the fact that the design is physically far away from the quantum substrate.

[0106] For the baseline design, a naive implementation can assign a decoder to each X-companion and each Z-companion for each logical qubit, as Fig.19 As shown in 1900. Fig.19The system structure of a large number of logical qubits within a quantum register 1910 is schematically shown. Quantum register 1910 is shown to include logical qubit 0 1910a, logical qubit 1 1910b, and logical qubit 1 1910l as representative logical qubits operating at 15-20mK. Each logical qubit is configured to receive a signal from control logic 1915 and output accompanying data to a compression engine (e.g., 1920a, 1920b...1920l). Control logic 1915 and compression engines 1920a...1920l are shown to operate at a higher temperature of 4K than the quantum register. However, higher (e.g., 8K) or lower (e.g., 2K) temperatures may be used.

[0107] Each compression engine routes the compressed companion data to a decompression engine (1925a, 1925b ... 1925l) operating at 77K. The decompression engine decompresses the compressed companion data and routes the decompressed X companion data and Z companion data to a decoding block 1930. In this example, each decompression engine is coupled to a pair of pipelined parallel-check decoders (1935a, 1935b, 1935c, 1935d ... 1935k, 1935l) operating at 77K. Each parallel-check decoder analyzes the companion data received from the decompression engine and updates an error log 1940. Although shown as operating at 77K, the decompression engine and decoder may be operated using higher (e.g., 85K) or lower (e.g., 70K) temperatures, although the operating temperature of the decompression engine and decoder may generally be higher than the operating temperature of the compression engine.

[0108] Thus, for the baseline design, the decoding logic may use 2L parallel-check decoders per logical qubit. In this implementation, each logical qubit uses its own dedicated decoder. However, the utilization of each pipeline stage may be different. Therefore, the architecture shown at 1900 may not provide an optimal allocation of resources. For a large number of qubits, the on-chip components are not fully utilized and dissipate heat. Since the entire system operates at 77K, the increased power consumption increases the cost of cooling linearly.

[0109] In this way, an architecture of a decoder block including a reduced number of pipeline units can be used. Fig. 202000 shows an example design of such a decoder block. A qubit register 2005 comprising a plurality of logical qubits transmits accompanying data to a set of Gr-Gen modules. The group of Gr-Gen modules 2010 can share one or more DFS engines 2020, and the group of DFS engines 2020 can share one or more Corr engines 2030. The hardware overhead includes a first set of multiplexers 2035 coupling the group of Gr-Gen modules 2010 to one DFS engine 2020, and a second set of multiplexers 2040 coupling the group of DFS engines 2020 to one Corr engine 2030. Memory requests generated by the Corr engine 2030 can be routed to the correct memory location using a demultiplexer 2045. The selection logic 2050 can give priority to the first ready component, and round robin arbitration can be used to generate appropriate selection signals for the multiplexers 2035 and 2040. For example, if four Gr-Gen modules 2010 share a DFS engine 2020, and the second Gr-Gen module completes cluster formation earlier than the other modules, it can first access the corresponding DFS engine 2020. Therefore, the polling strategy ensures fairness while sharing resources.

[0110] exist Fig.21 2100 shows an example system architecture. The qubit register 2105 includes a plurality of logical qubits 2110 coupled to control logic 2115. Each logical qubit is coupled to a compression engine 2120, which in turn is coupled to a decompression engine 2125. The blocks of N logical qubits 2110 share a decoder block 2130, which updates an error log 2135 for each coupled logical qubit 2110. As described with respect to Fig.19 As described, the operating temperature can vary with the indicated temperatures of 4K and 77K. If N logical qubits share a decoder block 2130, then for a quantum register 2105 having L logical qubits 2110, the total number of decoder blocks 2130 required is L / N. The example microarchitecture uses L Gr-Gen modules, (a) L DFS engines, and (b) L Corr engines. Resource savings depend on parameters (a) and (b). The values ​​of (a) and (b) can be calculated to minimize the overall hardware cost. This can be framed as a constrained optimization problem.

[0111] One way to decode large-scale systems is to allocate a decoder for each logical qubit. However, this approach results in a linear growth in hardware and, therefore, in power costs. As a result, the design is not very efficient and inherently not scalable. Our design supports the reuse of specific design components to reduce the actual cost when the decoder block is scaled up for a large number of logical qubits.

[0112] Resources can be shared within a decoding unit and / or across decoding units. Considering the distribution of decoding time, it is unlikely that several very long companion vectors need to be decoded at the same time, so resources can be shared.

[0113] This sharing is independent of the decoder or decoding algorithm, including cases where the decoding algorithm has a runtime that depends on the adjoint, so some adjoints may be harder to decode or take longer to decode than others. For example, some machine learning based decoders do not rely on adjoints. A machine learning decoder may have multiple layers of a neural network. Once decoding is performed on one qubit on the first layer, the second qubit may use the first layer while the first qubit operates on the second layer of the network.

[0114] Fig. 22 An example method 2200 of a quantum computing device is shown. The method 2200 may be performed by a multiplexed quantum computing device such as, Fig. 20 and Fig.21 At 2205, method 2200 includes generating a companion from at least one quantum register including l logical qubits, where l is a positive integer. The generated companion may include an X companion and a Z companion. At 2210, method 2200 includes routing the generated companion to a set of d decoder blocks coupled to at least one quantum register, where d < 2*l. Fig. 20 and Fig.21 As described, this allows for scalability of quantum computing devices since fewer than two decoders are needed to cope with the processing of the X-adjoint and Z-adjoint for each logical qubit.

[0115] In some examples, each decoder block is configured to receive a decoding request from a set of n logical qubits, where n>1. In some examples, each decoder block includes g Gr-Gen modules, where 0<g≤l, and each Gr-Gen module is configured to generate spanning tree memory (STM) data based on the received companion. In some examples, each decoder block also includes α*l DFS engines, where 0<α<1. In some examples, two or more Gr-Gen modules are coupled to each DFS engine via a multiplexer in a first set of multiplexers.

[0116] Optionally, at 2215, method 2200 includes accessing STM data generated by two or more Gr-Gen modules at each DFS engine via a multiplexer in the first multiplexer set. Optionally, at 2220, method 2200 includes generating an edge stack based on the STM data at each DFS engine. In some examples, each decoder block also includes β*l Corr engines, where 0<β<1. In some examples, two or more DFS engines are coupled to each Corr engine via a multiplexer in the second multiplexer set.

[0117] Optionally, at 2225, the method 2200 includes accessing, at each Corr engine via a multiplexer in the second set of multiplexers, edge stacks generated by the two or more DFS engines. Optionally, at 2230, the method 2200 includes generating a memory request based on the accessed edge stack. Optionally, at 2235, the method 2200 includes routing the memory request generated by each Corr engine to a memory location via one or more demultiplexers. Optionally, at 2240, the method 2200 includes routing a return signal through each multiplexer in the first set of multiplexers and the second set of multiplexers based on round-robin arbitration.

[0118] Error correction succeeds when d rounds of adjoint measurements are decoded within one logic cycle (T), which limits the maximum delay that the decoder can tolerate. When the decoder cannot decode all adjoints within a logic cycle, the error may not be detected. This type of failure can be called a timeout failure. Since the decoder is not perfect and exhibits threshold behavior, there is also the possibility of logical errors occurring when the correction generated by the decoder changes the logical state of the qubit. Therefore, the failure of the decoder can be attributed to either a timeout failure or a logical error. In order to keep the error threshold the same and prevent the system failure rate from increasing, the probability of a timeout failure (p tof ) must be lower than the probability of a logical error (p log ), as shown in equation (4). For the optimal design, as long as p tof Small enough, resource sharing is possible.

[0119] p tof ≤p log (Equation 4)

[0120] Assume that N logical qubits with exactly the same error rate share k decoding units. The total execution time for decoding N logical qubits is given by equation (5):

[0121]

[0122] Among them, τ irepresents the execution time of decoding the i-th logical qubit. In this case, the probability of timeout failure p tof Equation (6) must be satisfied.

[0123]

[0124] The optimization goal is to minimize the number of decoding units k for a given number of logical qubits N, so that the constraint given by equation (4) is satisfied. tof The model can be built using execution time obtained from a simulator.

[0125] The decoder performance can be modeled by studying the number of reads. The write operations performed may be read-modify-write and the write-back may not be on the critical path. A latency of 4 cycles is assumed for memory access and a 4GHz clock frequency. The total number of memory requests in a given companion Gr-Gen is proportional to the cluster diameter (Di). However, it is proportional to the cluster size (Si) in the DFS engine and the Corr engine. Equations (7) and (8) give the execution time spent in a companion Gr-Gen (TGG), DFS engine (TDFS), and Corr engine (TCE) for a cluster with n clusters.

[0126]

[0127] τ DFS =τ CE =∑ i S i (Equation 8)

[0128] In the optimized design, each Gr-Gen unit is an X-companion and a Z-companion growth cluster. Two or more Gr-Gen units use one DFS engine module, and two or more DFS engines use one Corr engine. These numbers of units to be shared can be determined by the fraction of the total execution time spent in each pipeline stage.

[0129] Next, we discuss the simulation infrastructure used to make design choices in the decoder microarchitecture. This infrastructure supports the estimation of some key statistics of the union-check decoder and also supports the study of the performance of the compression techniques described in this paper.

[0130] Monte Carlo simulators are used to analyze the performance of different compression techniques and to obtain and view statistics on the performance of decoders. Fig.23 The Monte Carlo simulator 2300 is shown schematically. The different configurations span four different physical error rates, ten different code lengths, and four noise models, each simulated for one million trials. The error rate chosen is 10 -6 (most optimistic), 10 -4, 10 -3 and 10 -2 (most pessimistic). The simulator 2300 receives a code distance 2302, a noise model 2304, and a compression algorithm 2306. Based on the code distance 2302, the simulator 2300 generates a surface code lattice via a lattice generator 2308. Depending on the selected noise model 2304, the simulator injects errors on the data qubits of the surface code lattice via error injection 2310 and generates an output adjoint 2312. The output adjoint 2312 is then compressed via a compressor 2314 according to the input compression algorithm 2306 to generate a compressed adjoint 2316. The simulator 2300 then outputs a compression ratio. As a quality factor for determining the most suitable compression scheme, the compression ratio (determined by equation (9)) and the percentage of incompressible adjoints are used. The simulation is repeated one million times to calculate the average compression ratio and the percentage of incompressible adjoints.

[0131]

[0132] The simulator also runs and checks the decoding algorithm against companion 2312 via decoder 2318. Statistics generator 2320 then analyzes the distribution of cluster sizes, the average number of clusters on a given lattice, and the execution time spent in each pipeline stage of decoder 2318 by modeling the hardware. These statistics and performance numbers provide insights that aid in the microarchitectural design of the decoder hardware implementation and drive scalable design.

[0133] The performance of the decoder depends largely on the noise model of the underlying qubits. Therefore, four different error models are explored. Identical and independently distributed (iid) errors are assumed, and the depolarization noise model is selected as the most basic noise model. In the depolarization noise model, if the error rate is p, the probability of each physical qubit encountering an error is p, and the probability of remaining error-free is (1-p). In addition, in this error model, X, Y, and Z errors appear with equal probability p / 3 respectively. The other three noise models assume that the probabilities of X errors and Z errors are different, as shown in Table 2.

[0134]

[0135] Table 2

[0136] This paper discusses adjoint compression, a baseline parallel-check decoder design, and the results of scalability analysis. The baseline decoder and scalability analysis results are based on the d-round adjoint measurement described in this paper.

[0137] The performance of each compression scheme depends on the noise model. For the depolarized noise model, compression schemes like DZC and Geo-Comp provide better performance at low code distances depending on the error rate compared to sparse representation. For specific types of errors (such as P x =10P z and P x =100P z ) for noise models with relative bias, DZC performs better than Geo-Comp. For lower code lengths, even though the sparse representation provides a higher compression ratio, the percentage of incompressible adjoints is higher (up to 6%) for larger error rates. For noise models where the probability of one type of error is much larger than the other, better compression ratios are obtained by compressing the X and Z adjoints separately at the cost of greater hardware complexity. If only one type of compression can be used due to hardware constraints, DZC performs better for lower code lengths. Table 3 specifies different noise mechanisms and the appropriate compression scheme that works best in each mechanism. In general, the sparse representation performs better for most cases in mechanisms with low error rates.

[0138]

[0139] Table 3

[0140] Fig.24 A graph 2400 is shown showing the mean compression ratio of the X-companion of a depolarized noisy channel using a selected compression scheme for different physical error rates and noise mechanisms. The depolarized noisy channel is considered as a representative candidate scheme. Similar results are observed for the Z-companion.

[0141] The distribution of cluster diameters was determined from the simulations. As defined herein, the cluster diameter is the maximum distance between any two boundary vertices of a cluster. Fig.25 A graph 2500 is shown indicating the average cluster diameter for different error rates and code distances for logical qubits. The average cluster diameter is low. This result is used to eliminate the storage cost incurred in maintaining a list of boundaries for each cluster in hardware (i.e., the functionality used in the original union-check algorithm). This reduces the hardware cost of the Gr-Gen module. The probability that the cluster diameter will become smaller increases as the error rate decreases.

[0142] The Spanning Tree Memory (STM) used by the Gr-Gen module and the DFS engine accounts for most of the storage cost. Fig.26A graph 2600 is shown indicating the total memory capacity required for a spanning tree memory (STM) for a given code distance (d) and number of logical qubits (N). This is a 3D graph of the results shown constructed using d rounds of measurements. Graph 2600 shows that even for a large number of logical qubits (such as 1000), the total memory required to decode both the X companion and the Z companion is less than 10MB for very large code distances (d) and d rounds of measurements. If the decoder does not need to consider d rounds of measurements (assuming perfect measurements are possible in the future), the total memory capacity required will be reduced by a factor of d.

[0143] The maximum number of possible entries in the root table and size table is the total number of companion bits for d (code length) rounds of companion measurements (equal to 2d(d-1)). Each root table entry contains the log 2 2d 2 (d-1) bits are needed to uniquely identify the root. Similarly, the maximum feasible cluster size includes all companion bits. Therefore, for each logical qubit, the total size of the root table and the size table is 2d 2 (d-1)log 2 2d 2 (d-1) bits.

[0144] The size of the stack can be determined by analyzing the maximum number of edges within a cluster from a Monte Carlo simulation. The number of edges in a cluster follows a Poisson distribution. Fig. 27 The indication is shown for a code distance d=11 and a physical error rate p=10 -3 An example graph of such a distribution is shown in Figure 2700. Therefore, the stack size can be designed to be half the maximum number of edges. Fig.28 is a graph 2800 showing the average number of edges in a cluster for different code distances and error rates. Each stack stores two vertices (log 2 4d 2 (d-1) bits), growth direction (2 bits), and 1 bit companion. It is worth noting that each DFS engine includes 2 stacks for pipelining. If the size of the cluster is larger than each stack can hold, the overflow bit can be set and an alternate stack can be used if available.

[0145] Fig.29 A graph 2900 is shown indicating the correlation between Gr-Gen and execution time in the DFS engine. This means that more time is spent in the Gr-Gen unit during decoding. As described herein, this data is used to select the number of resources to be shared within a decoder block. Fig.30 The indication is shown for a code distance (d) of 11 and an error rate (p) of 0.5x10 -3 A single decoder block (e.g., Fig. 20The shaded area indicates events that may increase the probability of timeout failures. In the case of resource sharing, the probability of timeout failure p tof The logical error rate is lower than 10 -8 For L logical qubits, the number of Gr-Gen modules, DFS engines, and Corr engines used in this architecture are L, L / 2, and L / 2, respectively. Therefore, the total number of Gr-Gen modules, DFS engines, and Corr engines are reduced by 2x, 4x, and 4x, respectively.

[0146] Error correction is an integral part of classical computing associated with quantum computers. Error decoding algorithms are designed to obtain higher error correction capabilities (thresholds). In this article, a hardware-implemented microarchitecture of a parallel-check decoder is disclosed, which uses CMOS working at 77K. Adjoint compression is feasible to meet the bandwidth requirements of 4K–77K links. Different compression schemes perform differently under different noise mechanisms, where sparse data representations generally perform better for lower error rates and larger code distances. The disclosed microarchitecture is designed to remember that the decoder needs to be extended to several thousand logical qubits. The architecture includes three pipeline stages and is tuned for high performance, high throughput, and low hardware complexity. The design can be extended for a larger number of logical qubits for practical fault-tolerant quantum computing. The time spent in each pipeline stage is different, so that the utilization of each stage is also different. By considering this, an architecture that relies on resource sharing across multiple logical qubits is disclosed. Such resource sharing is supported so that the logical error rate is not affected, and the system failure rate caused by the inability to decode errors due to lack of decoding resources is minimized.

[0147] In some embodiments, the methods and processes described herein may be associated with a computing system of one or more computing devices. Specifically, such methods and processes may be implemented as computer applications or services, application programming interfaces (APIs), libraries, and / or other computer program products.

[0148] Fig.31 A non-limiting embodiment of a computing system 3100 is schematically shown, and the computing system 3100 can implement one or more of the above methods and processes. The computing system 3100 is shown in simplified form. The computing system 3100 can embody the above-described and Figure 1 The computing system 3100 may take the form of one or more personal computers, server computers, tablet computers, home entertainment computers, network computing devices, gaming devices, mobile computing devices, mobile communication devices (e.g., smart phones), and / or other computing devices, as well as wearable computing devices (such as smart watches and head-mounted augmented reality devices).

[0149] The computing system 3100 includes a logic processor 3102, a volatile memory 3104, and a non-volatile storage device 3106. The computing system 3100 may optionally include a display subsystem 3108, an input subsystem 3110, a communication subsystem 3112, and / or Fig.31 Other components not shown.

[0150] Logical processor 3102 includes one or more physical devices configured to execute instructions. For example, a logical processor may be configured to execute instructions that are part of one or more applications, programs, routines, libraries, objects, components, data structures, or other logical constructs. Such instructions may be implemented to perform tasks, implement data types, convert the state of one or more components, obtain technical effects, or otherwise achieve desired results.

[0151] The logical processor may include one or more physical processors (hardware) configured to execute software instructions. Additionally or alternatively, the logical processor may include one or more hardware logic circuits or firmware devices configured to execute hardware-implemented logic or firmware instructions. The processor of the logical processor 3102 may be single-core or multi-core, and the instructions executed thereon may be configured for sequential, parallel and / or distributed processing. Optionally, the various components of the logical processor may be distributed among two or more separate devices, which may be located at a distance and / or configured for collaborative processing. The aspects of the logical processor may be virtualized and executed by a remotely accessible networked computing device configured with a cloud computing configuration. In this case, it is understood that these virtualized aspects are run on different physical logical processors of various different machines.

[0152] The non-volatile storage device 3106 includes one or more physical devices configured to store instructions executable by a logical processor to implement the methods and processes described herein. When implementing such methods and processes, the state of the non-volatile storage device 3106 can be converted - for example, to store different data.

[0153] The non-volatile storage device 3106 may include a removable and / or built-in physical device. The non-volatile storage device 3106 may include an optical memory (e.g., CD, DVD, HD-DVD, Blu-ray disc, etc.), a semiconductor memory (e.g., ROM, EPROM, EEPROM, flash memory, etc.), and / or a magnetic memory (e.g., a hard disk drive, a floppy disk drive, a tape drive, MRAM, etc.) or other mass storage device technology. The non-volatile storage device 3106 may include a non-volatile, dynamic, static, read / write, read-only, sequential access, location accessible, file accessible, and / or content accessible device. It will be understood that the non-volatile storage device 3106 is configured to save instructions even when the non-volatile storage device 3106 is powered off.

[0154] Volatile memory 3104 may include a physical device that includes random access memory. Logical processor 3102 typically utilizes volatile memory 3104 to temporarily store information during software instruction processing. It will be understood that when volatile memory 3104 is powered off, volatile memory 3104 typically does not continue to store instructions.

[0155] Aspects of the logic processor 3102, volatile memory 3104, and non-volatile storage device 3106 may be integrated together into one or more hardware logic components. For example, such hardware logic components may include field programmable gate arrays (FPGAs), program and application specific integrated circuits (PASIC / ASIC), program and application specific standard products (PSSP / ASSP), systems on chips (SOCs), and complex programmable logic devices (CPLDs).

[0156] When included, the display subsystem 3108 can be used to present a visual representation of the data stored by the non-volatile storage device 3106. The visual representation can take the form of a graphical user interface (GUI). Since the methods and processes described herein change the data stored by the non-volatile storage device, thereby transforming the state of the non-volatile storage device, the state of the display subsystem 3108 can also be transformed to visually represent the changes in the underlying data. The display subsystem 3108 can include one or more display devices utilizing almost any type of technology. Such a display device can be combined with a logical processor 3102, a volatile memory 3104, and / or a non-volatile storage device 3106 in a shared shell, or such a display device can be a peripheral display device.

[0157] When included, the input subsystem 3110 may include one or more user input devices (such as a keyboard, mouse, touch screen, or game controller), or interface with a user input device. In some embodiments, the input subsystem may include selected natural user input (NUI) components, or interface with selected NUI components. Such components may be integrated or peripheral, and the conversion and / or processing of input actions may be handled on or off the system. Example NUI components may include microphones for speech and / or voice recognition; infrared, color, stereo, and / or depth cameras for machine vision and / or gesture recognition; head trackers, eye trackers, accelerometers, and / or gyroscopes for motion detection and / or intent recognition; and electric field sensing components for assessing brain activity; and / or any other suitable sensors.

[0158] When included, the communication subsystem 3112 can be configured to communicatively couple the various computing devices described herein to each other and to communicatively couple to other devices. The communication subsystem 3112 can include wired and / or wireless communication devices compatible with one or more different communication protocols. As a non-limiting example, the communication subsystem can be configured to communicate via a wireless telephone network, or a wired or wireless local area network or a wide area network (such as HDMI on a Wi-Fi connection). In some embodiments, the communication subsystem can allow the computing system 3100 to send messages to other devices and / or receive messages from other devices via a network such as the Internet.

[0159] In one example, a quantum computing device includes: at least one quantum register including a plurality of logical qubits; a compression engine coupled to each of the plurality of logical qubits, each compression engine configured to compress companion data; and a decompression engine coupled to each compression engine, each decompression engine configured to: receive compressed companion data; decompress the received compressed companion data; and route the decompressed companion data to a decoder block. In such an example or any other example, at least one compression engine is additionally or alternatively configured to compress the companion data using dynamic zero compression. In any of the foregoing examples or any other examples, at least one compression engine is additionally or alternatively configured to compress the companion data using a sparse representation. In any of the foregoing examples or any other examples, at least one compression engine is additionally or alternatively configured to compress the companion data using geometry-based compression. In any of the foregoing examples or any other examples, the plurality of logical qubits are additionally or alternatively divided into two or more sectors, wherein a first sector of the one or more sectors is coupled to a first type of compression engine configured to compress the companion data using a first type of compression, and a second sector of the one or more sectors is coupled to a second type of compression engine configured to compress the companion data using a second type of compression. In any of the foregoing examples or any other examples, the compression engine is additionally or alternatively configured to operate at a higher temperature than the quantum register. In any of the foregoing examples or any other examples, the decompression engine and the decoder block are additionally or alternatively configured to operate at a higher temperature than the compression engine. In any of the foregoing examples or any other examples, each decompression engine additionally or alternatively routes the decompressed companion data to a graph generator module of the decoder block. In any of the foregoing examples or any other examples, the decompressed companion data additionally or alternatively includes at least X companion data and Z companion data. In any of the foregoing examples or any other examples, the plurality of logical qubits additionally or alternatively includes l logical qubits, wherein the quantum computing device includes a set of d decoder blocks, where d<l.

[0160] In another example, a method for a quantum computing device includes: generating adjoint data from at least one quantum register including l logical qubits, where l is a positive integer; and for each logical qubit: routing the generated adjoint data to a compression engine, the compression engine being configured to compress the adjoint data; routing the compressed adjoint data to a decompression engine, the decompression engine being configured to: receive the compressed adjoint data; and decompress the received compressed adjoint data; and routing the decompressed adjoint data to a decoder block. In such an example or any other example, at least one compression engine is additionally or alternatively configured to compress the adjoint data using dynamic zero compression. In any of the foregoing examples or any other examples, at least one compression engine is additionally or alternatively configured to compress the adjoint data using a sparse representation. In any of the foregoing examples or any other examples, the method additionally or alternatively includes operating the compression engine at a higher temperature than the quantum register. In any of the foregoing examples or any other examples, the method additionally or alternatively includes operating the decompression engine and the decoder block at a higher temperature than the compression engine. In any of the foregoing examples or any other examples, each decompression engine additionally or alternatively routes the decompressed companion data to a graph generator module of a decoder block. In any of the foregoing examples or any other examples, the quantum computing device additionally or alternatively includes a set of d decoder blocks, where d<2*l.

[0161] In yet another example, a method for a quantum computing device includes: generating adjoint data from at least one surface code lattice including l logical qubits, where l is a positive integer, the surface code lattice being partitioned into two or more regions based on lattice geometry; and for each logical qubit: routing the generated adjoint data to a compression engine, the compression engine being configured to compress the adjoint data using geometry-based compression; routing the compressed adjoint data to a decompression engine, the decompression engine being configured to: receive the compressed adjoint data; and decompress the received compressed adjoint data; and routing the decompressed adjoint data to a decoder block. In such an example or any other example, compressing the adjoint data using geometry-based compression additionally or alternatively includes: compressing the adjoint data of each of two or more regions of the surface code lattice using zero indicator bits; and transmitting the adjoint data only from non-zero regions. In any of the foregoing examples or any other example, the number of regions is additionally or alternatively determined based on an expected number of data blocks containing trivial adjoints.

[0162] It will be understood that the configuration and / or method described herein are exemplary in nature, and these specific embodiments or examples should not be considered restrictive, because many variations are possible. The specific routines or methods described herein may represent one or more of any number of processing strategies. Like this, the various actions shown and / or described may be performed in the order shown and / or described, in other orders, in parallel, or omitted. Likewise, the order of the above process may be changed.

[0163] The subject matter of the present disclosure includes all novel and non-obvious combinations and sub-combinations of the various processes, systems and configurations, and other features, functions, acts, and / or properties disclosed herein, as well as any and all equivalents thereof.

Claims

1. A quantum computing device, comprising: at least one quantum register including a plurality of logical qubits; a compression engine coupled to each logical qubit of the plurality of logical qubits, each compression engine configured to compress companion data; as well as A decompression engine, coupled to each compression engine, each decompression engine being configured to: receiving compressed companion data; decompressing the received compressed accompanying data; as well as The decompressed companion data is routed to a decoder block.

2. The quantum computing device of claim 1 , wherein at least one of the compression engines is configured to compress the companion data using dynamic zero compression.

3. The quantum computing device of claim 1 , wherein at least one of the compression engines is configured to compress the companion data using a sparse representation.

4. The quantum computing device of claim 1 , wherein at least one of the compression engines is configured to compress the companion data using geometry-based compression.

5. The quantum computing device of claim 1 , wherein the plurality of logical qubits are divided into two or more sectors, and wherein a first sector of the one or more sectors is coupled to a first type of compression engine configured to compress the companion data using a first type of compression, and a second sector of the one or more sectors is coupled to a second type of compression engine configured to compress the companion data using a second type of compression.

6. The quantum computing device of claim 1 , wherein the compression engine is configured to operate at a higher temperature than the quantum register.

7. A quantum computing device according to claim 6, wherein the decompression engine and decoder block are configured to operate at a higher temperature than the compression engine.

8. The quantum computing device of claim 1, wherein each decompression engine routes decompressed companion data to a graph generator module of the decoder block.

9. The quantum computing device of claim 1, wherein the decompressed companion data comprises at least X companion data and Z companion data.

10. The quantum computing device of claim 1, wherein the plurality of logical qubits comprises l logical qubits, and wherein the quantum computing device comprises a set of d decoder blocks, wherein d <l。 11. A method for a quantum computing device, comprising: generating adjoint data from at least one quantum register comprising l logical qubits, where l is a positive integer; as well as For each logical qubit: routing the generated companion data to a compression engine, the compression engine being configured to compress the companion data; The compressed companion data is routed to a decompression engine, which is configured to: receiving the compressed companion data; as well as decompressing the received compressed accompanying data; as well as The decompressed companion data is routed to a decoder block.

12. The method of claim 11, wherein at least one of the compression engines is configured to compress the companion data using dynamic zero compression.

13. The method of claim 11, wherein at least one of the compression engines is configured to compress the companion data using a sparse representation.

14. The method of claim 11, further comprising operating the compression engine at a higher temperature than the quantum register.

15. The method of claim 14, further comprising operating the decompression engine and the decoder block at a higher temperature than the compression engine.

16. The method of claim 11, wherein each decompression engine routes decompressed companion data to a map generator module of the decoder block.

17. The method of claim 11, wherein the quantum computing device comprises a set of d decoder blocks, where d<2*l.

18. A method for a quantum computing device, comprising: generating adjoint data from at least one surface code lattice comprising l logical qubits, wherein l is a positive integer, the surface code lattice being partitioned into two or more regions based on lattice geometry; as well as For each logical qubit: routing the generated companion data to a compression engine, the compression engine configured to compress the companion data using geometry-based compression; Routing the compressed companion data to a decompression engine, the decompression engine being configured to: receiving compressed companion data; as well as decompressing the received compressed accompanying data; as well as The decompressed companion data is routed to a decoder block.

19. The method of claim 18, wherein compressing the companion data using geometry-based compression comprises: compressing companion data for each of the two or more regions of the surface code lattice using zero indicator bits; as well as The companion data is transferred only from non-zero regions.

20. The method of claim 18, wherein the number of regions is determined based on an expected number of data blocks containing trivial companions.

Images