Patent Description:
Aspects of the present disclosure generally relate to configurable quantum computing systems, and more specifically, to a software-defined quantum computer.

In a conventional quantum computer (QC) for solid-state quantum bits or qubits (e.g., superconducting qubits, quantum dots (QDs), etc.), the qubits are fabricated in, and their connections are often limited by, the hardware design of the chip or integrated circuit. This means that, for instance (but not limited to), (i) the size of the problem that can be computed, (ii) the type of circuit operations or algorithms/computations that can be implemented, and (iii) the corresponding performance metrics (e.g., total number of gates needed to run the circuit/algorithm, time it takes perform computations, and the success probability for a quantum circuit) depend strongly on the detailed design of the qubit hardware (i.e., the hardware used to realize the quantum bits), which is often implemented as a chip or integrated circuit. In other words, the operation or configuration of a conventional solid-state quantum computer tends to be rigid by the inherent limitations of the hardware components.

Techniques that allow for flexibility and configurability, particularly dynamic and/or software-based configurability, of quantum computers are highly desirable. <NPL> discloses a method of reconfiguring and providing a programmable ion trap quantum computer. <NPL> discloses practical construction of scalable quantum computer hardware for executing non-trival quantum algorithms. <CIT>) discloses a scalable quantum computer including at least two classical to quantum interface devices.

Its purpose is to present some concepts of one or more aspects in a simplified form as a prelude to the more detailed description that is presented later.

In an aspect of the disclosure, a hardware description language may be used with a software-defined quantum computer to configure the various resources available to the software-defined quantum computer to perform particular tasks, functions, programs, or routines. The hardware description language may be used to dynamically configure the software-defined quantum computer such that, for example, the size of the computations (e.g., the number of qubits) need not be fixed and may be adjusted on the fly. In an example, hardware description language may specify the structure (e.g., hardware connectivity) and behavior (e.g., operations) of the software-defined quantum computer.

In an aspect of the disclosure, a software-defined quantum computer is described that includes a control unit configured to receive programming instructions from a software program and generate control signals based at least in part on the programming instructions, and multiple qubits, where a number of the qubits and connections between any two of the qubits are enabled and controlled by the control signals from the control unit.

In another aspect of the disclosure, not falling under the scope of the claims, a software-defined quantum computer is described that includes multiple modules, each module having a control unit, a communication control unit, and multiple qubits, each control unit being configured to receive programming instructions from a software program and generate control signals based at least in part on the programming instructions, and a number of the qubits and connections between any two of the qubits are enabled and controlled by the control signals from the control unit. The software-defined quantum computer also includes a switch/router unit configured to enable communication channels from the communication control unit from each of the modules.

In another aspect of the disclosure, not falling under the scope of the claims, a software-defined quantum computing architecture is described that includes an application programming interface (API), a quantum operating system (OS) on which the API executes, the quantum OS including a resource manager and a switch, and multiple quantum cores connected via the switch, the resource manager being configured to determine the allocation of qubits in the quantum cores.

In another aspect of the disclosure, not falling under the scope of the claims, a method for compiling source code for a software-defined quantum computer is described that includes performing a lexical analysis on a high-level intermediate representation of a quantum programming language, performing semantic analysis on an output of the lexical analysis, and producing a mid-level intermediate representation of the quantum programming language based on an output of the semantic analysis.

In yet another aspect of the disclosure, not falling under the scope of the claims, a computer-readable medium storing code with instructions executable by a processor for compiling source code for a software-defined quantum computer is described that includes code for performing a lexical analysis on a high-level intermediate representation of a quantum programming language, code for performing semantic analysis on an output of the lexical analysis, and code for producing a mid-level intermediate representation of the quantum programming language based on an output of the semantic analysis.

In another aspect of the disclosure, a software-defined quantum computer is described that includes a first control unit and a second control unit. The first control unit can be configured to receive programming instructions from a software program and generate first control signals, and a first plurality of qubits is enabled and controlled by the first control signals from the first control unit. The second control unit can be configured to receive programming instructions from the software program and generate second control signals, and a second plurality of qubits is enabled and controlled by the second control signals from the second control unit. Moreover, the first control unit can be configured to shuttle a number of the first plurality of qubits to be controlled by the second control unit such that a number of the second plurality of qubits is increased by the number of the first plurality of qubits that are shuttled.

Described herein are methods, apparatuses, and computer-readable storage medium for various aspects associated with software-defined quantum computers.

The appended drawings illustrate only some implementation and are therefore not to be considered limiting of scope.

This disclosure describes various aspects of an approach to implementing a quantum computer (QC), QC system, or quantum information processing (QIP) system, where several, if not most, of the functional aspects of the QC are defined by software (i.e., software-defined functionality). That is, the functionality of the QC need not be rigid or limited by the hardware design and can be configured using software. By implementing a software-defined architecture for a QC, it is possible to use software or some dynamic instructions to define a system of qubits, to control and manipulate qubit connectivity (e.g., connections between different qubits), and to modulate the inter-qubit interactions (e.g., interactions between different qubits) to execute a given computational or simulation task. This approach may also involve a systematic way to describe the hardware configurations for the QC.

A classical, that is, non-quantum, central processing unit (CPU) typically consists of a control unit and a datapath, both of which are typically implemented using digital complementary metal-oxide-semiconductor (CMOS) circuitry. The control unit typically translates the program's instructions to decide how to manipulate the data, and manages the resources in the CPU necessary for the execution of the instruction, as well as the timing of each instruction execution. The datapath is a collection of functional units, registers, and buses in the processor where the data being processed flow through. The computation is carried out by the control unit instructing the various functional units, registers, and buses to manipulate the data, resulting in the final output of the desired computational task. In a typical CPU, the control unit and the datapath are implemented using digital circuits constructed using logic elements, built using transistors, and are highly intertwined in its layout on the chip.

A quantum computer (or QC/QIP system) manipulates quantum data (measured in units of qubits), and therefore the datapath has to be made up of quantum objects. The functional units that store, transport, and manipulate the data must be able to handle the qubits, maintaining quantum characteristics (such as superposition and entanglement) and acting simultaneously on all components of the superposition input states. On the other hand, the control unit is typically classical, as the instructions specified in the control program are classical in nature. A typical control unit can be configured to translate an instruction from a program or algorithm into a classical control signal that operates the functional units to act on the qubits to effect the desired data manipulation. The action on the qubit is generally analog in nature, where the classical control signal (typically consists of a carrier electromagnetic field (e.g., radio frequency (RF), microwave, optical) with modulation that encodes the action in either the same or a separate field) transforms the qubit (or a group of qubits) to a different quantum state via controlled time-evolution of quantum systems. That is, the classical control signal is used to control operations that sequentially transform the qubit states over time to generate the desired computation or simulation.

In this disclosure, the implementation of a quantum computer (or QC/QIP system) is considered where the control units are specifically designed and constructed in the hardware, while leaving the physical implementation of the datapath fully flexible and reconfigurable. The physical implementation of the datapath is described by a set of instructions provided to the hardware units, rather than being pre-designed and fabricated in the hardware. Likewise, the interaction among the qubit datapaths are also implemented as a sequence of instructions that enacts the time evolution of the qubit systems, dictated by the control signal generated by the control unit using a software program.

The approach described in this disclosure has some unique features that distinguish this approach from earlier approaches. For a QC based on trapped ion technology, the unique features of the proposed system are described below. Trapped ion technology may refer to the use of ions or atoms loaded and arranged into a trap or similar structure to control their states in order to perform quantum operations/simulations.

In a first aspect, the number and connectivity (e.g., interactions) of the qubits in the system is not predetermined by the design of the hardware. For example, the QC can have a control unit with the capability to control n qubits at a time (e.g., n is an integer and could be <NUM>, <NUM>, <NUM> or something larger) in the hardware (control unit) design, and then "load" anywhere between <NUM> and m qubits (e.g., where m is also an integer and can potentially be much larger than n) each time we choose to operate the QC.

<FIG> shows a diagram <NUM> that illustrates an example of a software-defined quantum computer in accordance with aspects of this disclosure. The system shown in the diagram <NUM> of <FIG> can, as described above, load or enable up to m qubits and then control any subset of n qubits (see e.g., qubits <NUM> in <FIG>), where m ≥ n. As used herein, the terms quantum computer, quantum computer system, quantum computing system, an quantum information processing system may be used interchangeably.

As noted above, a hardware description language may be used with a software-defined quantum computer to configure the various resources available to the software-defined quantum computer so that it can perform particular tasks, functions, programs, or routines. The hardware description language may be used to dynamically configure the software-defined quantum computer such that, for example, the size of the computations (e.g., the number of qubits) may be adjusted on the fly (e.g., can be changed from one size to another size at any point in time). In an example, hardware description language may specify the structure and behavior of the software-defined quantum computer. This approach differs from a conventional quantum computer in which the configuration is rigid and fixed by the hardware. Instead, a software-defined quantum computer may be configured using, for example, a hardware description language (or quantum hardware description language), in a manner similar to how a field programmable device may be configured. As such, a software-defined quantum computer may be configured to load and use <NUM> qubits, <NUM> qubits, or <NUM> qubits (or any number for that matter) as it is needed for the particular operations being performed.

In a second aspect, the qubits have available all-to-all interaction among them, where such form of interaction may be normally off. In other words, each qubit may interact or have some connectivity (see e.g., connections or interactions <NUM> in <FIG>) to a subset of the remaining qubits (including a single other qubit) or to all of the remaining qubits. Some of the interactions among the qubits can be "turned on" or enabled by a control unit (see e.g., control unit <NUM> in <FIG>) to affect certain instructions (e.g., a set of logic gates) on a set of qubits. The nature of each instruction may be determined by the way the control unit is programmed (e.g., by program <NUM> using programming instructions <NUM>), to generate the necessary control signals (see e.g., control signals <NUM>) to perform the instruction(s). The programming instructions <NUM> provided by the program <NUM> may therefore reflect the set of instructions and the control unit <NUM> may process the programming instructions <NUM> to generate the appropriate control signals <NUM> to perform the set of instructions.

In another aspect, in one implementation, the set of instructions can be described as a collection of algebraic quantum gates with each gate performing a discrete action on a quantum input of qubits to generate an output state of the qubits.

In another aspect, in another implementation, the set of instructions can be described as a collection of parameterized, continuous quantum gates, broadly defined, with each gate performing a parameter-dependent action on a quantum input. For example, a predetermined evolution of a set of qubits in the QC associated with desired interaction Hamiltonian is implemented with continuous variables that dictate the nature of evolution.

In yet another aspect, the time evolution of the set of qubits used can be adiabatic (e.g., adiabatic time evolution), diabatic (e.g., diabatic time evolution), or anything in between (e.g., adiabatic/diabatic or mixed time evolution), as long as they are well-defined.

In yet another aspect, in another implementation, the set of instructions can be a combination of quantum logic gates and Hamiltonian evolution. The combination may be temporal, spatial, or both.

In another aspect, an expanded or expandable system can also be considered as part of the type of software-defined quantum computers described in this disclosure. The overall, composite system may be constructed with a group of individual, component qubit systems, where the quantum connection among the constituent qubit systems are established by either shared entanglement among a subset of constituent qubit systems, or by physically moving the qubits between the constituent qubit systems.

<FIG> shows a diagram <NUM> that illustrates an example of a control unit <NUM>. The single control unit <NUM> in diagram <NUM> can represent the implementation of several of the control units <NUM> in <FIG>. These multiple control units <NUM>, while physically and/or logically separate from each other, may be organized or implemented within a higher level structure, in this case the single control unit <NUM>. For example, in diagram <NUM>, the control unit <NUM> includes control units 120a, 120b,. , <NUM>, which may also be referred to as sub-control units or sub-units to the control unit <NUM>. In this example, each of the control units 120a, 120b,. , <NUM> can process a subset of the programming instructions <NUM> received by the control unit <NUM> or can receive its own, separate set of programming instructions <NUM>. <FIG>, which shows an expandable software-defined quantum computer and is described in more detail below, illustrates a case in which more than one control unit <NUM> is used, where these control units <NUM> may be separately implemented.

Each of the control units 120a, 120b,. , <NUM> is independently programmable and can be used to control (e.g., using control signals <NUM>) a distinct set of qubits (e.g., qubits <NUM>). The number of qubits can be the same for all of the control units or can vary across control units, depending on the programming instructions received and the maximum number of qubits that can be loaded or enabled by a respective one of the control units 120a, 120b,.

Since the qubits are implemented using ion trap technology, each of the control units 120a, 120b,. , <NUM> handles qubits in a different region of the ion trap. It is possible then to expand a software-defined quantum computer by how these control units are used in connection with adjacent regions in an ion trap.

<FIG> show diagrams <NUM> and <NUM>, respectively, to illustrate the "shuttling" of ions or atoms between different control units (e.g., between different regions in an ion trap). For example, in diagram <NUM>, the control unit 120a controls x qubits (e.g., ions or atoms) and the control unit 120b controls y qubits (e.g., ions or atoms). The dashed line indicates that while the control unit 120a and the control unit <NUM> are shown as separate devices, they may be optionally implemented monolithically as part of a same structure (e.g., control unit <NUM> in <FIG>).

Diagram <NUM> shows the "shuttling" or transfer of z qubits from the qubits controlled by the control unit 120a to the qubits controlled by the control unit 120b. As a result of this process, the control unit 120a is left controlling (x - z) qubits and the control unit 120b is left controlling (y + z) qubits. In one example, if both control units initially handled thirty (<NUM>) ions or atoms, and five (<NUM>) ions or atoms are shuttled or transferred over, then the control unit 120b is left controlling or handling thirty five (<NUM>) ions or atoms and the control unit 120a s left controlling or handling twenty five (<NUM>) ions or atoms. These shuttled or transferred ions or atoms are used to communicate information from one set of qubits to another set of qubits.

Based on the additional aspects described in <FIG>, a software-defined quantum computer (e.g., such as a variation of the software-defined quantum computer <NUM> in <FIG>), can include a first control unit (e.g., control unit 120a) and a second control unit (e.g., control unit 120b), where the first control unit is configured to receive programming instructions (e.g., programming instructions <NUM>) from a software program and generate first control signals (e.g., control signals 125a), and a first plurality of qubits is enabled and controlled (e.g., x qubits) by the first control signals from the first control unit, and where the second control unit is configured to receive programming instructions from the software program and generate second control signals, (e.g., control signals 125b) and a second plurality of qubits is enabled and controlled (e.g., y qubits) by the second control signals from the second control unit. In such a quantum computer, a number of control units including the first control unit and the second control unit can be dynamically changed (e.g., increased or decreased based on the number of qubits needed and the number of control units needed to control those qubits).

The first control unit is further configured to shuttle a number of the first plurality of qubits (e.g., z qubits) to be controlled by the second control unit such that a number of the second plurality of qubits is increased by the number of the first plurality of qubits that are shuttled (e.g., y + z qubits). A number of qubits that remain under the control of the first control unit are reduced by the amount of qubits shuttled over (e.g., x - z qubits).

The programming instructions received by the first control unit may be different than the programming instructions received by the second control unit. The programming instructions received by the first control unit include communication instructions to shuttle the number of the first plurality of qubits to be controlled by the second control unit.

In another aspect, the number of the first plurality of qubits that are shuttled includes information associated with the first plurality of qubits, and the information is transferred to the second plurality of qubits by the number of the first plurality of qubits that are shuttled. The number of the first plurality of qubits shuttled to be controlled by the second control unit includes one or more qubits and the shuttling of the one or more qubits establishes a communications channel between the first plurality of qubits and the second plurality of qubits.

In another aspect, the first plurality of qubits includes memory/operations qubits (see e.g., memory/operations qubits 130a in <FIG>) and communications qubits (see e.g., communications qubits 130b in <FIG>) that are enabled and controlled by the control signals from the first control unit, and the number of the first plurality of qubits that are shuttled includes one or more of the communication qubits.

It is possible to expand the capabilities of a software-defined quantum computer through the techniques described above in connection with <FIG> by adjusting the number of ions or atoms and the number of control units needed to control the ions or atoms. An example of such expanded capabilities is described in more detail below in <FIG>.

<FIG> shows a diagram <NUM> that illustrates an unclaimed example of an expandable software-defined quantum computer or quantum computing system. The expandable quantum computing system shown in diagram <NUM> in <FIG> follows some of the architectural aspects of the system shown in diagram <NUM> in <FIG> and in <FIG>. For example, the system in diagram <NUM> includes a program 110a that provides programming instructions 115a to a module 210a (Module <NUM>) having a control unit 120a and a communication control unit 220a (referred to as Comm. Unit 220a in <FIG>). The programming instructions 115a may be used to program the control unit 120a to affect a set of instructions on one or more of the qubits that have been loaded within the module 210a via control signals produced by the control unit 120a. Moreover, the programming instructions 115a may be used to program the communication control unit 220a to affect a set of instructions on one or more of the qubits via control signals produced by the communication control unit 220a to enable, implement, or control a communication channel 225a with a switch/router unit <NUM>.

The program 110a may also provide programming instructions 115b to a module 210b (Module <NUM>) configured to include a control unit 120b and a communication control unit 220b (referred to as Comm. Unit 220a in <FIG>), which in turn can enable, implement, or control a communication channel 225b with the switch/router unit <NUM>. As shown in the diagram <NUM>, the number of modules used in the system is configurable or expandable and there could be up to k modules, where a module <NUM> (Module K) can also include a control unit and a communication control unit (in addition to multiple internal qubits) and a communication channel <NUM> may be enabled between the module <NUM> and the switch/router unit <NUM>. The switch/router unit <NUM> is configured to provide connectivity between the different modules via the interactions between the modules and the switch/router unit <NUM>.

The communication control units 220a and 220b in <FIG> may be implemented independent from their respective control units 120a and 120b, or may be integrated within their respective control units 120a and 120b. The communication achieved using the communication control units 220a and 220b as well as the switch/router unit <NUM>, may also be accomplished or realized, at least in part, using the shuttling technique described in <FIG> in which information from one set of qubits is available to another set of qubits as a result of the shuttling of qubits.

Within each of the modules 210a,. , <NUM> there are a number of qubits <NUM> that can be controlled by the respective control unit and communication control unit. Some of the qubits may be used for memory/operations (e.g., qubits 130a) and others may be communications qubits used to enable the communications channels <NUM> (e.g., qubits 130b). Since the qubits <NUM> in a module are implemented using ion-trapped technology, the memory/operation qubits 130a can be based on <NUM>Yb+ atomic ions, and the communication qubits 130b can be based on <NUM>Ba+ atomic ions. Other species and/or isotopes can also be used for the pairs of memory/operations and communications qubits. The memory/operations qubits 130a are enabled and controlled by the control signals from the respective control unit, and the communication qubits 130b are enabled and controlled by the control signals from the respective communication control unit.

In another aspect, the specific instance of the hardware configuration (e.g., hardware configurations for the systems described in <FIG> and <FIG>) may be provided using a quantum version of a hardware description language (HDL), that captures the key resources in each hardware (or set of qubits) instantiation, their availability and relative connection, and low-level functionality of the quantum hardware enabled by the configuration. It will also have an interface to which the quantum program generated by the higher-level software will control the operation of the hardware (see e.g., programs <NUM>, 110a and control units <NUM>, 120a, 120b).

In yet another aspect, the approach described in this disclosure also ensures a maximum portability of quantum programs (e.g., programs or instructions that are to be effected using a QC or QC system), because using a software-defined architecture allows for code independence from the underlying details of the hardware specifics of a QC or QC system. That is, the programs <NUM> and 110a in <FIG> and <FIG>, respectively, can be ported.

In another aspect, the flexibility of the approach described in this disclosure allows the use of optimized graph placement and the embedding of algorithms using both heuristics (e.g., a custom tabu search (TS)) and deep leaming to port programs among different software-defined architectures. Using a custom tabu search for heuristics may involve using a global optimization algorithm and a metaheuristic or meta-strategy for controlling an embedded heuristic technique.

In another aspect, the approach described in this disclosure enables verification of the porting of a program to a software-defined architecture using both formal and algorithmic approaches.

In another aspect, this disclosure also describes the implementation of a resource manager (see e.g., resource manager <NUM> in a diagram <NUM> in <FIG>) to deliver the most efficient software-defined architecture for an incoming job. The optimization is done over the following parameters:.

In yet another aspect, the software-defined QC approach described in this disclosure may also adapt the concept of elasticity from cloud computing. For example, it is possible to implement an elastic computing environment where qubits can be shuttled from a reserve region (already loaded in a separate trapping zone) to the computing region and back on demand during the runtime of a program. That is, the demands placed on the system during runtime of a program may be used to dynamically modify (e.g., provide elasticity to) the computing environment. Therefore, it is possible to have readily available zones in a trap with additional computing resources (e.g., preloaded ions) to easily expand the computing environment on demand.

In another aspect not falling under the scope of the claims, the architectures described herein for software-defined QCs and QC/QIP systems may support both homogenous and heterogeneous multi-core quantum processing unit (QPU) systems. A homogenous multi-core QPU is a network of identical traps (e.g., ion traps). On the other hand, a heterogeneous multi-core QPU is a network of traps of different configurations, or a network of QPUs constructed using disparate technologies (e.g., ion traps, superconducting circuits, etc.).

For heterogeneous multi-core QPU networks having disparate technologies may require the use of transducers (e.g., quantum transducers) to connect qubits of different physical systems. In one implementation, a single transducer may be used between two qubits of different technologies. In another implementation, different transducers may be used based on the direction of the connection or interaction (e.g., a first transducer in a direction from a qubit <NUM> to a qubit <NUM>, and a second transducer in a direction from the qubit <NUM> to the qubit <NUM>).

Various aspects of the software-defined QC and QC/IP systems described in connection with this disclosure include aspects associated with the architecture, implementation, configuration, and optimization, including but not limited to architecture graph, circuit graph, portability, quadratic assignment problem, depth optimal layout, sequence of (heuristic) optimal embedding, single-instruction multiple-data (SIMD) QC, quantum circuit compilation, quantum circuit design, and quantum circuit optimization.

<FIG> shows the diagram <NUM> that illustrates an unclaimed example of a system architecture for a software-defined QC. The system architecture shown in the diagram <NUM> is based on ion traps or ion trap technology. In embodiments not falling under the scope of the claims, systems based on technologies different from ion trap technology (e.g., trapped neutral atoms or superconducting circuits) may also be implemented using the techniques described in connection with diagram <NUM> in <FIG>.

A software-defined quantum computer may generally include three major architectural layers. At the very top lies the API stack <NUM>, which is configured to expose a programmable interface for the computer's users. Typically, the API stack <NUM> does not expose the hardware variability and assumes a virtual large completely connected quantum computer. That is, the manner in which the hardware is configured need not be known to the computer's users.

The Quantum Operating System (OS or QOS) <NUM> sits between the hardware and the API stack <NUM>. The primitives of software-defined quantum architecture may be exposed and programmable inside this layer. The Quantum OS <NUM> may include a resource manager <NUM> (described at least partially above) to find an optimized way to handle qubit allocation. That is, the role of the resource manager <NUM> is to identify the most efficient software-defined architecture for an incoming job. A qubit allocation can be intra or inter quantum core (see e.g., quantum cores 370a, 370b, and <NUM>). A quantum core may also be referred to as a quantum unit, a core unit, or simply a core. As used in this disclosure unless otherwise specified, a quantum core is individual ion trap (although in embodiments not falling under the scope of the claims quantum cores of other technologies may also be used). It is understood that an individual ion trap may include one or more qubits. If the core units in a network or architecture are not identical, the architecture is referred to as a heterogeneous architecture (this could mean different ion traps, or different cores made of different technologies, such as ion traps and trapped neutral atoms, or superconducting qubits). On the other hand, when a network or architecture has identical core units (e.g., identical ion traps), the architecture is referred to as a homogenous architecture. The resource manager <NUM> is configured to decide or determine how the qubits will be allocated and aligned inside a core unit (i.e. ion trap). The resource manager <NUM> is also configured to determine the best qubit connection (e.g., interactions <NUM>) and communication channel (e.g., communication channels <NUM>) (photonic interconnect, for example) for qubit allocation over multiple core units (i.e. ion traps). After the mapping is determined by the resource manager <NUM>, a switch <NUM> inside the Quantum OS <NUM> may route all the operations and readouts. The switch <NUM> may include a soft switch <NUM> and a hard switch <NUM> that can have classical channels <NUM> (dotted line) and quantum channels <NUM> (solid line) connected to the quantum cores.

In another aspect of resource allocation in software-defined quantum architectures, <FIG> show a flow chart <NUM> that illustrates an example of a resource manager workflow in accordance with unclaimed embodiments.

There are many different kinds of resources at the disposal of a resource manager (e.g., resource manager <NUM>) in a software-defined quantum architecture. These resources include qubits, connectivity, coherence, (photonic) interconnect network among core units (e.g., ion traps), classical communication channels, as well as other types of resources. A software-defined quantum architecture, via a resource manager, needs to optimize the resource utilization as much as possible within a reasonable time frame. When a program (e.g., a set of instructions) is submitted via the API stack <NUM> (see <NUM>), it is translated into a next level intermediate representation which is handed over to the resource manager (see <NUM>). From the netlist-like representation, the resource manager estimates the cost of executing the program (see <NUM>). This cost will be used by the resource manager to make decisions about resource allocation. The first decision taken by the resource manager is whether hardware has the necessary and sufficient resources to execute the program (see <NUM>). If it is a multi-quantum-core system, the resource manager allocates the least number of cores on which the program can run (see <NUM>). If there are more than one set of least number of cores, the resource manager chooses the cores for which distribution of the program is least expensive. For example, the current requested operation is following a sequence of previous operations which have been performed on a certain software-defined architecture (see <NUM>). The resource manager may compare between the cost of mapping the operation on an existing software-defined architecture (see <NUM>) and the cost of creating a software-defined architecture native to the operation (see <NUM>) and decide accordingly (see <NUM>, <NUM>). If any decision increases the circuit depth (see <NUM>) or if a rounding off error occurs (see <NUM>), the appropriate flags (see <NUM>, <NUM>) need to be raised while returning the result. The job may then be placed on the priority queue for the target core(s) (see <NUM>).

Another aspect associated with the software-defined quantum computer architectures described in this disclosure is the need for compiling quantum programs. Referring to <FIG>, there is shown a chart <NUM> that illustrates an example of levels of API access points in accordance with unclaimed embodiments. The chart <NUM> shows as the top level, a client <NUM>, followed by a rest API <NUM>, a quantum programming language (QPL) <NUM>, a high-level intermediate representation (HLIR) <NUM>, a mid-level intermediate representation (MLIR) <NUM> for software-defined architecture, a quantum hardware definition or description language (HDL) <NUM>, a low-level intermediate representation (LLIR) <NUM>, a quantum control system language <NUM>, and machine code <NUM> as the lowest level.

In an ideal system implementation, the software-defined quantum architecture may not be exposed via the highest level API (e.g., rest API <NUM>). A code written using QPL (e.g., QPL <NUM>) may be translated into a high level intermediate representation (<NUM>) which may still assume an idealized quantum architecture. An interpreter, which has access to the language primitives for software-defined quantum architecture, may translate the code into a mid-level intermediate representation (<NUM>). This mid-level representation may then be translated into a quantum version of hardware description language (HDL) or quantum HDL (QHDL) (<NUM>). A robust type system is needed to limit the propagation of programmer's error from the high-level intermediate representation to the mid-level intermediate representation for software-defined architecture. The development of the robust type system may be accomplished through the application of type theory. Standard languages of logic for these application are Floyd-Hoare logic and intuitionistic type theory. While it may be natural to use Floyd-Hoare logic for an imperative mid-level intermediate representation, one can be benefited from the usage of intuitionistic type theory if the representation has functional elements for distributed quantum computers. As noted above, after the use of QHDL, a low-level intermediate representation (<NUM>), a quantum control system language (<NUM>), and machine code (<NUM>) may be obtained or applied.

Further with respect to the compilation of quantum programs, <FIG> shows a diagram <NUM> illustrating an example of typical components of a quantum compiler in accordance with unclaimed embodiments. As shown in diagram <NUM>, a quantum compiler <NUM> receives quantum programming language source code <NUM>. The quantum compiler <NUM> includes a lexical analyzer <NUM> and a semantic analyzer <NUM>, which in turn has an operational semantic analyzer <NUM> and a denotational semantic analyzer <NUM>. The output of the quantum compiler <NUM> is an intermediate representation <NUM>.

In the case of software-defined architecture, a variant of the quantum compiler <NUM> is used to translate high-level intermediate representation (HLIR) of the source code (<NUM>) to a mid-level intermediate representation (MLIR) (<NUM>). The HLIR goes through the lexical analyzer <NUM>, which checks or verifies that the syntax of the program is appropriate. The goal is to see whether the primitives for software-defined architecture are being used with appropriately formatted parameters and instructions. Then the semantic analyzer <NUM> determines the meaningfulness of the code. As shown in diagram <NUM>, this is done at two levels. The operational semantic analyzer <NUM> checks whether the organization of the code is compliant with the language for software-defined architecture. Then the denotational semantic analyzer <NUM> validates the equivalence of expected and actual types of the inputs and outputs of each statements. Once the semantic analysis is completed, the translation of the high-level intermediate representation (HLIR) to the mid-level intermediate representation (MLIR) is completed, where the MLIR contains the language primitives of the software-defined architecture.

Another aspect related to the operation of software-defined QC architectures is exception handling. Exceptions can happen while a program is being executed on a software-defined quantum computer. <FIG> show diagrams <NUM>, <NUM>, and <NUM> that illustrate an example of exemption taxonomy in accordance with unclaimed embodiments. As shown in the diagram <NUM> in <FIG>, exceptions <NUM> can rise from either hardware <NUM> or software <NUM>. The API stack (see e.g., API stack <NUM>) for the software-defined QC architecture is generally robust enough to handle these exceptions gracefully and return the exception messages with appropriate level of abstraction.

The diagram <NUM> in <FIG> shows the hardware exceptions <NUM>. These exceptions may include, but need not be limited to, decoherence error <NUM>, measurement error <NUM>, shuttling error <NUM>, reset <NUM>, interrupts <NUM>, teleportation error <NUM>, and frequency crowding <NUM>. A measurement error <NUM> can occur either from a global measurement error <NUM> or a partial measurement error <NUM>.

The diagram <NUM> in <FIG> shows the software exceptions <NUM>. These exceptions may include, but need not be limited to, stack trace <NUM>, errors <NUM>, and programmer initiated <NUM>. The only programmer initiated exception is measurement. Software errors <NUM> include, but need not be limited to, address error <NUM>, rotation rounding off error <NUM>, privilege violation error <NUM>, illegal instruction error <NUM>, divided-by-zero error <NUM>, cloning error <NUM>, and tomography error <NUM>. In a software-defined QC architecture a middle layer plays a crucial role in abstracting the hardware errors and handling a major number of software errors.

Referring now to <FIG>, illustrated is an example computer device <NUM> in accordance with aspects of the disclosure. The computer device <NUM> can represent a single computing device, multiple computing devices, or a distributed computing system, for example. The computer device <NUM> may be configured as a quantum computer (or QC/QIP system), a classical computer, or a combination of quantum and classical computing functions. For example, the computer device <NUM> may implement some or all of the features described herein for a software-defined quantum computer, including modular expandability, architecture, resource manager functionality and workflow, API access points, and exception taxonomy/handling. Moreover, the computer device <NUM> may implement aspects of a classical computer to perform certain functions such as compiling, optimization, and the like. In addition, the computer device <NUM> may implement a combination of classical computer and quantum computer features sequentially and/or concurrently in order to enable the various aspects described herein. As such, the computer device <NUM> may include one or more of the hardware and/or software components described in connection with <FIG>.

More generally, the computer device <NUM> may include a processor <NUM> for carrying out processing functions associated with one or more of the features described herein. The processor <NUM> may include a single or multiple set of processors or multi-core processors. Moreover, the processor <NUM> may be implemented as an integrated processing system and/or a distributed processing system.

The processor <NUM> may include a central processing unit (CPU), a quantum processing unit (QPU), or both. As such, the processor <NUM> can be used to perform or implement classical operations, quantum operations, or a combination of classical operations and quantum operations.

The processor <NUM> may be used to, for example, implement at least a portion of control units, communication control units, and/or switch/router units (see e.g., <FIG> and <FIG>), to run at least a portion of programs, APIs and/or QOS (see e.g., <FIG>), and/or to implement aspects associated with qubit control (see e.g., <FIG>).

The processor <NUM> may be used to, for example, perform the resource manager workflow described in <FIG>, implement the levels of application programming interface (API) access points described in <FIG>, implement functions of the compiler architecture described in <FIG>, and/or implement the exceptions described in <FIG>.

The computer device <NUM> may include a memory <NUM> for storing data, which may include instructions executable by the processor <NUM> for carrying out the functions described herein. In an implementation, the memory <NUM> may correspond to a computer-readable storage medium that stores code or instructions to perform one or more of the functions or operations described herein. In one example, the memory <NUM> may include programs <NUM> and 110a in <FIG> and <FIG>. In another example, the memory <NUM> may be used to enable the software-defined quantum computer architecture described in <FIG> (e.g., by storing at least a portion of the QOS <NUM>), the resource manager workflow in <FIG>, the levels of API access points described in <FIG>, the compiler architecture described in <FIG>, and/or the exceptions described in <FIG>.

Further, the computer device <NUM> may include a communications component <NUM> that provides for establishing and maintaining communications with one or more parties utilizing hardware, software, and services as described herein. The communications component <NUM> may carry communications between components on the computer device <NUM>, as well as between the computer device <NUM> and external devices, such as devices located across a communications network and/or devices serially or locally connected to computer device <NUM>. For example, the communications component <NUM> may include one or more buses, and may further include transmit chain components and receive chain components associated with a transmitter and receiver, respectively, operable for interfacing with external devices.

In an aspect, when the computer device <NUM> implements quantum operations, the communications component <NUM> may include and/or implement aspects of the communication control units (e.g., communication control units 220a and 220b) and the switch/router unit <NUM> in <FIG>.

Additionally, the computer device <NUM> may include a data store <NUM>, which can be any suitable combination of hardware and/or software, that provides for mass storage of information, databases, and programs employed in connection with implementations described herein. For example, the data store <NUM> may be a data repository for operating system <NUM> (e.g., classical OS, quantum OS, or both). In one implementation, the data store <NUM> may include the memory <NUM>.

The computer device <NUM> may also include a user interface component <NUM> operable to receive inputs from a user of the computer device <NUM> and further operable to generate outputs for presentation to the user. The user interface component <NUM> may include one or more input devices, including but not limited to a keyboard, a number pad, a mouse, a touch-sensitive display, a digitizer, a navigation key, a function key, a microphone, a voice recognition component, any other mechanism capable of receiving an input from a user, or any combination thereof. Further, the user interface component <NUM> may include one or more output devices, including but not limited to a display, a speaker, a haptic feedback mechanism, a printer, any other mechanism capable of presenting an output to a user, or any combination thereof.

In an implementation, the user interface component <NUM> may transmit and/or receive messages corresponding to the operation of the operating system <NUM>. In addition, the processor <NUM> may execute the operating system <NUM> and/or applications or programs, and the memory <NUM> or the data store <NUM> may store them.

When the computer device <NUM> is implemented as part of a cloud-based infrastructure solution, the user interface component <NUM> may be used to allow a user of the cloud-based infrastructure solution to remotely interact with the computer device <NUM>. For example, the user may interact by providing an algorithm or simulation to be programmed for execution by the computer device <NUM>.

In yet another aspect, the computer device <NUM>, when implementing aspects of a quantum computer or QC/QIP system, may include qubit hardware <NUM>. As mentioned above, the qubit hardware <NUM> includes at least one ion trap to perform quantum operations. In embodiments not falling under the scope of the claims, the qubit hardware <NUM> may be based on other types of quantum technology, such as superconducting technology, in which case the qubit hardware <NUM> includes superconducting circuits to perform quantum operations.

Claim 1:
A quantum computer (<NUM>), comprising:
an ion trap including a plurality of qubits (<NUM>), the ion trap including a plurality of regions that each includes a subset of qubits; and
a control unit (<NUM>) configured to receive programming instructions from a software program, the control unit (<NUM>) including multiple sub-control units logically separate from each other and independently programmable, wherein the number of multiple sub-control units is dynamically-configurable and each of the multiple sub-control units (120a, 120b, ..., <NUM>) is configured to generate a corresponding set of control signals based at least in part on the programming instructions;
wherein each subset of qubits is controlled by the set of control signals from a corresponding and different one of the multiple sub-control units (120a, 120b, ..., <NUM>), the controlling of each subset of qubits including enabling a number of qubits in each subset of qubits and a connectivity between the plurality of qubits,
wherein a total number of qubits enabled in the plurality of qubits (<NUM>) is based on a particular operation being performed by the quantum computer (<NUM>), and
wherein the set of control signals controlling a first subset of qubits of the plurality of qubits (<NUM>) is used to shuttle at least one qubit from the first subset of qubits in one region of the ion trap to a second subset of qubits of the plurality of qubits (<NUM>) that is in a different adjacent region of the ion trap, and the set of control signals controlling the second subset of qubits is used to handle the at least one qubit shuttled from the first subset of qubits, and
wherein the shuttling of the at least one qubit from the first subset of qubits in the one region to the second subset of qubits in the different adjacent region includes transferring information from the first subset of qubits to the second subset of qubits, such that the shuttled at least one qubit is used to communicate the information from first subset of qubits to the second subset of qubits.