Scalable system-level architecture for the control of a quantum processor

Abstract

The present invention relates to a system for controlling a quantum processor (9), comprising utility entities, router entities (8) and backbone entities (71, 72, 73, 74) as nodes of a network, wherein each entity in the network is connected to at least one other entity, and at least one transducer (6) configured for interacting with quantum objects (5) of a quantum system. It further relates to a backbone entity (7) for a system for controlling a quantum processor (9), wherein the backbone entity (7) comprises utility cores comprising a network interface core (11), a service core (41), a power core (31), a time core (21), a memory management unit core (13) and an opcode-core (12) and optionally one or more transmission core(s) (131, 132, 133, 134). Further, it relates to a router entity (8) for a system for controlling a quantum processor (9), wherein the router entity (8) is configured to re-direct instructions from a hardware-specific instruction set architecture, wherein the router entity (8) comprises a network hub port (16), a switch core (17), a service core (41), a power core (31), a time core (21). It relates further to a controlling method for and an operating method for controlling a quantum processor (9).

Description

[0001] SCALABLE SYSTEM-LEVEL ARCHITECTURE FOR THE CONTROL OF A QUANTUM PROCESSOR

[0002] Field of the invention

[0003] The present invention relates to a system for controlling a quantum processor, comprising utility entities, router entities and backbone entities as nodes of a network, wherein each entity in the network is connected to at least one other entity and relates to a backbone entity and a router entity for a system for controlling a quantum processor, and relates to a controlling method for a quantum processor and an operating method for controlling a quantum processor.

[0004] Background of the invention

[0005] Almost thirty years have passed by since the concept of a trapped-ion quantum processor (TIQP) was first proposed and in the same year experimentally proven. Since then, many efforts were made to realize quantum computation by using trapped-ions as quantum-bits (qubits), including the design and development of its control system. Further, many other quantum systems have been developed which allow quantum computation.

[0006] However, common to all these quantum processors (QPs) is the urgent need for a shift on the design methodology for the control system, to be able to move past the experimentation phase and unite efforts on the roadmap towards achieving the development of a utility-scale quantum processor.

[0007] The scalability of a quantum processor is the only DiVincenzo criteria that has not yet been achieved for a utility-scale and fault-tolerant quantum processor. The control system of a quantum processor needs to scale jointly with the number of quantum objects. Therefore, the control system is one of the engineering bottlenecks hindering the deployment of this device. In engineering we can take one of two main approaches to design a system: top-down or bottom-up. Either build each component (sub-system) separately and at the end join them together in a system: bottom -up, or start with the system-level description and from there define each component (sub-system): top-down. Until now, development of the control system of a TIQP has taken an embedded system bottom-up approach. Furthermore, we can generalize thatstatement to other quantum object types of quantum processors, for the status-quo is to develop a quantum processor with a bottom-up mindset. During the first years after its conception, the control requirements for the noisy intermediate-scale quantum (NISQ) TIQP were those to allow characterization of quantum information processing with trapped ions. For that reason, experiments have not yet required much integrated functionality from its control system and the existing solutions have been able to satisfy the laboratory experimental needs. Yet in the long run, a bottom-up approach to the design of the control system of a TIQP will continue to generate standalone sub-systems designed for a specific experimental need opposed to the ultimate goal of scaling-up the system and executing a useful quantum algorithm. Furthermore, to move towards a fault-tolerant quantum processor (FTQP), the control system must enable feedback loops, be closely integrated to the quantum-objects, and reduce it’s current rack-based size, none of which we see fully satisfied by current control systems. Thus, there is the need to approach the design of the control system of QP with a top-down mindset.

[0008] Prior art is set forth:

[0009] US 11,748,649 covers an apparatus and method for specifying quantum operation parallelism.

[0010] US 2022 / 0150044 Al discloses a quantum measurement and control system comprising a network and a plurality of measurement and control subgroups.

[0011] DEGENHARDT C. et al. "Systems Engineering of Cryogenic CMOS Electronics for Scalable Quantum Computers". In: 2019 IEEE International Symposium on Circuits and Systems (ISCAS), p. 1-5, (26.05.2019). XP033574147. <DOI:10.1109 / ISCAS.2019.8702442> describes a SQuBICl, which is an IC device with a I2C protocol interface which directly drives digital to analog converters (DACs) and oscillators (DCO, VCO) to interact with a quantum dot. The single device test and the on chip window comparator on-chip measurement are not driven nor controlled by the I2C protocol interface.

[0012] GEBAUER R. et al. "A modular RFSoC-based approach to interface superconducting quantum bits". In: 2021 International Conference on Field Programmable Technology (ICFPT), p. 1-9, (06.12.2021). XP034028257. <DOI:10.1109 / ICFPT52863.2021.9609909> describes a modular FPGA-bases system, featuring the digital unit cell (DUC), with a master-slave bus topology: the Wishbone interconnect, centrally controlled by the RISC-V-based sequencer, andwhich contains all logic to interact with a superconducting qubit. The DUCs are interconnected via a master-slave bus: the AXI4Lite interconnect. This is a device in an FPGA driven directly and controlled from a control computer.

[0013] FU X. et al. "An experimental microarchitecture for a superconducting quantum processor". In: Proceedings of the 50th Annual IEEE / ACM International Symposium on Microarchitecture, New York, USA: Association for Computing Machinery, p. 813- 825, (14.10.2017). XP080954511. <DOI: 10.1145 / 3123939.3123952> describes a control microarchitecture: the QuMA, which implements the von Neumann model of computation by reading instructions out of the main memory (instructions & data), with an instruction fetch mechanism driven from an execution controller, which is an embodiment of a central processing unit (CPU) with an arithmetic-logic unit (ALU), instruction fetch, decoder, and register file. This QuMA core then drives various arbitrary-waveform generator (AWG) which exclusively transmit signals to the quantum objects, specifically superconducting qubits.

[0014] WO 2015 / 178992 A2 describes a centralized control system which multiplexes control and readout signals for qubits, each with a distinct operating or readout frequency.

[0015] WO 2023 / 208815 Al describes a computing device which embodies a von Neumann architecture because it consist of a processing unit and a storage device storing a set of instructions. It comprises a central controller system with one-to-one single connections to driver blocks and / or acquisition blocks which interact with a pool of qubits.

[0016] Summarizing, there is a high need for a blueprint for the system-level architecture of a scalable control system of a quantum processor. The latter will enable the stand-alone design of subsystems with the mindset of being ultimately compatible and integrable into the full-control system.

[0017] Short description of the invention

[0018] Thus, the object of the present invention is to identify and create a scalable architecture for the control system of a quantum processor, and a solution is provided by a system (architecture) and specific components for controlling a quantum processor which serves as an accelerator within a higher hybrid computing system.In a first aspect, the present invention provides a backbone entity for a system for controlling a quantum processor, wherein the backbone entity comprises utility cores comprising

[0019] • a network interface core connected to a network,

[0020] • a service core connected to all other cores within the backbone entity and connectable to a design for test system via a port, wherein the service core is configured to self-test and / or calibrate all cores within the backbone entity,

[0021] • a power core configured to dynamically scale power areas connecting a plurality of cores of the backbone entity,

[0022] • a time core configured to synchronize the local time of the backbone entity with the global time of the network and broadcast the local time to the other cores of the backbone entity, preferably the time core comprises a phase locked loop, • a memory management unit core configured to manage the mapping between virtual and physical memory and make the memory accessible to read and write, • and an opcode-core connected to all other cores within the backbone entity and configured to function as a central router, and preferably to configure register maps of the backbone entity and preferably to read and write memory to the memory management unit core,

[0023] wherein the backbone entity optionally further comprises one or more transmission core(s), wherein the transmission cores are connected to the memory management unit core and are selected from the group consisting of a transmit core, a receive core, a driver core and a monitor core, wherein the backbone entity is configured to be driven by an instruction from a hardwarespecific instruction set architecture, wherein the network interface core is configured to unpack or pack a network package from the hardware-specific instruction set architecture and extract or insert the time-stamped instructions, wherein the opcode core is configured to route the extracted time-stamped instructions to the corresponding cores within the backbone entity.

[0024] The backbone entity according to the invention is a novel aspect in the inventive system for controlling a quantum processor and ensures the systems scalability. The backbone entity is the smallest essential technical part in the control -system or may be itself the control -system of a quantum processor. Multiple backbone entities can be combined to increase the size of the controlled quantum system with increasing numbers of these entities. The backbone entity may be used as a transmission entity in the inventive system.With the aid of the backbone entities, it is possible to construct an architecture of local entities where each core decodes and executes instructions from a hardware-specific instruction set architecture for computation of utility operations of a quantum processor. This allows to execute e.g. a quantum algorithm composed of layers of gate operations.

[0025] Further, the backbone entity may be an integrated circuit, also referred to as a chip. Each core or sub-component of the entity may be a reusable unit of logic / cell that describes a component in an integrated circuit. Each core is a processing unit. Preferably, each core in the entity is instantiated on demand, depending on the task to fulfill. Preferably, the entity is constructed based on a template, wherein the physical space is available for each of the potential cores described herein. Preferably, the entity has a layout with blocks for all transmission cores selected from the group consisting of a transmit core, a receive core, a driver core and a monitor core, which blocks are either filled or empty. This allows for simple mass production of the base structure and modular adaptation of the integrated circuit for individual types of backbone entities as required in the system. The utility cores represent parts of the backbone entity required for integration in the overall system. Hence, these features are mandatory in the backbone entity independent from the type of backbone entity. The transmission cores are instantiated on demand, depending on the transmission task to fulfil by the entity.

[0026] In a further embodiment, the backbone entity may be implemented as a field-programmable gate array (FPGA), i.e., an array of logic gates that are reprogrammable in which the cores are mapped to configurable logic blocks and interconnect resources that can be programmed or reprogrammed to realize the required transmission and utility functions. In an alternative embodiment, the backbone entity is implemented as a complex programmable logic device (CPLD).

[0027] The manufacturing concept of integrated circuit entities may comply with the methods of Chiplet design and heterogeneous integration packaging. The strategy is to manufacture most the backbone entities and / or cores as volume mass-production Chiplets and integrate them with some other non-volume custom transmission Chiplets design using heterogeneous packaging methods. For integrated circuit entities placed at room-temperature, standard packaging is thought to be used. For integrated circuit entities placed in harsh environments such as cryogenic or baked at high temperatures, the package of these must be sturdy enough and must shield EMR via a sort of Faraday-cage type design. This manufacturing method gives thearchitecture greater flexibility, scalability, and cost-effectiveness; and enables multiple development teams to collaborate. The only reasonable & industry-proven method to reduce the size and minimize power-consumption / dissipation of the over-head of control devices a quantum processor needs to execute a useful quantum processor is by adhering as close as possible to the integrated circuit mass-production volume approach. In this regard, the template lego-like approach of a backbone entity allows blocks of the integrated circuit to be volume mass-produced and other custom design blocks to be integrated at a reasonable extra interface area and packaging cost.

[0028] The utility cores comprise a network interface core, which may be a network or bus interface. From the perspective of each entity, the outer system may be the NoS. Preferably, the entity is connected to the NoS via the network interface core. The network interface core may unpack or pack the network packages extracting or inserting the hardware-specific instruction set architecture package within. For an incoming package, the network interface core can check if the delivered package matches its network ID before forwarding it to the internal system for distribution. The hardware-specific instruction set architecture package is transmitted through the internal cores via a ping-pong-forward (PPF) mechanism. The PPF mechanism refers to the receiving core within an entity checking if the hardware-specific instruction set architecture package matches its opcode range, if yes then it holds the instruction for execution, if not it forwards it to the next recipient. The network interface core can also prepare and pack a time-stamped package to be transmitted to other entities.

[0029] The utility cores further comprise a service core, that may be also called built-in self-test (BIST) core, which is configured mainly to test the backbone entity’s functionality and manage initial setup. In a preferred embodiment the service core is connected to all other cores within the backbone entity and configured to self-test and / or calibrate all cores. The service core is intended to be mostly used during the setup-cycle, but it maybe also used during run-time for test purposes. It is used to execute all tasks related to the design for test (DFT) module and may be based on the IEEE 1149.1-2013 standard. The DFT tasks are mapped to the service core at each entity and used during manufacturing tests, the setup-phase, and during run-time for calibration, and reporting purposes. Preferably, this core has a direct connection to all cores within the entity to access them for self-test purposes and calibration. Similar to the service entity of the system described below, it can be connected to a DFT system.A further utility core is given by the power core, which manages the power- or clock-gating of power areas at the entity level. Preferably, the power core is connected to the service core and also to the DFT system. It is thought that some power areas in each entity can be put in a clockgating stand-by mode during the execution of an algorithm to avoid noise or heating coming from this area of the entity during computation. For example, a first power area may be intended to be on only during the set-up cycle of the processor and a second power may be turned on if the entity belongs to the active resources needed for a given algorithm.

[0030] The time core manages the clock and reset signals as well as the local-time notion at the entity level. This core may hold and track the work-cycle of the system, synchronize the local-time of the global-time by continuously running synchronization protocols, and broadcast its local -time to all cores within the entity. It generates a phase locked high-frequency clock for physical clock generation at which the entity runs, locked to the systems’ clock, preferably through a phase locked loop (PLL). Alternatively, the time core may comprise a voltage-controlled oscillator (VCO).

[0031] Note that the local time is a logical time with timestamps embedded in hardware-specific instructions, which is based on the physical clock. Preferably, instructions are timestamped with numbers corresponding to algorithm layers or refined with finer granularity after decomposition into hardware-specific instructions.

[0032] The utility cores further comprise a memory management unit core, which is configured to manage the mapping between virtual and physical memory. Through this core the memory is also accessible for read and write, note, however, that memory write is preferably done via a build-in self-test module before run-time. Preferably, the memory management unit core is also configured to configurate register maps of the backbone entity. The configuration of the cores register maps can be done after reset and at the incoming of a hardware-specific instruction set architecture command. The configuration broadcast may include retrieving their configuration from memory, packing them for network distribution, and forwarding them to the opcode core. From there they can be distributed to the cores in the local entity.

[0033] The opcode core is a central element of the backbone entity and the master or arbitrator of the backbone entity, and it functions as a central router for packages as it is connected to the network interface core. Thus, it is the central communication router for the backbone entity. Preferably, it is designed so that it allows the configuration of the entity's register maps afterstartup or reset by retrieving its configuration from memory. In an alternative embodiment, this task is assigned to the memory management unit core, as explained above. Further, any process that needs to synchronize the transmit core and / or receive core or neighboring entities that need to synchronize may use the central opcode core to do so. Thus, preferably the opcode core is connected to all cores within the backbone entity.

[0034] Optionally and preferably, the backbone entity comprises one or more transmission core(s). The transmission cores may be a transmit core, a receive core, a driver core or a monitor core. A backbone entity may comprise any combination of transmission cores. The term transmission core refers to the part that has a send or receive activity towards or from the quantum system. Given that the transmission cores either extract data from memory for digital signal processing or write data to memory after digital signal processing, each transmission core has a direct link to write and / or read memory. That is, each transmission core is configured to read and / or write to the memory management unit core. In most cases, the transmit and driver core has a readonly memory port, and the receive and monitor core has a write-only memory port.

[0035] All transmission cores are instantiated by demand based on the functionality of the backbone entity. In the usual case, each entity accomplishes one functionality, therefore has either a send or receive activity towards or from the quantum object. The receive and monitor core receive signals from the quantum system, whereas the transmit and driver core send signals to the quantum system.

[0036] The receive core may have a data port, this is needed for the case of an entity being a quantum error management unit. Usually, this data port transmits a syndrome in the case of quantum error correction or the actual result of the measurement in the case of quantum error mitigation. The transmission cores may have direct access to the memory management unit core for these cores are required to generate all data streamed towards the quantum object based upon matrices or parameters stored in memory. Thus, in memory no long sequences of shots have to be stored, all streamed data can be generated in real-time.

[0037] The receive core and the transmit core can be further connected with the opcode core through a dynamically time ordered pipe interface (DTOP), configured to push the time-stamped instructions at the time-stamped time into the receive core and the transmit core, respectively. In the backbone entity the DTOP forms a separate hardware block inserted between the opcodecore and the transmit core and receive core, respectively. Thereby, the dynamically time ordered pipe interface may consider the internal-data path of the transmission core. The DTOP, as its name suggests, is a hold-pipe of hardware-specific instruction set architecture instructions which is dynamically re-ordered in real-time according to the time-stamp of each incoming hardware-specific instruction set architecture. It then pushes the instructions at the time-stamped time into the transmission cores for execution. All other cores track the time-stamped execution of their instructions, and preferably only the time critical transmission cores may have this external pipe.

[0038] Thus, the DTOP is a synchronization pipe of the time-stamped instructions. Note that these time-stamped instructions can also be delayed and interleaved by other instructions. Thus, the DTOP may be configured to manage the delays of these instructions in the pipe and possibly the interleaving of instructions in the pipe.

[0039] Whenever the backbone entity is used for interaction with the quantum system, it also comprises an analog front-end (AFE). The AFE handles all digital-to-analog converter (DAC) / — analog-to-digital converter (ADC) activities and any other ASP / OSP needed. In this case the backbone entity comprises a receive core and / or a transmit core, which are connected to the AFE. Further, if the backbone entity is interacting towards the quantum system, the AFE controls a transducer, which interacts with the quantum system.

[0040] Preferably, the backbone entity can send instructions to any other entity within the network. This may be done via the network interface core. The instructions may originate from any core within the backbone entity. Further, any core within an entity may send instructions to any other core within the entity. Each core may decode the instructions particular of that core.

[0041] Further, the backbone entity can send a global delay to all or a subset of entities in the network that delays the time-stamp execution of instructions. The global delay may be broadcast via a global delay hardware-specific instruction set architecture message. The global delay may be in relation to the time stamp of the instructions, which makes reference to the algorithm circuit layer step. Further, the global delay may mostly affect the DTOP as it may dynamically re-order and / or delay the DTOP. Preferably, the global delay is propagated throughout the network with top priority.The invention further provides a router entity for a system for controlling a quantum processor, wherein the router entity is configured to re-direct hardware-specific instruction set architecture packages, wherein the router entity comprises

[0042] • a network hub port connected to a network and at least one backbone entity within the network, wherein the network hub port is configured to re-direct time-stamped network packages from the hardware- specific instruction set architecture packages, • a switch core connected to the network hub port and configured to route the network packages,

[0043] • a service core connected to all other cores within the router entity and connectable to a design for test system via a port, wherein the service core is configured to self-test and / or calibrate all cores within the router entity,

[0044] • a power core configured to dynamically scale power areas connecting a plurality of cores of the router entity and / or the power of the whole router entity,

[0045] • a time core configured to synchronize the local time of the router entity with the global time of the network and broadcast the local time to the other cores of the router entity, preferably the time core comprises a phase locked loop.

[0046] The router serves as a switching device to route packages and may serve as a temperature crossing point of data and clock. It also comprises a time and power core to regenerate the clock and keep track of power related configurations of the router. Further it comprises a service core for self-testing and calibrating and executing all DFT related tasks like manufacturing, debugging, and start-up tests and fill or read-out memories. These cores work analogously to the corresponding cores of the backbone entity. It may have many backbone entities connected through a network hub port to re-direct the network packages. This may also include the transmission of global delay packages. The main switching activity is mandated by a central switch core which may be priority-based on the opcode and time-stamp of each network package. Thus, the switch core reroutes the network packages with a specific priority according to the opcode or also according to the global delay. In certain embodiments, the router entity comprises an analog back-end (ABE) where the multiplexing / de-multiplexing and the conversion between electrical and optical signals takes place and preferably an opto-electro management unit (OEMU) directing the conversion. The optical interface allows to transfer information across different temperature zones. In this case the router entity is a temperature crossing router entity. Note that there is a split of the temperature crossing point of signals related to the DFT module and another crossing point for all other signals. In the case of atemperature crossing router entity the service core acts as a repeater of the DFT port to the temperature zone it is in.

[0047] Further, any backbone entity or router entity may be configured to be trained and adapted. This training and adapting may be algorithm specific. More precisely, at the beginning of the workcycle the system is setup and configured for the specific algorithm. In this case the execution of an algorithm will be previously trained to optimize its execution. Thus, the optimal system configuration for the execution of that given algorithm can be found and the backbone entities and router entities adapted according to the optimal system configuration.

[0048] Preferably, the entities fulfil at least one property out of the group consisting of the properties, which make them particularly useful in the context of quantum processors: baking-temperatures static tolerant, cryogenic-temperatures functional tolerant, very low power configured to not increase the physical temperature of the environment during run-time, faraday-cage shielded package of the entities configured to avoid electromagnetic interaction with the ions, and as small die-area as possible.

[0049] For example, when controlling a TIQP, for a backbone entity the transmit core may be configured to generate a signal for DC and RF electrodes for confinement and / or manage the laser signal generation including turning on / off Laser sources and / or generate RF voltages to feed acousto-optic modulators where lasers shine on. That is the main functions of the transmit core may be in certain embodiments the AC-RF and DC signal generation for the confmement / transport electrodes, the management of computation / cooling operations which includes the on / off of LASER sources and the generation of AC-RF voltages to feed the acousto-optic modulators where the lasers shine on for optical qubits. Additionally, the transmit core may be also configured for the generation of microwave radiation. This is especially useful in the case of microwave-driven quantum logic for hyperfine qubits.

[0050] In another aspect of the invention a system for controlling a quantum processor is provided, the system comprising utility entities, router entities and backbone entities as nodes of a network, wherein each entity in the network is connected to at least one other entity, and comprising at least one transducer configured for interacting with quantum objects of a quantum system, wherein the utility entities comprisea main interface configured to receive a sequence of instructions, translate the instructions to a sequence of hardware-specific instruction set architecture packages and schedule the instructions from the hardware-specific instruction set architecture packages with a time-stamp, a time entity configured to hold the global time and synchronize local times in all entities of the network,

[0051] a power entity configured to dynamically scale the power of individual entities within the network and preferably configured to dynamically scale the power of hardware resources of the network,

[0052] and a service entity connectable to a design for test system via a port and configured to test and / or calibrate the entities and / or read and write memories to the entities,

[0053] wherein the router entities are configured to transport data across the network, wherein the backbone entities are configured

[0054] to interact with the quantum system and comprise an analog-front end configured for said interaction and / or

[0055] to process incoming data from the quantum system and / or

[0056] to store incoming data from the quantum system.

[0057] Said system combines a set of utility, router and backbone entities, i.e. a scalable controlling system for a quantum processor. The system architecture is a network of distributed entities. The system can be seen as one processor composed of mini-incomplete processors, i.e. the entities, and the system is synchronized via the time-stamps.

[0058] Each sub-system in a quantum processor (QP), which is defined by accomplishing a specific functionality, is composed of an interconnected set of entities that in conjunction perform the required functionality. Yet each QP targeting a specific set of algorithms will have a configurable physical architecture for its control system, but it is all based on the same backbone functional and architectural concept of interconnected entities. It may be configurable through the mechanism of powering on-off entire sets of entities or single entities for the specific algorithm to be executed during the run-time of the QP.

[0059] Each entity in the system accomplishes part of a sub-system’s functionality, thus is labelled accordingly.Preferably, the system uses a network-on-system (NoS) to communicate internally. The NoS may be priority-based and low-power. Each entity is a node in the network, preferably has a network-ID, and an interface to receive and transmit hardware-specific instruction set architecture packages to any other entity in the network thus enabling cross-entity communication. The network uses routers to transmit the internal instructions to the target entity.

[0060] Further, the network may maintain priority of packages, according to a priority ranking of the hardware-specific instruction set architecture. The input instruction stream is captured by the main interface. It may receive the sequence of instructions, which may be time-stamped, from an algorithm-request hardware, schedule the computation, and respond with the computation result. Preferably, the response of the quantum algorithm is stored in the result entities and at the end of the execution of N repetitions of the quantum algorithm the results can be bulked out via the service system. The results may correspond to data that will map to a probability distribution. In certain embodiments the input instructions may be a set of instructions that map to quantum gate operations. The main interface translates these input instructions to a sequence of hardware-specific instruction set architecture packages, which are scheduled as time-stamped instructions. The sequence of hardware-specific instruction set architecture packages are then distributed to the appropriate entity for a time-stamp accurate execution. Preferably, the input instruction stream is also time-stamped and the main interface decomposes this input instruction stream into many instructions, that is the hardware-specific instruction set architecture packages, with a time-stamp that is relative to the received original time stamp.

[0061] Preferably, each entity of the system has a device-ID which makes it known to the system-level what set of instructions this device reacts-to and executes, and identifies its sub-system membership that defines the reason for its existence in the system. Part of the start-up check may be to retrieve all the device-IDs of the active resources, this is the check-in of the entities. With the help of the device-IDs it is possible to define the instruction set architecture of the entire system.

[0062] An entity of the system can be one of three types, either a utility entity, a router entity, or a backbone entity. The utility entities are namely the main interface and the service / power / time entities. These utility entities can be replicated if needed in different temperature zones. This allows to locally manage the entities in the temperature zones. The router entities are used asthe transport backbone of data across the system. The backbone entities may derive from a generic entity and are preferably either a transmit entity, a receive entity, a quantum error management entity or a result entity. The backbone entity may be a transmission entity configured to interact with the quantum system and comprising an analog-front end configured for said interaction and / or to process incoming data from the quantum system and / or too store incoming data from the quantum system.

[0063] For example, a transmit entity performs measurements or manipulations on a quantum-object or it’s environment and a quantum error management entity implements the signal processing for quantum error correction purposes. Further, a result entity may store the results of the computations across multiple executions of an algorithm, whereas the receive entity detects measurements of the quantum object or the environment. Note that signal processing activities are realized by all entities, and especially the backbone entities have strong signal processing data-paths. To interact with the quantum system the backbone entities may have an electronic or optical interface. Specifically, the transmit and receive entities must have one, thus these contain an analog front-end facing the quantum objects.

[0064] Further, the system comprises a time entity. The time entity is a utility entity configured to keep track of the global time and update the system on a regular basis to synchronize the local times in all entities. The time entity keeps the notion of time within the processor so that all entities can synchronize to a global-time and thus wait and execute each time-stamped instruction accurately and precisely at their local-time. On each entity in the system a corresponding time core exists to keep the local time. Via the use of time-stamped hardware specific instruction set architecture it is possible to have a notion of time for the quantum processor so that all entities can wait and execute each time-stamped instruction accurately and precisely. The time entity may keep track of the work-cycle mode (setup, sby, work, rep) the processor is in, defines the notion of global-time at the system-level, and synchronize it to the local-time in all entities.

[0065] Preferably, the global clock is continuously synchronized across the system to make sure all entities have their local-time synchronized to the global-time within a defined accuracy so that the hardware specific instruction set architecture is timed-accurately executed.

[0066] Further, the system comprises a power entity, which is a utility entity configured to dynamically scale the power of entities and preferably hardware resources. The capacity to dynamicallyscale the power of entities as understood herein includes turning individual entities independently from each other on and off as well as dynamically scaling their power consumption down and up. Preferably, the power entity directly controls local-power blocks at each entity, which allow execution of all activities related to the power management. For example, the power entity allows scaling the system up or down or turning on and off certain hardware resources. Thus, with the help of this entity it is possible to scale the hardware resources of a quantum processor to those needed to execute a certain quantum algorithm by powering them on and off. Therefore, each quantum algorithm may have a power map, which is defined as the physical hardware resources to be turned on or off for the execution of said algorithm. Preferably, via power-gating or clock-gating techniques the power entity activates or deactivates parts of the system that are not needed for the execution of the algorithm. Further, via the power entity it is possible to scale the power of entities, parts of entities or other hardware resources down during time steps in the algorithm, where these parts are not needed. Summarizing, the power entity enables a low-power system with a very good power management.

[0067] The service entity, which may be also called BIST-entity, is an entity taking over functionalities of the service of the system and could also be referred to as main-service entity. As such it enables debugging and testing and calibration of the system as well as memory fill in and out. Instead of adding a new backbone communication scheme, it is possible to re-use the same design for test (DFT) system constantly via connecting the service entity with a DFT system via a port. Note that the DFT system may also referred to as the service system.

[0068] Thus, the same DFT methodology can be adopted for: manufacturing, debugging, stat-up tests, as well as for data pre-load. The latter entails that all entities preferably support DFT capabilities so that: the entities can be tested against manufacturing errors, the entities can have debugging means during development, evaluation, and deployment phases, the system can verifies whether hardware resources are active and responsive (an automatic all start-up hardware check is run to make sure all active resources are indeed active and responsive, where each entity can check-in and be equipped to test itself and only report back if malfunctioning), the entities memories can be bulk-in filled, the system can run full / sensitive calibration of all sub-systems / entities, and the system can bulk-out the measured results stored in memories. Summarizing, this utility entity aims to provide for the control system means to test itself and rule out errors injected by the malfunctioning of the control system in order to provide a reliablecontrol to this already error-prone system. Preferably, the service entity maps to local service blocks, that is the service cores, in each entity.

[0069] In a certain embodiment of the system the entities may be distributed among at least two, preferably three temperature zones, wherein router entities from different temperature zones are connected via optical crossing connections and comprise an analog back-end facing the optical crossing connection.

[0070] For example, the different temperature zones may be connected via temperature crossing router entities. The temperature crossing router entities have an optical interface, thus these comprise an analog back-end facing the optical temperature crossing. The system can be distributed e.g. across room (~300K), vacuum chamber (~120K), and cryostat (~30K) temperatures. Preferably, each entity may have a membership to a temperature zone trough a temperature ID. The entity’s power management and environment compliance may be tested against those of that zone. If needed the utility entities can be replicated in each temperature zone, or there can also be one centralized control in one temperature zone comprising all utility entities.

[0071] Between temperature zones optical crossing connections are preferred. The latter implies that at the temperature border crossing an electrical -optical transformation of the data has to take place. For crossing temperature zones there may be temperature crossing router entities with an optical interface, thus, comprising an analog back-end facing the optical temperature crossing. Further, these router entities also have an opto-electro management unit, where the multiplexing and de-multiplexing and the conversion between electrical and optical signals takes place.

[0072] The system may be split in power zones, wherein the power entity dynamically scales the power of entities in different power zones. Each entity may have a membership to a power zone. A power zone is a grouping of entities that have a common objective or are in a close physical location or it can be also a single entity. These zones are directed by the central power entity which scales the system up or down, e.g. turns on or off hardware resources, at the setup-phase of the processor by giving the possibility to address many entities at once.

[0073] Preferably, each entity comprises a power ID referring to a power zone. In the example of a trapped-ion quantum processor, in most cases a set of entities is needed to manage an ion-trap section of a trapped-ion quantum processor, therefore all entities needed for a given section willshare the same power zone. With the help of the power ID one can define power zones that include a set of entities. For example, one power zone could be given by entities with power IDs 1, 2 and 3.

[0074] For any given algorithm only the required resources in the processor may be turned on and active during run-time. Therefore, this architecture proposes an quantum processor which physically scales and changes its physical configuration based on the algorithm which is executed during its run-time phase. Each entity may have a power ID and it may be turned on and off at the set-up cycle according to the algorithm specific resources requirements. Therefore, the system scales up or down during the setup-cycle. The turning on and off of power zones also takes a ramp up / down time for the processor resources, all this logistic is preferably dealt by the power entity in the system.

[0075] Router entities can be also powered down if all entities attached to it are not part of the active resources. Between boarder crossings, the electrical-optical transformation can be pushed from or to a router entity with a transducer interface. At the temperature crossing router entities, the transmission of optical data can benefit of frequency and / or phase multiplexing protocols.

[0076] In another embodiment the system may comprise an algorithm management unit (AMU) configured to translate an algorithm computation request into a sequence of instructions, which are preferable time-stamped and which may correspond qubit gates, and send the sequence of instructions to the main interface. The AMU can be a low-level hardware device that accepts algorithm requests from a higher hybrid-computing system and executes it with a quantum processor or a set of quantum processors. This allows to move the algorithm execution to the hardware layer.

[0077] Another aspect of the invention is given by a controlling method for a quantum processor, wherein the method is for controlling a system as defined above. The controlling method controls the execution of a quantum algorithm at the hardware level via a time-stamped based synchronization of all entities of the system, wherein the scheduled instructions from the hardware-specific instruction set architecture packages are time-stamped and internally distributed to the intended entities for time-accurate execution.The method may control the execution of a quantum algorithm at the hardware level via a time-stamped based synchronization of all entities of the system. The execution of a quantum algorithm can be dynamically delayed by a global delay broadcast to the entire quantum processor.

[0078] For the controlling method the time and power cores in each entity of the system may be controlled centrally by the time and power entity. The power entity controls the dynamical power scaling of specific entities split in power zones. The time entity holds the global time and controls the synchronization of the local times in all entities of the system. This can be done by continuously broadcasting the global time to all entities within the network and synchronize it to a given accuracy.

[0079] Preferably, the power entity scales the power according to the algorithm to be executed by the quantum processor. This can be done with the help of a pre-defined amount of physical resources, which can be called the power map of the quantum processor, needed by the algorithm to be executed.

[0080] Furthermore, it is preferred that the service cores comprised in individual entities may be centrally controlled by the service entity. In analogy to the BIST entity as service entity, the BIST cores may be generally referred to as service core. The service entity is configured to access and direct the design for test (DFT) system. Each entity has a corresponding service core to allow manufacturing tests, and all tasks related to the design for test. Via this it is possible to debug and test the system. The design for test module comprises the following tests: manufacturing tests, debugging tests, start-up automatic test, and data pre-load. The latter means that all subsystem will include DFT capabilities so that: the devices can be tested against manufacturing errors, the devices have debugging means during evaluation and deployment phases, that at the start of every setup-phase the processor runs an automatic start-up check to make sure all active resources are indeed active and responsive, and memories and big-data transfers are carried out through this system before the algorithm-phase. Preferably, the service entity allows to

[0081] • test the entities against manufacturing errors,

[0082] • check if all hardware resources are active and responsive,

[0083] • bulk-in write the memories of the entities,

[0084] • check if the memories of all entities of the system are correctly filled,• run a calibration of all entities of the system,

[0085] • and bulk-out measured results from memories of entities of the system.

[0086] Preferably, the calibration is in accordance with the quantum system state and predefined calibration sequences in the memories.

[0087] Given that there are so many error injection means to a quantum system, the control system is preferably tested at the beginning during a setup-phase to make sure that all its components pass the start-up test. The intention is to rule out errors inj ected by malfunctioning of the control system and to provide a reliable control to this already error-prone quantum system.

[0088] Another aspect of the invention is an operating method for controlling a quantum processor, wherein the method is characterized by implementing a pre-defined and preferably pre-trained limited set of quantum algorithms to be performed on the quantum processor.

[0089] The operating method may be applied on the inventive system. It may comprise a setup-time and a subsequent run-time, wherein during the setup-time the method comprises the steps • choosing a run-time algorithm out of the set of quantum algorithms,

[0090] • scaling all entities and hardware resources to those needed for the execution of the runtime algorithm,

[0091] • self-testing and calibrating all entities and hardware resources needed for the execution of the run-time algorithm,

[0092] • synchronizing local times in all entities of the system,

[0093] wherein during run-time the method comprises the steps

[0094] • waiting for an algorithm execution request,

[0095] • executing the algorithm N times, where N is preferably larger than 10A3,

[0096] • reporting the results of the algorithm execution.

[0097] The system starts in the setup-phase, wherein the steps of the setup-time ensure that the preassigned resources required for a specific algorithm are initialized, i.e., become active resources (power scaling). Thus, this allows for a system that scales its resources based on the specific run-time algorithm. This may also include that for the active resources, memories are filled, register maps are configured and active resources check-in in the system. Part of the start-up check may be to retrieve all the device-IDs of the active resources, this is the check-inof the entities. This may be referred to as the device map, which ultimately reflects in a network map. Further, the self-testing and the calibrating of the entities can be coordinated in the setup-time. Preferably, the entities do the calibration and the self-testing themselves.

[0098] During run-time, the system waits for an algorithm execution request, which is preferably in the form of an instruction set architecture for algorithms. After receiving the algorithm request, during run-time the system may undergo another sensitive calibration. The difference between the full calibration in the setup-time and the sensitive calibration in the run-time is the number of parameters calibrated, and thus correlates to the amount of time it takes. For example, the Sycamore-72 superconducting-circuit QP needs about one week for a full calibration. A sensitive-calibration only calibrates parameters of key importance, those initially calibrated parameters that drift more often as a function of time.

[0099] At the end of the run-time the results of the algorithm execution are reported, which may imply bulk out of all the data which describes a probability distribution.

[0100] In prior art general -purpose quantum processors are used, which are not algorithm-specific. In contrast to that, here an algorithm-specific quantum processor is suggested, which affects how the control system works and operates its entities. This method to control the quantum processor allows for the processor to serve as an accelerator within a higher hybrid-computing system. Preferably, in this method only quantum algorithms that show a quantum advantage over classical counterparts are executed. For the method the quantum processor has then a supported set of quantum-algorithms, that is a pre-defined and preferably pre-trained limited set of quantum algorithms. Pre-training refers to pre-defined configuration settings, meaning that the quantum processor is pre-trained to execute the supported set of quantum algorithms. The quantum processor may be pre-trained such that it has the right configuration parameters for a given quantum algorithm. During run-time, the processor is preset to compute only one algorithm of those within the set, accordingly during run-time it accepts algorithm-computation requests of the run-time algorithm only. What may vary across algorithm-computation-requests are the operands of the algorithm or its settings or parameters.

[0101] Changing the run-time algorithm to another one within the set may be possible via a restart and rescaling the processor to that new run-time algorithm. The processor operated via the inventive operating method is thus a gate-based computation processor which is run-time algorithmspecific, i.e. quantum instruction set architecture (QIS A) sequence specific, and not a run-time general processor.The control system must preferably be able during setup-time to scale the hardware resources of the processor according to the run-time algorithm. The latter gives the benefit of aiming to support predefined sequences of QIS A instructions, that maps / scale to as much active hardware resources as the algorithm requires.

[0102] Preferably, each algorithm has a pre-trained quantum error correction algorithm running concurrently. There is the possibility to pre-train the processor to cope with errors by e.g. concurrently running in the backstage a quantum error correction (QEC) circuit (algorithm) fully tailored to accompany the run-time computing algorithm according to the allocated resources. So that, each pre-trained computing-algorithm supported by the quantum processor has an accompanying pre-trained QEC-algorithm running concurrently in the backstage to perform real-time QEC. This embodiment suggests that the control system runs two concurrent synchronized algorithms: one for computation and one for error correction. The control system must then be able to dynamically react to the QEC algorithm running in the real-time in the backstage.

[0103] Further, the operating method is applied on a system as described above. Thus, the system is such that it only controls algorithm-specific quantum processors.

[0104] Further, the system can be interfaced to an external computing device via an algorithm management unit (AMU), wherein the AMU translates an algorithm request from the external computing device into instructions for the quantum system, preferably the gate operations the system must apply on the quantum system.

[0105] Summarizing, the knowledge-gap in the control system of quantum processors is addressed by the inventive idea by pivoting on a top-down design methodology to achieve the goal of describing a system-level scalable architecture for the control system of a quantum processor.

[0106] The inventive system is fundamentally different from currently existing control systems, as known control systems aim to execute a von Neumann type control methods and architecture, that is, a CPU reading a sequential executed program out of a memory. Or do this previously and then download the pre-compiled shot sequence to hardware accelerators implemented in FPGAs to execute the static sequence. Very differently, this work has introduced a way ofcontrolling a QP machine, which is not a von Neumann architecture nor methods. It has to be highlighted that for the inventive system and method: there is no central memory; there is no central processing unit (CPU); there is no centralized single-thread execution of a one sequential program; there is no read-out of instructions from a memory one after the other. In a nutshell: this is not the von Neumann architecture.

[0107] Detailed description and preferred embodiments

[0108] The foregoing and other objects, features and advantages of the invention will become more apparent from the following detailed description, which proceeds with reference to the accompanying figures.

[0109] Fig. 1 shows an exemplary architecture diagram of a backbone entity.

[0110] Fig. 2 shows an exemplary architecture diagram of a router entity.

[0111] Fig. 3 shows an example of a system-architecture blueprint of the system for controlling a quantum processor.

[0112] Fig. 4a and 4b depict an algorithm-specific quantum processor (ASQP) including an algorithm management unit (AMU) for a single quantum processor (Fig. 4a) and multiple quantum processors (Fig. 4b).

[0113] Fig. 5 shows a system-concept diagram of the control system of a quantum processor.

[0114] Fig. 6 shows the physical mapping of integrated circuit (IC) entity’s electrode-domains in a quantum charge-coupled device trapped-ion quantum processor.

[0115] Fig. 7 shows an exemplary sub-system-level architecture for the ion-transport sub-system mapped to the inventive system-level architecture.

[0116] Fig. 8 shows a quantum error management entity.

[0117] Fig. 9 shows a result entity.

[0118] Fig. 10 shows a receive entity.

[0119] Fig. 11 shows a transmit entity.

[0120] Fig. 12 shows the concept of the main interface.

[0121] Concepts and examples

[0122] Concept 1: System-level features, definition of sub-systems and concepts of the inventive systemIn this section the main features and concepts of the scalable system-level architecture for the control system of a utility-scale & fault-tolerant QP are presented. Without loss of generality, here, we refer to a QP with a discrete variable unitary transformation evolution model, namely the circuit model of quantum computation. In this model, quantum computation is performed by applying a sequence of quantum gates to a set of quantum-objects with a specific initial state, all which is described by a quantum circuit.

[0123] The case-study uses trapped-ions as quantum objects, but this control-system can be extended to any other type of QPs. The main types of QPs are superconducting-circuits, trapped-ions, neutral-atoms, silicon-dots, and photons.

[0124] The system is a system-of-systems with a time-stamp based synchronization, it has a distributed-network topology, where each node is an entity, it may be operated and physically distributed across one or more temperature zones. Further, it may scale it’s hardware resources according to the run-time quantum algorithm, and execute the quantum algorithm at the hardware level with a set of seed quantum instruction set architecture (QISA) instructions, may aim to concurrently run quantum error management algorithms, and dynamically self-adapt their execution in real-time.

[0125] The system entails a mixture of electronic and optic components for data transport and computation. It has a top-down design methodology, thus each sub-system / entity can be standalone developed and tested but must maintain compatibility to the top level architecture. A subsystem is formed by a sub-set of nodes / entities within the network which accomplishes a specific functionality. The system relies at its core on microelectronic interconnected entities, e.g. an interconnection of system-on-chip (SoC) application specific integrated circuits (ASICs) entities. Each entity is driven by a hardware specific instruction set architecture, may test and calibrate itself, and can be powered on / off / down. With the inventive system it is possible to control a utility-scale O(106) amount of quantum objects needed to perform a useful quantum algorithm, hence we roughly estimate the amount of control devices to be in the O(103). For that scale of required control devices a cost-size-energy effective and reasonable solution is an industry proven mass-production ASIC -based control system, with a template-based approach for the entities. In this system an enhancement to a typical ASIC definition of an all-electronic based chip, is that some chips considered here may have integrated optical pre / post computing blocks called photonic integrated circuits (pICs). Preferably the QP is managed by a algorithm management unit (AMU) 20 as depicted in Figure 3a and 3b, that is the preferred mode for the QP to interact with the outer classic / quantum computing system. The AMU 20 may be driven by a Quantum-Algorithm Instruction Set Architecture (QA-ISA), that is an algorithm-levelrequest instruction-set. Each algorithm-level instruction contains a target quantum-algorithm and its operands and parameters, for example in the form: quantum algorithm(opl,op2,..., parl,par2,...), what changes from one request to the other are the operands and / or parameters. Thus, the QP may have a base-set of quantum-algorithms it has been pre-trained to execute, each with a pre-defined sub-set of it’s total physical resources. Yet the inventive system can also serve the control of QPs which choose to interact with the outer classic / quantum computing system directly via a QISA without an AMU 20. As to the number of computing levels of the controlled quantum-objects, the system aims to serve d = 2 (qubit) or any higher d > 2 (qudit) dimensional computational Hilbert-space, for all needed compensations are to be handled at the hardware specific instruction set architecture level. Finally, we acknowledge the impact of QPs: the economic burden the dawn of these have as deep-tech ventures in our society, the overall ecological-footprint of the QP, and the energy top-up the control system will add to the overall energy consumption of a QP. Thus, we have conceived a system that may reduce this impact by e.g. reducing the re-development of similar entity blocks across different quantum-object technologies, re-using circuit parts by core integration in a SoC, reduce energy consumption of the control devices by the power-scaling and resource-scaling features, and reduce cost per control-integrated circuit (IC) by a template-based manufacturing solution. Entities and / or cores are meant to be reused across various types of QPs and can be massed-produced thus reducing the cost. Also, the human-resources needed to build each entity / core for this control system can be distributed as well, thus enhancing a distributed economical growth and the best use of distributed human-talent across many development teams.

[0126] Sub -systems: Among the sub-systems in this system, we differentiate between quantum-object interaction sub-systems and others that are there for backbone utility purposes, thus called utility sub-systems. In this system-of-systems architecture, each quantum-object interaction sub-system fulfils one functional task of the QP. These functional tasks have an intrinsic data flow direction regarding the quantum-object. That is, either towards the quantum-object: transmit (TX), incoming from the quantum-object: receive (RX), or purely analysis of incoming data from the quantum-object for further steering of the system: a RX-signal processing (SP). Each of the sub-systems directs a given functionality of the QP and thus must accurately execute its task in synchronization with the rest of the sub-systems. The utility sub-systems are there to execute the tasks required to realize the backbone functional concept of the system as discussed below. The sub-system division also give us the possibility to use and evaluate standalone subsystems to test / experiment a specific functionality each as a standalone system. It also enablesthe standalone development of these sub-systems and / or entities across separate engineering groups, as long as system-level compatibility is maintained.

[0127] System-concept:

[0128] The aim of this section is to map the previously defined functionality, which describes the behaviour of the system, to conceptual modules. The modules description of the system includes both sub-systems for quantum-object interaction and for backbone utility purposes. From the established functional description, we recognize modular functionality in the system, which lead us to the system-concept diagram as depicted in Figure 5. The diagram is a conceptual description which aims to depict the system-level workflow for the processor, shown in the outer layer, and seven modules to map the functionality and utilities for the control system of the QP in the inner and central layers. The quantum-object interaction modules are the transmission (TRX) in / out, and the signal processing (SP) modules. The backbone utility modules are communication, design for test (DFT), power & time management.

[0129] The workflow of the QP is as follows, each full cycle is a work-cycle. During run-time, the QP accepts computational requests preferably of only one of the algorithms within the base-set, called the run-time algorithm. In the following the workflow of the QP is exemplary described for a QP with a run-time algorithm, that is an algorithm specific quantum processor. Note, however, that these concepts also hold for more general scenarios. The system starts in the setup-phase, which prepares the processor to execute the chosen run-time algorithms with the pre-assigned active resources (AR). Within a run-time cycle, the processor executes the standby, the algorithm, and the report phase. During run-time it enters first into the sby-phase, where the system waits for an algorithm-execution request. Once it receives such a request it triggers the processor into the algorithm-phase where the algorithm is executed N times with the given operators / parameters. Usually, N is in the order of millions O(106) to get a significant statistical distribution of the results. Finally, during the report-phase, the processor bulks-out the N result measurements to the upper-stack. In the following it is described how to map functionality to each conceptual module of the system.

[0130] During the setup-phase the first task is to pre-set the run-time algorithm from the limited set of algorithms.

[0131] In the following the modules of Fig. 5 are described in more detail.

[0132] Power module:

[0133] According to the executed algorithm this utility module scales the hardware resources of the QP to those needed to execute the algorithm by powering them on and off, these constitute theactive resources. Via the design for test (DFT) module the external setup-equipment accesses the control system and turns on or off or down all required entities. Further, the power management utility module may control and execute power-gating and clock-gating techniques to activate or deactivate parts of the system that are not needed for the execution of the runtime algorithm. The power scaling may also be done according to the pre-defined power resources of the run-time algorithm. The choice of either using a power-gating or clock-gating technique can be decided based on the temperature range where the entity is located. It has been shown that for CMOS digital systems working at cryogenic temperatures, there is no staticpower dissipation, therefore a clock-gating technique achieves the same as a power-gating technique. In terms of the Kelvin scale, the cryogenic region is often considered to be that below 120K ( 153 C). For all electronic entities working in environments above the cryogenic temperature range, static power dissipation is existent, and thus power-gating is necessary. As a power aware consideration, given the great amount of estimated 0(103) entities needed to control a useful quantum algorithm, all microelectronics in the system may adopt standard low-power design methods. Each entity can be assigned a maximum power consumption and dissipation budget, to which it must comply at manufacturing tests, and it is to be monitored during deployment by the power management system.

[0134] Design for test (DFT) module:

[0135] This utility module enables debugging and testing of the system. Instead of adding a new backbone communication scheme, one can re-use the same DFT system 42 already in place to access the entities during the setup-phase control actions. Thus, one can adopt a DFT methodology for: manufacturing, debugging, start-up tests, as well as for data pre-load. The latter entails that all sub-systems / entities must support DFT capabilities so that: the entities can be tested against manufacturing errors, the entities have debugging means during development, evaluation, and deployment phases, the system runs an automatic start-up hardware test to make sure all active resources are indeed active and responsive, where each entity checks-in and is equipped to test itself and only report back if malfunctioning, the entities memories are bulk-in filled, the system runs a full / sensitive calibration of all sub-systems / entities, and the system bulks-out the N measured results stored in memories. Summarizing, the DFT module aims to provide for the control system means to test and calibrate itself and rule out errors injected by the malfunctioning of the control system in order to provide a reliable control to this already error-prone system.

[0136] Communication module:This utility module covers both local, internal, and external-communication of the system. Via its local communication, each entity can configure its register maps and deliver instructions locally. The internal-communication preferably enables all entities to communicate. The external-communication refers to the interface facing the external hybrid classic-quantum computing system 22. From such system we expect an algorithm computation request, which is preferably translated by the algorithm management unit 20 to an Macro-QISA (M-QISA) sequence (see below) being pushed into the processor. The incoming M-QISA is translated to a set of hardware specific instruction set architecture-instructions, which includes not only quantum operations but also control and configuration related operations. These instructions may be e.g. from a local instruction set architecture (LISA). The seed-sequence execution of the main quantum-algorithm is very often delayed by the intertwined execution of quantum error management algorithms, thus it is needed that entities can generate and push into the internal-communication control hardware specific instruction set architecture -instructions to dynamically delay the quantum-algorithm execution and execute the operations to suppress and / or correct and / or compensate for the errors in real-time. Therefore, at the incoming interface of the processor an incoming M-QISA instruction may be translated to a hardware specific instruction set architecture sequence, e.g. LISA sequence, and scheduled for execution. The notion of instruction scheduling introduces then the concept of a time-stamped instruction for synchronization. All hardware specific instruction set architecture -instructions, e.g. LISA instructions, have a time-stamp so that the target entity accurately knows exactly when to execute that given instruction. These scheduled instructions are then internally distributed (dispatched and delivered) to the intended entity for time-accurate execution. In addition, we may also support cross-entity communication for real-time quantum error management. Across temperature boarders the data communication is to be transmitted optically, while within a temperature region the data is to be transmitted electrically. Each entity receives instructions via an interface to ultimately decode and execute the hardware specific instruction set architecture instructions. During run-time it is expected that the quantum error management entities generate hardware specific instruction set architecture instruction traffic to dynamically correct the run-time errors caused by the operations and environment. Thus, a global-delay is often broadcasted to the entire system through the internal-communication because of quantum error management purposes. If during ramp-up of this system it is discovered that the traffic in one sole internal-communication system is somehow limiting the throughput of the information, we may separate utility and interaction modules communications, each through an own internal-communication link. The benefit of separating the internal-communication systeminto links is dividing the load of traffic that is not critical from the algorithm critical -traffic, downside is the duplication of internal-communication systems leading to more devices and energy consumption / dissipation.

[0137] Time module:

[0138] This utility module keeps the notion of time within the processor so that all entities can synchronize to a global-time and thus wait and execute each time-stamped instruction accurately and precisely at their local-time. The synchronization of entities in this architecture takes place via time-stamped instructions. Thus, the time module may maintain the notion of physical time (via clock signals) and logical time (local-time / global-time) within the processor, enabling entities to synchronize and execute time-stamped instructions precisely. This module may keep track of the work-cycle phase (setup-phase, sby-phase, algorithm-phase, report-phase, see Fig. 5) and the task in each phase, define the notion of global-time at the system-level, synchronize it to the local-time in each entity, and execute regularly synchronization protocols to keep each entities local -time as accurate as possible to the global system-time. All hardware specific instruction set architecture -instructions, e.g. LISA-instructions, carry a time-stamp so that these can be executed in a timed-accurate manner by each entity. At the quantum processor level (e.g. algorithm-specific quantum processor), the logical time may correspond to quantum instruction set gate operations time stamped to a number corresponding to the layer in which is executed in the quantum algorithm. At the system level, these timestamps are preserved but refined with finer granularity, as each quantum instruction set instruction decomposes into multiple hardware specific instruction set architecture-instructions executed in a synchronized manner. For example, different entities execute operations in parallel and an individual entity executes layers of the quantum instructions sequentially. Thus, at the system level the logical time may be based on that which was timestamped in the received instruction from the quantum processor level, but in this case the one quantum instruction set instruction can be translated into many instructions timestamped in a finer grain time stamp step, because the quantum instruction set -instructions are decomposed in hardware specific instruction set architecture -instructions, e.g. LISA-instructions, which are at a lower level.

[0139] The global-time has to be continuously broadcasted across the system to make sure all entities have their local-time synchronized to the global-time within a defined accuracy and precision so that the hardware specific instruction set architecture instructions are timed-accurately executed. For example, the clock synchronization may be executed once during the setup-phase, and again each time at the beginning of the algorithm-phase. It may also be beneficial to re-synchronize time during stand-by and computation tasks. Given the dynamic character of the execution of quantum error management algorithms, often a global-delay is broadcasted to the entire system, and all subsequent instructions are then delayed until the system has recovered from errors. The latter triggers a local-delay of the time-stamped hardware specific instruction set architecture, that is the delay of the time-line of execution of the seed-sequence of the quantum algorithm. As mentioned before given that time synchronization is critical to this system, it may be that the time-synchronization internal-communication system may run in an own separate link because of the need for accuracy.

[0140] From a digital circuit design perspective, the digital blocks of this design are synchronous. The latter requires the distribution of a (low-frequency) backbone-clock and the phase-locked regeneration of a (high-frequency) local-clock at each entity. The clock is to be transmitted electrically inside a temperature range and preferably optically over temperature crossings. At the end of the algorithm phase until the N algorithm executions are completed, this module triggers a repeat of the algorithm-phase. At the end of the report phase, it triggers a return to the sby-phase.

[0141] Transmissions - in-TRX module and out-TRX module:

[0142] This module faces the quantum objects 5 and is directly and / or indirectly interacting with them. Directly, if it is statically or dynamically interacting with the quantum-object 5. Indirectly, if it is an indirect measurement or static trigger of / to the environment of the quantum-object 5. The interaction is for computation and / or measurement purposes. If the signal is going outwards from the entity, then it’s called a outgoing TRX, it can be of two types. If the signal is directly interacting with the quantum-object 5 it is called TX module and in the indirect case is called a driver. In the same way for a signal going inwards into the entity, it is an incoming TRX, it can be of two types. If the signal is coming as a direct measurement of the quantum-object 5 it is called an RX module and in the indirect measurement case is called a monitor. The measurement of a quantum-objects 5 is triggered by quantum error management or for quantum-state read-out purposes.

[0143] Signal processing (SP) module:

[0144] The outgoing and incoming signals to and from the quantum-object 5, respectively, must be processed. In general, the control approach avoids relying on storing large fix data-sets in memories to drive the entities. The generation of these signals should be performed as locally as possible to avoid high data transfers during runtime or a limited fixed sequence size because of the limited memory. The signal processing (SP) paths are to be accurately triggered to output the data stream in a timed-stamped accurate and synchronized manner. The TX / RX moduleshave SP blocks to generate and analyze the output and input data. For example, the RX quantum error management module executes mainly SP computations to decode how to best correct and / or mitigate and / or suppress errors. We consider two types of signal processing, either in the electron realm as digital signal processing (DSP) / analog signal processing (ASP) or in the photon realm as optical signal processing (OSP). Thus, we open the possibility to integrate dedicated processing photonic integrated circuits (pICs) to the system because they offer faster processing speed and lower noise. The latter requires also the integration of transducers to convert the signal representation from the electronic to the optical domain, and vice-versa. For the near-future we consider integrating photonic processing devices as pre / post signalprocessors or accelerators for time-critical or accuracy-critical SP computational paths. One of the main interests on integrating optical signal processing (OSP) is in the case where fast or low-noise pre or post processing data paths are needed for quantum error management.

[0145] Concept and examples 2: System-architecture

[0146] The aim of this section is to map the previously defined modules to the inventive system for controlling a quantum processor 9, which describes the mapping of concepts to physical devices and gives a space distribution of the system. The system-architecture is a network of distributed entities, preferably integrated circuit entities, a descriptive top-level blueprint is shown in Fig.

[0147] 3. As can be seen in Fig. 3, each entity is connected to at least one other entity. This blueprint is for illustrative purposes and aims to depict a possible space distribution and interconnection of the control-architecture of a QP. Each sub-system in a QP, both utility and transmission, is composed of an interconnected set of entities that in conjunction perform the required functionality. Yet each QP targeting a specific set of algorithms may have a tailored physical architecture for its control-system, but it is all based on the same backbone functional and architectural concept of interconnected entities. Each entity in the system is shown as a block in the blueprint, and it accomplishes part of a sub-system’s functionality, thus is labeled accordingly. In the next paragraphs, a discourse describing the main principles of the system is presented.

[0148] Sy stem -level principles:

[0149] The first principle we discuss is the modules physical split, which entails that each of the previously described seven logical modules is now realized and mapped into one or many blocks at the system-level and within the entities so that the system as a whole can behave as described by the behavioural concept of the architecture. Each entity may have a device-ID which makes it known to the system-level what set of hardware-specific instruction setarchitecture instructions this device reacts-to and / or executes and identifies its sub-system membership that defines the reason for its existence in the system.

[0150] Part of the start-up check may be to retrieve all the active resource’s device-IDs, this is the check-in of the entities. Each entity typically supports all modules in order to be able to be a functional unit within the QP in accordance with the system concept. An entity of the system can be one of three types, either a utility entity 1, 2, 3, 4, a router-entity 8, or a backbone entity 71, 72, 73, 74. The utility entities 1, 2, 3, 4 are namely the main interface 1 and the service entity 4, the power entity 3 and the time entity 2 shown at the top-level diagram in Fig. 3. If the system is such that the entities are distributed among at least two temperature zones, these utility entities 1, 2, 3, 4 can be replicated if needed in each temperature zone. The input M-QISA stream is captured by the main interface 1. It receives the sequence of instructions from e.g. the algorithm-request hardware, schedules the computation, and responds with the computation result. The main interface 1 translates the M-QISA to a sequence of hardware specific instruction set architecture, e.g. LISA, packages, which are scheduled as time-stamped instructions, and dispatched to the network as schematically depicted in Fig. 12. The sequence of hardware specific instruction set architecture packages are then distributed to the appropriate entity for a time-stamp accurate execution. The DFT module maps to the service entity 4 and preferably to the local service cores 41 at each entity which allow execution of all activities related to the DFT module as explained before. As shown in Fig. 3 the service entity 4 may be connected to a DFT system 42 via a port. As explained above this allows to re-use the same DFT system 42 to access the entities. The time entity 2 holds the global-time and updates the system on regular bases to synchronize the local-time in all entities. Each entity may have a time core 21 that maintains the notion of the local -time.

[0151] The router entities 8 are used as the transport-backbone of data across the system. Further, router entities 8 from different temperature zones may be connected via optical crossing connections. The temperature crossing routers 8 have an optical interface, thus these contain an analog back-end 18 facing the optical temperature crossing.

[0152] The backbone entities, which may also be referred to as transmission entities, 71, 72, 73, 74 may all derive from a generic backbone entity and possible derivations are shown in the Fig. 3 as: transmit (TX) entity 71, receive (RX) entity 72, quantum error management (QEM) entity 73 and result (RES) entity 74. Regarding their functionalities, the backbone entities 71, 72, 73, 74 are configured to interact with the quantum system and comprise an analog front-end 14 for said interaction, this would be either a receive or transmit entity 72, 71, and / or to process incoming data from the quantum system, this would be either a quantum error managemententity 73 or a receive entity 72, and / or to store incoming data from the quantum system, this would be a result entity 74. Thus, to compute with the quantum-objects 5 some of the backbone entities must have an electronic or optical interface. Specifically, the transmit and receive entities 71, 72 must have one, thus these contain an analog front-end 14 facing the quantumobjects 5.

[0153] For example, in Fig. 3 the transmit module is represented in a first temperature zone Tzonel by a first transmit entity TX1, and also in a second temperature zone Tzone2 by a second transmit entity TX2. The same holds for the receive and quantum error management entities in Fig. 3. In a third temperature zone Tzone3 in the exemplary embodiment of a system in Fig. 3 only a quantum error management entity 73 and a receive entity 72 are available.

[0154] A receive entity 72 may perform measurements to a quantum-object 5 or its environment. A quantum error management entity 73 may implement the SP for quantum error suppression, correction and / or mitigation purposes. Note that, the quantum error management of noise in a QP is currently dealt trough three different schemes: suppression, correction, and mitigation. Each scheme differs on the step at which the error is addressed, either at the input signal stream by quantum error suppression (QES), actively during computation by quantum error correction (QEC), or to the results by quantum error mitigation (QEM).

[0155] A result entity 74 may store the results of the computations across multiple executions of the algorithm. Note that SP activities are realized by all entities, and specially the transmission modules have strong SP data-paths.

[0156] The system can be distributed across various temperature zones as explained above. Each entity may have a membership to a temperature zone trough a temperature-ID. Its power management and environment compliance may be tested against those of that temperature zone.

[0157] Between temperature zones, we have optical crossing connections. The latter implies that at the temperature boarder crossing an electrical -optical transformation of the data has to take place. The system is split may be further split power zones, this is a grouping of entities that have a common objective or are in a close physical location. Thus, each entity may have a membership to a power zone. These power zones are preferably directed by a central power entity 3 which dynamically scales the system up or down (e.g. turn on or off HW resources) at the setup-phase of the processor by giving the possibility to address many entities at once. The power entity 3 directly controls the local-power blocks at each entity, which allow execution of all activities related to the power module as explained before. Additionally, each entity may have a power-ID and it may be turned on and off or only turned down individually within a zone e.g. at the set-up cycle according to the algorithm specific fine-resources requirements. Turning on andoff or down and up of entities or hardware resources is all included in the dynamically scaling of the power which is done by the power entity 3. The turning on or off or down of power zones, also takes a ramp up or down time for the processor resources, all this logistic can be dealt by the power entity 3. The system may use a priority -based low-power network-on-system (NoS) 10 to communicate internally. Each entity is a node in the network, preferably has a network-ID, and has an interface to receive and transmit packages to any other entity in the network thus enabling cross-entity communication. The network uses router entities 8 to transmit the internal hardware specific instruction set architecture, e.g. LISA, instructions to the target entity. Router entities 8 can be also powered down if all entities attached to it are not part of the active resources. The network maintains priority of packages, according to a priority ranking of the hardware specific instruction set architecture packages. Between temperature boarder crossings, the electrical-optical transformation are pushed from / to a router entity 8 with a transducer interface. At the temperature crossing routers, the transmission of optical data can benefit of frequency and / or phase multiplexing protocols.

[0158] Concept and examples 3: Backbone entities and router entities

[0159] The generic-architecture diagram of a backbone entity 7 for a system for controlling a quantum processor 9 is depicted in Fig. 1. This the general structure of a backbone entity 7, which allows each sub-system / entity to be designed / tested separately but still be compatible with the inventive control-system concept and manufacturing concept. At this abstraction layer, we start to call the blocks within an entity: cores, these are reusable units of logic cells that describe a component-block in an entity. Preferably, the backbone entity 7 is an integrated circuit (IC) entity. A backbone entity 7 comprises several utility cores. These utility cores are: network interface core 11, service core 41, power core 31, time core 21, opcode-core 12, and the memory management unit (MMU) core 13. The utility cores are basic components needed by the system to use a backbone entity 7 as part of the concept of this control system. The system-level tasks of all cores are also described above.

[0160] More precisely, the backbone entity 7 is connected to the network via a network interface core 11, it is also connected to the DFT equipment via a service core 41, which is connected to all other cores of the entity 7. The service core 41 is used to execute all tasks related to the DFT-module. The DFT tasks are mapped to the service core 41 at each backbone entity 7 and may be used during manufacturing tests, the setup-phase, and during run-time for calibration, and reporting purposes. This core has a direct connection to all cores within the entity to access them for self-test purposes and calibration. The power / clock -gating of possible power areasParea is managed by the power core 31 at the entity level. It is thought that some power-areas in each entity 7 can be put in a clock-gating stand-by mode during the algorithm-phase to avoid noise or heating coming from this area of the entity during computation. Thus, the power core 7 can dynamically scale the power of the power areas of a backbone entity 7. The clock / reset signals as well as the local-time notion are managed by the time core 21 at time the entity level. This core 21 may hold and track the work-cycle of the system, synchronize the local -time of the global-time by continuously running synchronization protocols, and broadcast its local -time to all cores within the backbone entity 7. Further, it may generate a phase-locked high-frequency clock at which the backbone entity 7 runs, locked to the systems’ clock, preferably through a phase locked loop (PLL) 211. The opcode-core 12 is the master of the backbone entity 7 and it functions as a central router for e.g. hardware specific instruction set architecture packages. Its tasks may include: configuration of the backbone entity 7 registers maps after startup / reset by retrieving its configuration from memory and the read and write from memory. The memory management unit core 13 manages the mapping between virtual and physical memory. Further, the memory management unit core 13 may also do the configuration of the backbone entity's 7 cores registers-maps after reset and at the incoming of a hardware specific instruction set architecture command. The configuration broadcast includes retrieving their configuration from memory, packing them for network distribution, and forwarding them to the opcore. When the memory management unit core 13 does these tasks the opcode-core 12 can mainly function as the central router.

[0161] Through the memory management unit core 13 the memory is also accessible for read and write, even though memory write and read are preferably done via the service core 41 during the setup-phase and at the end during the report-phase.

[0162] Further, the backbone entity 7 optionally comprises one or more transmission cores 131, 132, 133, 134, which are connected to the memory management unit core 13 as shown in Fig. 1 and may be a transmit core 131, a receive core 132, a driver core 133 or a monitor core 134.

[0163] From the perspective of each backbone entity 7, the outer system is the network on system (NoS) 10. Each entity may thus receive packages from the NoS 10, which may have a packageoverhead required for message distribution across the network. The network interface core 11 unpacks or packs the network packages extracting and / or inserting the hardware specific instruction set architecture, e.g. LISA, package within. For an incoming package, the network interface core 11 preferably checks if the delivered package matches to its network ID before forwarding it to the internal system for distribution. The hardware specific instruction setarchitecture package is preferably transmitted as a whole trough the internal cores via a ping-pong-forward (PPF) mechanism. The PPF mechanism refers to the receiving core within an entity checking if the hardware specific instruction set architecture package matches its opcode range, if yes then it holds the instruction for execution, if not it forwards it to the next recipient. The network interface core 11 can also prepare and pack a time-stamped package to be transmitted to other entities.

[0164] Given that the transmission cores 131, 132, 133, 134 either extract data from memory for signal processing or write data to memory after signal processing, each one has a direct link to write / read memory. Preferably, the transmit and driver cores 131, 133 have a read-only memory port, the receive and monitor cores 132, 134 have a write-only memory port, and the opcodecore 12 has a read-write port. All transmission cores 131, 132, 133, 134 are preferably instantiated by demand based on the functionality of the backbone entity 7. In the usual case, each entity accomplishes one functionality, therefore has either a send or receive activity towards or from the quantum-object 5. The receive core 132 may have a data port 135, this is needed for the case of an entity being a quantum error management entity 73. Usually this data port 135 transmits a syndrome in the case of quantum error correction or the actual result of the measurement in the case of quantum error mitigation. The transmission cores 131, 132, 133, 134 have direct access to the memory management unit core 13 for these cores are required to generate all data streamed towards the quantum-object 5 based upon matrices or parameters stored in memory. Thus, in memory no long sequences of shots are to be stored, all streamed data must be generated in real-time. Further, the backbone entity 7 may comprise an analog front-end (AFE) 14, which handles all digital-to-analog converter (DAC) / — analog-to-digital converter (ADC) activities and any other ASP / OSP needed.

[0165] Further, the backbone entity 7 may have a port for clock / reset and power lines.

[0166] The transmission cores 131, 132, 133, 134 are preferably instantiated on demand, depending on the transmission task to fulfill by the entity. Thus, Figs. 8 -11 show different backbone entity topologies that can be derived from the template generic-architecture. These different topologies comprise different transmission cores. In Fig. 8 a quantum error management entity 73 with a receive core 132, in Fig. 9 a result entity 74 with no transmission core, in Fig. 10 a receive entity 72 with a receive, monitor and driver core 132, 133, 134 and in Fig. Il a transmit entity 71 with a transmit, monitor and driver core 131, 133, 134 is shown.

[0167] The connections between the cores are preferably defined interfaces that include the communication protocol within, hence cores have only to instantiate the right interface version in order to plug in to the system. Two connections in Fig. 1 and one connection in Fig. 8, Fig.10 and Fig. 11 are shown differently as dashed-lines in the diagram, those are the connection between the opcode core 12 and each of the interacting cores: that is the receive core and transmit core 132, 131. The dash-lines interfaces in the diagram represent an interface with a dynamically time-ordered pipe (DTOP) 15 which pushes hardware specific instruction set architecture instructions into the interacting cores at the time-stamped time, taking into account the internal-data path of the transmission core. The DTOP 15 as its name suggests, is a holdpipe of hardware specific instruction set architecture instructions which is dynamically reordered in real-time according to the time-stamp of each incoming hardware specific instruction set architecture. It then pushes the instructions at the time-stamped time into the interacting cores for execution. Preferably, all other cores must track the time-stamped execution of their instructions, only the time-critical cores may have this external pipe.

[0168] Further, the backbone entity 7 preferably has a power split of areas, each called a Parea#, see Fig. 1 and Fig. 8 - 10, where each of them can be powered on or off or down independently or be the object of a clock-gating stand-by mode. Towards the quantum-objects 5 the backbone entity 7 may have an analog interface, i.e. an analog front end 14, to convert all electrical or optical signals to interact with the quantum-object 5. Preferably, the analog front end 14 can control a transducer 6 interacting with the quantum system.

[0169] The entities of the inventive system have a digital and an analog part, thus may classified as mixed-signal ICs entities. Given that it is considered to include OSP blocks, the classification is thus extended to a pIC. The digital and analog part are application specific designed, yet with a template-based approach for cost-effective manufacturing.

[0170] The manufacturing concept of IC backbone entities 7 may abide by the methods of Chiplet design and heterogeneous integration packaging. Chiplets are small / modular ICs to be combined in a more complex multi-die design by using packaging technology. This approach aims to integrate dissimilar chips, such as various Chiplets, photonic devices, or components, possibly all fabricated in different process technologies, possibly all developed by different engineering teams, into a system on a common package substrate, known as heterogeneous integration packaging . The strategy is preferably to manufacture most the backbone entities 7 and / or cores as volume mass-production Chiplets, and integrate them with some other nonvolume custom receive or transmit Chiplets design using heterogeneous packaging methods. For IC-entities placed at room-temperature, standard packaging is thought to be used. For IC-entities placed in harsh environments such as cryogenic or baked at high temperatures, the package of these must be sturdy enough and must shield EMR via a sort of Faraday-cage type design. This manufacturing method gives the inventive system greater flexibility, scalability,and cost-effectiveness; and enables multiple development teams to collaborate. The only reasonable & industry-proven method to reduce the size and minimize power-consumption / dissipation of the over-head of control devices a QP needs to execute a useful QP is by adhering as close as possible to the IC mass-production volume approach. In this regard, this template / lego-like approach of the backbone entities 7 allows blocks of the entity to be volume mass-produced and other custom design blocks to be integrated at a reasonable extra interface area and packaging cost. Depending on the functionality of the backbone entity 7 these blocks are either filled or empty. Different examples of backbone entities are shown in Fig. 8 -11.

[0171] The router entity 8 is exemplary shown in Figure 11. The router entity 8 serves as a switching device to route packages and may act as a temperature crossing point of data and clock. It is comprised of a service core 41 to execute all DFT related tasks and preferably connected to the DFT system 42, which may be also referred to as service system, via a port. It has a time core 2 land a power core 31 for all tasks related to each respective module. The functionalities of the time core 21 and the power core 31 for the router entity 8 is the same as for the backbone entity 7, where the power core 31 of the router entity 8 can also dynamically scale the power of the whole router entity 8. This is especially useful if e.g. all entities connected to a router are not used in a certain step of a quantum computation. Further, the router entity 8 has at least one entity connected through a network hub port 16 in order to re-direct the network packages. Thereby definition of a hub port here super-seeds that of a classical hub, for the switch core can preferably both address each port in the hub individually or do a broadcast. The hub can be configured such that messages sent form an entity connected to the hub can be immediately broadcast to the local-network or / and go to the switch. In come cases it may be of interest to set the switch into by-pass mode so that the messages are broadcast only, this method gives the flexibility of lower latency of delivering messages if the intended recipient is at the localnetwork, but can flood the network with messages.

[0172] The main switching activity is mandated by a central switch core 17 which may be prioritybased on the opcode and time-stamp of each network package and may also route packages depending on the ID of the target and / or recipient entity. Additionally, a temperature crossing router has an analog back-end (ABE) 18 and preferably an opto-electro management unit (OEMU) core 19 where the multiplexing / de-multiplexing and the conversion between electrical and optical signals takes place. Note that there is a split of the temperature crossing point of signals related to the DFT module and another crossing point for all other signals. In the caseof a temperature crossing router the service core 41 acts as a repeater of the DFT port to the temperature zone it is in.

[0173] Concept and examples 4: Concepting a run-time algorithm-specific quantum processor, a algorithm management unit and an operating method for controlling a quantum processor

[0174] Quantum processors are not a substitution of classic ones, but a different paradigm that allows the computation of very specific and specially designed algorithms that benefit from quantum advantage. The latter is defined as solving useful industrial or scientific problems with an advantage in terms of less operations which maps to less computation time, better accuracy of result, less energy, less logical resources needed for the computation, and / or less overall operation cost; although the primary meaning of the quantum advantage is usually coined as less computational cost (less operations per problem).

[0175] The term quantum supremacy was coined by J. Preskill in 2012 in reference to a QP solving quantum-algorithms with at least a super-polynomial speed-up relative to classic-processors, the “dream” is a QP that solves problems classical-processors cannot. For that reason, it is only reasonable from a system-level perspective to envision a QP as a co-processor / accelerator embedded within a higher hybrid classic-quantum computing system and not as a stand alone processor. The quantum co-processor executes only those specific algorithms that benefit from a quantum acceleration. Therefore, the system-level design of its control system must take into account that the full-stack will be shared with a classic computing system and other quantum processing technologies. As we head towards a QP being used as an accelerator within a higher computational system, we aim to have a machine driven interface, and not a human-user one. Therefore, the interface of the control system of a QP must be ready to expect instructions from such a higher computation system, and not from a human-user interface. From a system-level perspective, the latter is currently not fully aligned with the status-quo of a single-QP software (SW)-based full-stack where the input is a quantum-circuit, followed by optimizations, and translated to the specific machine assembly language for the executing QP. Nonetheless, specifically by integration with High-Performance Computing (HPC) systems, efforts are heading in that direction.

[0176] Let us consider the example of a trapped-ion quantum processor (TIQP) to go into more details. A TIQP contains ions subject to quantum computation in an ion-trap by holding them inelectromagnetic pseudo-potential wells (harmonic oscillator) and computes / measures them by exposing them to electro-magnetic radiation (EMR). To achieve an ultra-high vacuum (UHV) ion-traps are placed in a vacuum chamber and baked at high temperatures, a faster turn-around approach is to place them at cryogenic temperatures, thus minimizing the interaction of the ions with environmental particles. Among the various ion-trap topologies, the micro-fabricated segmented 2D ion trap seems to be a good choice for its great scalability potential and ease of fabrication according to existing industrial methods. A single trap can accurately hold and compute with 15-25 ions, to scale beyond that the quantum charge-coupled device (QCCD) architecture gives a modular approach to scale the number of interconnected ions and operate in the regime of 50-200 ions. To further expand beyond that ion threshold, optical interconnection of a cluster of QCCD ion-traps is proposed.

[0177] Another proposed scalable trap-structure architecture is an ion-trap lattice array, in which ions are trapped along parallel rows of a 2D linear trap arrays in a Quantum Spring Array (QSA) architecture. Other proposed scalable architecture uses optical tweezers to segment large ion chains in a ID ion-trap. All later scalable approaches are based on Paul-traps, yet recently scalability of a TIQP is also pursued by using Penning-traps in which the trapping method differs. Thus all considered, the interconnected devices the control system of a TIQP must manage just keeps increasing, getting more diverse, and physically distributed. Accordingly, a very flexible, scalable, cost-effective, and environmental-sturdy control system must keep-up with this fast changing system while coping with the still uncertain scalable ion-architecture it must control. Yet if the control-system does not scale along, the TIQP will never scale in order to solve useful algorithms.

[0178] Abstraction layers facilitate the understanding of complex systems. Hence to gain intuition, it is a reasonable starting point to examine the abstraction layers of the computer stack of a classical processor and analyze it within the case-study of a specific quantum-object technology: trapped-ions. For a classic electronic computing system these layers are well defined in literature. These abstraction layers can be intuitively mapped to a quantum computing system. Within that understanding, for the example of a trapped-ion quantum processor this processor is composed of two main sub-systems, that map to four hardware-related layers of classic computation. That is, at the lowest level are the quantum-system related elements:

[0179] the ions, the ion trap, the electromagnetic wave (EMW) generators for confinement, LASER-cooling and pumping, and computation, as well as the photon measurement devices. Allgoverned by a classic control system to direct computation, measurement and quantum error management tasks. Above these bottom hardware layers, there is the software-stack to enable the abstraction required for a TIQP to execute an algorithm and to interact with other processing devices. The first software-layer is the Instruction Set Architecture (ISA)-layer. A natural extension of that classical concept is a Quantum Instruction Set Architecture (QISA) for a QP, and thus the control system acts as a transceiver, that receives QISA instructions and executes them as computations / measurements on the ions. Following this line of thought, the QISA will then define the operations (functionality) that the control system will execute on the ions. Therefore, we can derive that towards the definition of the system-level description of the control system of a quantum processor, the definition of the QISA layer is of particular interest.

[0180] In the gate based quantum computation model, a universal set of gates is used to perform computation on qubits, opposed for example to the annealing based computing which is coined as analog quantum computing used mainly to solve optimization problems. Thus, quantum gates are a universal language for describing an algorithm in the gate based quantum computation model. Ions in an ion-trap are one of many quantum technologies a quantum processor can be implemented in. We must then consider that, it may be the case that different quantum processors of different quantum technologies are used as parallel co-processors in the same hybrid computing system. To ease the integration of the upper software-stack with the potentially-various quantum technologies processors in the system, we acknowledge the concept of having a general QISA to address all the quantum processors with quantum mechanics gate level operations. Consequently, the upper software- stack requires less awareness of the quantum technology-dependent execution of the instructions, but rather it can seamlessly make a quantum-logic-gate computing request to a quantum processor, independent of its quantum technology implementation. Therefore, the QISA layer of a quantum computing processor may be decomposed into two sub-layers of abstraction. More precisely, the upperpartition Macro-QISA (M-QISA), is quantum technology semi -independent set of instructions, that map to quantum gate operations, incoming from the upper software-stack. The lower-partition is the hardware specific instruction set architecture, e.g. local instruction set architecture (LISA), which is quantum technology and microarchitecture dependent, mapping the incoming quantum gate operation to specific quantum technology computation and measurement operations. This split leads to the abstraction layer of the QISA-layer needed between the classic and quantum computing elements. The M-QISA is defined for the classicsystem, and is translated at the QISA-interface of the quantum processor to the set of according processor-specific hardware specific instruction set architecture instructions.

[0181] A M-QISA instruction initiates a function (computation / measurement) requests in the quantum processor, incoming from the upper software-stack. There have been a hand full of proposals that describe such general QISA, from which a sub-set resembles almost one-to-one to quantum gate circuit operations. Examples are the common quantum assembly language (cQASM), an instruction set originated within the context of superconducting quantum processors. Other QISAs are specifically designed for a TIQP, consequently they include ion-transport and cooling operations which are specific for trapped-ions. That is the reason for the M-QISA is quantum technology semi-independent because of the specific need of ion-transport operations required in a scalable TIQP. Yet aside from these ion-transport and cooling operations, the M-QISA describes a general quantum algorithm compatible with other quantum technologies.

[0182] The instructions may be classified in: qubit gates (1-qubit, rotation, 2-qubit), initialization, measurement, ion-transport, cooling and flow control.

[0183] The received M-QISA instructions are then translated to the processors-specific hardware specific instruction set architecture set of instructions at the incoming interface of the control system of the quantum processor. The hardware specific instruction set architecture, e.g. LISA, is an internal control -system specific set of instructions for the processor. It is a set of instructions used inside the processor to synchronously execute the required M-QISA functionality. Therefore, the hardware specific instruction set architecture is defined as the add-up collection of all instructions needed to cover all functionality and control specific related tasks of a quantum processor. Each sub-system in the quantum processor responds to a defined sub-set of the hardware specific instruction set architecture. The hardware specific instruction set architecture is then expected to grow as more sub-system are added to the over-all system, yet they all have the same format in order to be compatible at the system -level.

[0184] Thus far in the discussion, we have analyzed the stack of a quantum processor as if it were a nuance of the classical one. Yet while both classic and quantum processors are gate-based computing units, each aims to solve problems with a different mathematical underlying logical-unit paradigm. A classic processor computes using a bit (binary digit) of two logical values physically mapped to a transistor, while a quantum processor uses a quantum-logical unitmapped to a physical quantum-object . The latter is logically mapped within the Hilbert-space to either a two-dimension (d = 2) level system known as a quantum-bit (qubit) or to a multidimension (d > 2) level system known as a quantum-dit (qudit). A ‘quantum-object’ refers to a physical quantum-information-carrier unit and a ‘quantum-logical unit’ refers to a set of n-quantum-objects grouped for fault-tolerant purposes; if the system is not fault-tolerant n = 1. This quantum-logical unit exhibits the quantum mechanical properties of superposition, entanglement, and interference. It has an inherent coherence decreasing over time, once it is measured it looses its quantum properties by probabilistically and irreversibly collapsing its wave-function to a classical observable state, and it is extremely prone to errors caused by initialization / computation / read-out operations as well as from external perturbations from the environment. A quantum processor is currently more energy-efficient than massive-supercomputing farms when solving the same problem.

[0185] Consequently, quantum-algorithms differ from classical ones in that these exploit the benefits of quantum mechanical properties of a quantum-logical unit with the promise to outperform their equivalent classic-algorithm counterparts, with the burden that their physical practical implementation is inherently transient, stochastic, and extremely sensitive to perturbations. Ergo, in as much a practical quantum processor could compute quantum-algorithms a classic processor cannot (within reasonable computing-resources / time), when it comes to the fidelity of the result of the computation, a classic processor currently outperforms a quantum one. Generally speaking, a classic processor delivers reliable deterministic computations, whereas a quantum one (currently) sinks after a few operations because of its high error rate. Quantum processors are (currently) still far from being capable of executing algorithms for relevant problem sizes: utility-scale quantum computation. Moreover considering the great amount of materials / energy (currently) needed to build / run a quantum processor, energy is most efficiently utilized by a classic processor. Classical memory is long-lasting and cost effective, hence given the inherit transit quality of quantum states and the fact that quantum information cannot be copied a quantum memory is (currently) not a competition to classical solutions. Furthermore, consider that the amount of available quantum-algorithms is still limited. Also, since quantum computing is in essence stochastic the results of an algorithm are probabilistic, and therefore evaluated via interpretation of a probability distribution. Hence it is expected that the same algorithm, i.e. sequence of QISA-instructions, is repeatedly executed N times (shots) to be able to get a statistical distribution and discern among the probabilistic distribution of the result. All considered, the scenario where a quantum processor is used needs to be simplified as a step towards a practical use of its benefits.A quantum processor may serve as an accelerator within a higher hybrid-computing system. It may only execute quantum algorithms that show a quantum advantage over classical counterparts. The processor has then a supported set of quantum-algorithms, that is a predefined and pre-trained limited set of quantum algorithms. During run-time, the processor may then be preset to compute only one algorithm of those within the set, accordingly during runtime it accepts algorithm-computation requests of the run-time algorithm only. What may vary across algorithm-computation-requests are the operands of the algorithm or its settings / parameters. Changing the run-time algorithm to another one within the set is possible but it requires a restart and rescaling the processor to that new run-time algorithm. In this embodiment gate-based computation processors are considered which are run-time algorithmspecific, i.e. QISA instruction sequence specific, and not run-time general processors. The control system should then be able during setup time to scale the hardware resources of the processor according to the run-time algorithm. The latter gives the benefit of aiming to support predefined sequences of QISA instructions, that maps / scale to as much active hardware resources as the algorithm requires. Furthermore, there would also be the possibility to pre-train the processor to cope with errors by concurrently running in the backstage dynamic quantum error management algorithms tailored to accompany the run-time computing algorithm thus performing real-time and dynamic quantum error management (QE-MGT). So that, each pretrained computing-algorithm supported by the processor has an accompanying pre-trained QE-MGT-algorithm running concurrently in the backstage to perform real-time QE-MGT. The idea suggests that the control system runs two concurrent synchronized algorithms: one for computation and other for error correction. The control system must then be able to dynamically react to the QE-MGT algorithm running in the real-time in the backstage. For this run-time algorithm-specific quantum processor there may also exist an algorithm management unit (AMU). The AMU is a low level hardware device that accepts algorithm requests from the upper stack as shown in Figure 4a and 4b. The simplest case is to execute an algorithm with one single QP as shown in Figure 4a. The extended case is to compute the one algorithm with / across various optically-linked entangled QPs as shown in Figure 3b. The AMU stores the pre-trained seed QISA-instructions that describe each run-time algorithm, pushes them into the QP according to its pre-trained process. Further, the QP may run concurrently the QE-MGT algorithms to cope with errors. The latter ultimately proposes to raise the interface of the QP to the algorithm level trough the AMU interface, to move the algorithm execution to the HW layer,and let the QP dynamically fix itself in real-time at the HW level with a very distributed and trainable hardware-based control system architecture.

[0186] In light of our hypotheses, we argue that a classic computing stack is meant to be executed in a Von-Neumann type architecture and cannot / should-not be adopted / migrated as it is to a QP. At this point in human-history when we are engineering these machines, we propose a more practical way of raising the interface of a QP to the algorithm-level. By dynamically executing the quantum algorithm at the HW level, the QP has better chances to fast-enough and to dynamically self-adapt to the errors that arise during computation. The ability to train a QP and equip it with real-time decision-making without human-driven intervention is key to meet the real-time reaction requirements of QE-MGT. The control system must allow the QP to dynamically self-adapt the intertwined execution of the quantum-algorithm and QE-MGT algorithms. All, so that some day we (humanity) can engineer a QP that completes a useful quantum-algorithm within its coherence time. That day, quantum computation will be finally useful to humanity.

[0187] At the current stage in the roadmap, towards that day, we suppose the proposed hypotheses assumptions & constraints simplify the use-case of a QP yet add extra requirements for its control system with a fully HW-based stack, which we aim to fulfill. From a physical scalability standpoint, we must consider not only clusters of interconnected TIQPs, but also an extension to various quantum-object types of QPs. The diversity and amount of external devices to manipulate increases such that the control system must be able to scale resources for any given algorithm and use the best underlying quantum-technology to split the computation.

[0188] Example 5: The case-study of trapped-ions

[0189] In this section we aim to showcase the use of the inventive system with a practical example. Thus, we use it to map a specific sub-system required by a QP of a specific quantum-object technology, namely the ion-transport sub-system of a TIQP. For that purpose we leverage on a top-down design methodology. At the system-level, we first define the functional system specification for the target QP, we then do the system-level mapping of the functionality into sub-systems and assign specific physical resources to each. We then move into the sub-system mapping by its physical integration into one of the currently sought scalable QP architectures, and finally we show a physical sub-system architecture within the blueprint of the inventive system architecture. This top-down approach produces an output blueprint of the sub-systemthat opens the door to the distributed / stand-alone physical implementation of the components of this sub-system, i.e. the independent design and implementation of each of its components as long as compatibility to this initial blueprint and the concept of the system architecture is maintained.

[0190] System specification: The use-cases map to the M-QISA as defined above, where each instruction defines a specific functionality of the TIQP. We also defined various use-cases and environmental / electric requirements for its control-system. Currently, a scalable TIQP is industrially-pursued within a main set of system -level variances: the type of trap (Paul / Penning), the type of computing-transition (optical / hyperfine), the type of scalable architecture (QCCD / QSA), and the type of functional-temperature range (room / cryo).

[0191] System-level mapping: We now map the interaction sub-systems to physical resources. All the possible interaction subsystems functional tasks for various types of TIQP and their mapping to physical resources are listed in the following Table VI.

[0192]

[0193] Note that we have included all systems needed for the wide variety of currently pursued TIQPs, that is either a Paul / Penning trap, optical / hyperfine gates, and / or QCCD / QSA scalable architectures. In the following lines we give examples of how each sub-system could be mapped to physical resources for the specific case of a TIQP with a planar-segmented paul-trap, optical -transition, and a QCCD scalable architecture, as shown in Table VI. For example, a transmit entity 71 has a membership to either one of the TX sub-systems, namely: ion confinement, transport, or computation. The activities of the transmit entities 71 may include: the RF-AC and DC voltage signal generation for the confmement / transport electrodes respectively and the management of initializing / computing / cooling operations which includes turning on / off LASER sources as well as the generation of RF-AC voltages to feed AOMs were LASERs shine. For example, photon measurement devices, as for example a photo multiplier tube (PMT) or an electron-multiplying charge coupled device (EMCCD) or a complementary metal-oxide semiconductor (CMOS) camera, could be managed by a receive entity 72, this measurement provides feedback to a quantum error management system. For example, an incoming TRX mapped to a monitor core 134 of an entity could be the temperature measurement to monitor the physical conditions of the environment of the quantum-objects 5.Further, a driver core 133 of an entity could manage the RF-AC voltage applied to the electrodes lines needed for confinement in a segmented ion-trap, which is considered a quasi-static signal during computation for the type of TIQP in discussion. For example, a quantum error management is mapped to a plurality of entities which execute a Steane code.

[0194] Sub-system mapping:

[0195] Ion-transport is needed in a scalable TIQP architecture to move ions across regions of the processor. Such architectures use micro- structured ion-traps to enable scalability. Specifically, the ion-transport sub-system of a TIQP (planar-segmented paul-trap, optical-transition, QCCD architecture) requires the steering of DC voltages. In this section we show one possible mapping of the ion-transport sub-system into the system architecture. We propose to have the controlling ICs entities pertaining to the ion-transport sub-system embedded in close proximity to the segmented ion-trap to avoid the wiring bottleneck trough the vacuum / cryo chamber. A sketch of the mapping of the ion-transport ICs into the original proposal diagram of the QCCD-TIQP architecture is shown in Figure 6. The idea is that an IC-entity is controlling an electrodedomain of the QCCD-TIQP, that is a set of paired-DC electrodes. We refer to an electrodedomain as a planar-segmented ion-trap of N pairs of DC electrodes +1 central electrode. A paired-DC electrode, refers to the one electrode and the opposite-row electrode in a segmented ion-trap topology. The electromagnetic well whose pseudo-potential minimum is above the trap center electrode and aligned in-between the paired-DC electrodes, we refer to as an ion-area. In a QCCD architecture the TIQP as a whole is an ensemble of ion traps, where the DC electrodes of each ion-trap is controlled by one ion-transport IC. The collection of all these paired DC electrodes is called the IC electrode-domain. The manufacturing and tolerance requirements and required testing for this IC entity are set by the environment it must endure. If the TIQP is in a cryogenic environment or the ion-traps are backed at high temperatures to achieve a better vacuum, the ion-transport ICs must then also statically / dynamically endure and function in such environments. Which implies that these IC should be: (1) baking-temperatures static tolerant, (2) cryogenic-temperatures functional tolerant, (3) very low-power for they must not increase the physical temperature of the cryo-environment during run-time, (4) the package of the IC must be Faraday-cage shielded to avoid electromagnetic interaction with the ions, and they must be as (5) small die-area as possible. Notice that we consider different topological configurations for a linear trap: a T-type junction or an X-type junction, yet the same IC. Synchronization across neighbouring IC entities is needed in order to hand over ions across electrode-domains. The latter means that neighbouring IC entities must execute an ionhandover protocol across domains in a very-synchronized process.Sub -sy stem architecture:

[0196] From a system-level architecture perspective, the strategy for integration of the ion-transport subsystem into a cryogenic TIQP is depicted in Figure 7, showing the sub-system top architecture. In accordance with the system architecture guidelines, the data-path of the hardware specific instruction set architecture instructions at the temperature crossing is optically trough the router entity 8, then into the IC entity 71, which triggers an interaction with the DC electrodes of the ion-trap (quantum-system) and consequently with the ions (quantumobject 5). An IC transmit-type entity pertaining to the ion-transport sub-system is called an iontransport integrated circuit (ITIC) 71. In this case, each ITIC entity 71 has control over an electrode-domain in an ion-trap array composed of n pairs of electrodes plus a central electrode, in total N = 2n + 1. In this case, the ion-trap array is placed inside a cryogenic chamber, thus the ITICs must function and be connected via a network on system (NoS) 10 functioning at cryogenic-temperatures as well. At the temperature boarder the temperature-crossing router entity 8 has a ABE 18 which converts data between electrical and optical domain.

[0197] Summary

[0198] The scalability of a QP and our ability to manage its errors are currently the greatest challenges for realizing useful quantum-computing and they can only be conquered if the control-system plays an active role in enabling these features. Accordingly, here we have presented a scenario and precise assumptions that delimit the use-case of a QP and also presented the idea of a runtime algorithm-specific quantum processor . The past-decades have shown that it is limiting to simply take the same ideas and computing-stack we use for classic processors and extrapolate it to serve a QP. In the same way, it has also been noticed by now that taking the two-level classical-computation unit and extrapolate it to a two-level quantum-computation unit (qubit) may also be limiting, instead of exploiting the multidimensional (qudit) computational essence of a quantum mechanical system. In a nutshell, people have been treating a QP as if it were a nuance of a classical one, which is certainly not the case. Maybe we need to rethink the quantum computing paradigm and not keep dragging classical limiting-constraints to the quantum world. Thus, an algorithm-specific quantum processor has a set of pre-trained runtime algorithms, receives algorithm computation requests, executes only one of them during run-time concurrently-intertwined with its error-management algorithms, and has the ability self-adapt their execution; all at the HW layer. For that purpose a scalable, self-reacting, adaptable, and trainable control -system is required. As solution to this problem is given by the inventive system for controlling a QP. The system is a hardware specific instruction set architectureextensible, preferably algorithm-execution oriented, resources scalable control system, and a distributed network of entities. The system executes the algorithms at the hardware level based on a time-stamp based synchronization of its ginormous (e.g. O(103)) expected amount of distributed entities. The entities pertaining to this control-system may be integrated within the quantum target system as integrated electronics or optics, and not run externally from racks. Since size is limited, we aim an IC implementation of the entities and aim to manufacture them in a cost-effective SoC layout. The hardware specific instruction set architecture, e.g. LISA, is extensible according to the entities in the network aiming to compute e.g. a specific run-time quantum algorithm. The system enables the QP with the HW required to dynamically react in real-time and make quantum error management decisions. Finally we showed a practical example by mapping one of the sub-systems of a specific QP technology, namely the iontransport of a TIQP, to the inventive system.

[0199] The vision is to build a QP whose control-system is self-correcting, thus we also aim to use the best techniques of Machine Learning (ML) to train this machine to make error-management decisions at the HW-layer. The architecture allows for different entities to be developed by different engineering teams, which we believe is a key strategy to use the talent spread across many engineering development teams in order to deliver the ginormous amount of entities needed to control this machine. Yet, the performance requirements and energy budget must be met by all entities, therefore a responsible coordination body is recommended.

[0200] The environmental-footprint and the economic impact the dawn of QPs have to our society / planet must be taken into consideration for at utility-scale levels it will not be insignificant. At utility-scale levels these machines may be one of the most energy-consuming machines humanity has ever made, because they will not only need to power the quantumobjects in their preferred environment (e.g. vacuum, cryogenic), but also the great amount of classic control-electronics. Thus, the energy efficiency metric by which QPs are to this day undefeated, is yet to be re-examined at utility-scale levels; although we can be optimistic. We have specially designed this control system with sustainability in mind. Thus, it is very power-saving-aware, in the effort to preserve the current energy-efficiency advantage that QPs have. All parts of the circuit in a IC entity are preferably able to be turned-on or off or down, that is, it is possible to dynamically power scale the entities, and every entity preferably ranks below a designated energy budget. Furthermore, this system aims to reduce the human-effort and resources of re-designing the same component across different types of QPs by reusing existing entities / IP-Cores / utility-HW. The life-cycle, recycle, and ultimate disposal of all control-system related HW may abide by processes of a circular-economy. Thus, paving the path towards energy-efficient and sustainable quantum computation.

[0201] The comparison of the inventive system against all other existing solutions is simple: all current control systems for QPs abide by a von Neumann architecture. In contrast, the inventive system proposes a different physical control implementation paradigm. The system is a microarchitecture for a processor with a distributed set of computing units. The system timestamps hardware-specific instruction set architecture instructions and distributes them for time-accurate execution to the entities of the system. Preferably, the system has internal hardware structures, e.g. DTOPs, that allow its entities to manage the execution of time-stamped instructions in a dynamically scheduled environment. The system can allow the execution of an algorithm to be dynamically delayed by the feature of global delays that entities can issue dynamically during run-time, therefore the execution of an algorithm is not static but dynamically runtime scheduled. Further, the system may allow intra-communication of its computing entities to dynamically run supporting utility services, which we call hardware threads. Finally, the system can be built in a physically distributed set of IC entities, where each has an application-specific instruction set architecture, therefore each entity is an automaton, specifically, an incomplete Turing machine. Yet, the collection of the hardware-specific instruction set architecture of all entities in the system enable the control of a complete quantum Turing machine.

[0202] List of reference signs:

[0203] 1 main interface

[0204] 11 network interface core

[0205] 12 opcode-core

[0206] 13 memory management unit core

[0207] 2 time entity

[0208] 21 time core

[0209] 211 phase locked loop

[0210] 3 power entity

[0211] 31 power core

[0212] 4 service entity

[0213] 41 service core

[0214] 42 design for test (DFT) system

[0215] 5 quantum object

[0216] 6 transducer

[0217] 7 backbone entity

[0218] 71 transmit (TX) entity

[0219] 72 receive (RX) entity

[0220] 73 quantum error management (QEM) entity

[0221] 74 result (RES) entityrouter entity

[0222] quantum processor

[0223] network on system

[0224] transmit (TX) core

[0225] receive (RX) core

[0226] driver core

[0227] monitor core

[0228] data port

[0229] analog front end

[0230] dynamically time ordered pipe interface network hub port

[0231] switch core

[0232] analog back-end

[0233] opto-electro management unit core algorithm management unit

[0234] hybrid classical-quantum computing system

Claims

CLAIMS1. Backbone entity (7) for a system for controlling a quantum processor (9), wherein the backbone entity (7) comprises utility cores comprising• a network interface core (11) connectable to a network, • a service core (41) connectable to a design for test system (42) via a port, wherein the service core (41) is configured to self-test and / or calibrate at least a part of the cores within the backbone entity (7), • a power core (31) configured to dynamically scale power areas connecting a plurality of cores of the backbone entity (7),• a time core (21) configured to synchronize the local time of the backbone entity (7) with the global time of the network and broadcast the local time to the other cores of the backbone entity (7), preferably the time core (21) comprises a phase locked loop (211),• a memory management unit core (13) configured to manage the mapping between virtual and physical memory and make the memory accessible to read and write,• and an opcode-core (12) connected to all other cores within the backbone entity (7) and configured to function as a central router, wherein the backbone entity (7) optionally further comprises one or more transmission core(s) (131, 132, 133, 134), wherein the transmission cores are connected to the memory management unit core (13) and are selected from the group consisting of a transmit core (131), a receive core (132), a driver core (133) and a monitor core (134),wherein the backbone entity (7) is configured to be driven by an instruction from a hardware-specific instruction set architecture, wherein the network interface core (11) is configured to unpack or pack a network package from the hardware-specific instruction set architecture and extract or insert the time-stamped instructions, wherein the opcode core (12) is configured to route the extracted time-stamped instructions to the corresponding cores within the backbone entity (7).

2. Backbone entity (7) according to claim 1, wherein the backbone entity (7) is an integrated circuit having a layout with blocks for all transmission cores (131, 132, 133, 134) selected from the group consisting of a transmit core (131), a receive core(132), a driver core (133) and a monitor core (134), which blocks are either filled or empty.

3. Backbone entity (7) according to any of the claims 1 or 2, wherein the receive core (132) and the monitor core (134) comprise a preferably write-only memory port to the memory management unit core (13) and are configured to receive signals from a quantum system,wherein the transmit core (131) and the driver core (133) comprises a preferably read-only memory port to the memory management unit core (13) and are configured to send signals to a quantum system,wherein the receive core (132) preferably comprises a data port (135), wherein the receive core (132) and the transmit core (131) are connectable with the opcode core (12) through a dynamically time ordered pipe interface (15), configured to push the time-stamped instructions at the time-stamped time into the receive core (132) and the transmit core (131), respectively.

4. Backbone entity (7) according to any of the claims 1 to 3, wherein the backbone entity (7) comprises a receive core (132) and / or a transmit core (131), wherein the backbone entity (7) is configured for interacting with the quantum objects (5) of a quantum system and comprises an analog front end (14) configured for said interaction, wherein the receive core (132) and / or the transmit core (131) is connected to the analog front end (14).

5. Backbone entity (7) according to claim 4, wherein the backbone entity (7) comprises a transmission core being a transmit core (131), wherein the analog front end (14) is configured to control a transducer (6) interacting with the quantum system.

6. Backbone entity (7) according to any of the claims 1 to 5, wherein the backbone entity (7) is configured to send instructions to any other entity within the network.

7. Backbone entity (7) according to any of the claims 1 to 6, wherein the backbone entity (7) is configured to send a global delay to all or a subset of entities in the network that delays the time-stamp execution of instructions.

8. Router entity (8) for a system for controlling a quantum processor (9), wherein the router entity (8) is configured to re-direct hardware-specific instruction set architecture packages, wherein the router entity (8) comprises• a network hub port (16) connected to a network and at least one backbone entity (7) within the network, preferably a backbone entity (7) according to any of the claims 1 to 7, wherein the network hub port (16) is configured to re-direct time-stamped network packages from the hardware-specific instruction set architecture packages,• a switch core (17) connected to the network hub port (16) and configured to route the network packages,• a service core (41) connected to all other cores within the router entity (8) and connectable to a design for test system (42) via a port, wherein the service core (41) is configured to self-test and / or calibrate all cores within the router entity (8),• a power core (31) configured to dynamically scale power areas connecting a plurality of cores of the router entity (8) and / or the power of the whole router entity (8),• a time core (21) configured to synchronize the local time of the router entity (8) with the global time of the network and broadcast the local time to the other cores of the router entity (8), preferably the time core (21) comprises a phase locked loop (211).

9. Router entity (8) according to claim 8, wherein the router entity (8) comprises an analog back-end (18) configured for converting data between electrical and optical domain and comprises an opto-electro management unit core (19) configured to direct such conversion.

10. Router entity (8) according to claim 9, wherein the service core (41) is configured to act as a repeater of the design for test system (42) port.

11. System for controlling a quantum processor (9),comprising utility entities, router entities (8) according to any of the claims 8 to 10 and backbone entities (71, 72, 73, 74) according to any of the claims 1 to 7 as nodes of a network, wherein each entity in the network is connected to at least one other entity, and comprising at least one transducer (6) configured for interacting with quantum objects (5) of a quantum system,wherein the utility entities comprise- a main interface (1) configured to receive a sequence of instructions, translate the instructions to a sequence of hardware-specific instruction set architecture packages and schedule the instructions from the hardwarespecific instruction set architecture packages with a time-stamp,- a time entity (2) configured to hold the global time and synchronize local times in all entities of the network,- a power entity (3) configured to dynamically scale the power of individual entities within the network and preferably configured to dynamically scale the power of hardware resources of the network,- and a service entity (4) connectable to a design for test system (42) via a port and configured to test and / or calibrate the entities and / or read and write memories to the entities,wherein the router entities (8) are configured to transport data across the network, wherein the backbone entities (71, 72, 73, 74) are configured- to interact with the quantum system and comprise an analog-front end (14) configured for said interaction and / or- to process incoming data from the quantum system and / or- to store incoming data from the quantum system.

12. System according to claim 11, wherein the entities are distributed among at least two, preferably three, temperature zones, wherein router entities (8) from different temperature zones are connected via optical crossing connections and comprise an analog back-end (18) facing the optical crossing connection.

13. System according to any of the claims 11 to 12, wherein the system is split in power zones, wherein the power entity (3) is configured to dynamically scale the power of entities in different power zones.

14. System according to any of the claims 11 to 13, wherein the system comprises an algorithm management unit (20) configured to translate an algorithm computation request into a sequence of, preferably time-stamped, instructions and send the sequence of instructions to the main interface (1).

15. Controlling method for a quantum processor (9), wherein the method is for controlling a system as defined in any one of claims 11 to 14, wherein the method controls the execution of a quantum algorithm at the hardware level via a time- stamped based synchronization of all entities of the system, wherein the scheduled instructions from the hardware-specific instruction set architecture packages are time-stamped and internally distributed to the intended entities for time-accurate execution.

16. Controlling method according to claim 15, wherein the execution of a quantum algorithm is dynamically delayed upon occurrence of errors by a global delay broadcast to the entire quantum processor (9).

17. Controlling method according to any of the claims 15 or 16, wherein the power cores in each entity of the system are controlled centrally by the power entity (3), wherein the power entity (3) controls the dynamical power scaling of specific entities split in power zones.

18. Controlling method according to any of the claims 15 to 17, wherein the time cores (21) in each entity of the system are controlled centrally by the time entity (2), wherein the time entity (2) holds the global time and controls the synchronization of the local times in all entities of the system.

19. Controlling method according to any of the claims 15 to 18, wherein the service entity (4) centrally controls the service cores (41) comprised in individual entities of the system, wherein the service entity (4) is controlled by a design for test system (42).

20. Controlling method according to claim 19, wherein the service entity (4) allows to• test the entities against manufacturing errors,• verifies whether hardware resources are active and responsive,• bulk-in write the memories of the entities,• check if the memories of all entities of the system are correctly filled,• run a calibration of all entities of the system,• and bulk-out measured results from memories of entities of the system.

21. Operating method for controlling a quantum processor (9), wherein the method is characterized by implementing a pre-defined limited set of quantum algorithms to be performed on the quantum processor (9).

22. Operating method according to claim 21, wherein each quantum algorithm has pretrained quantum error management algorithms running concurrently to the quantum algorithm execution.

23. Operating method according to claim 21 or 22, wherein the method is applied on a system according to any one of claims 11 to 14.

24. Operating method according to any one of the claims 21 to 23, wherein the system is interfaced to an external computing device via an algorithm management unit (20), wherein the algorithm management unit (20) translates an algorithm request from the external computing device into instructions for the quantum system, preferably the time-stamped gate operations the system must apply on the quantum system.

25. Operating method according to claim 23 or 24, wherein the method comprises a setup-time and a subsequent run-time, wherein during the setup-time the method comprises the steps• choosing a run-time algorithm out of the set of quantum algorithms, • scaling all entities and hardware resources to those needed for the execution of the run-time algorithm,• self-testing and calibrating all entities and hardware resources needed for the execution of the run-time algorithm,• synchronizing local times in all entities of the system,wherein during run-time the method comprises the steps• waiting for an algorithm execution request,• executing the algorithm N times, where N is preferably larger than 10A3 , • reporting the results of the algorithm execution.

Images