Framework for Principles of Operation for a Quantum Computer

This informal paper proposes a framework for the principles of operation for a quantum computer, which is a document which specifies all relevant detail needed by a quantum programmer wishing to develop quantum programs for a particular quantum computer or family of similar quantum computers.

It is not a goal to specify any or all details of the hardware and internal design of the quantum computer, but only those details which the programmer needs to control to achieve the functional effect of a quantum program. This includes capacity and performance limits, but not necessarily all details of performance — coherence time is important, as is the approximate time needed to execute a typical quantum logic gate, but the exact execution time of each gate is not needed.

It is not a goal of this paper to provide detailed principles of operation for any particular quantum computer, but simply to summarize at the conceptual level what a principles of operation document should contain.

This conception of principles of operation also applies to quantum computer simulators, although there may be other details needed for simulators, such as configuring the simulator for different hardware models.

For brevity, this paper will refer to the principles of operation as POP. Generally, POP will refer to the document which details the principles of operation.

Audience for principles of operation

The intended audience for a POP document is quantum programmers — anybody writing code to be executed on a quantum computer (or quantum simulator).

Audience for this paper

In contrast to the audience for a POP document itself, the audience for this paper is:

• Technical writers tasked with actually writing a POP document.
• Product managers responsible for designing quantum computer products for use by quantum programmers.
• Designers of quantum computers and their firmware responsible for specifying the details of their machines which will be visible to quantum programmers.
• Quality Assurance staff who will be reviewing and using the POP.
• Support staff who will be supporting customers who are developing quantum programs. They may be the final reviewers, the guinea pigs to validate the quality and readability of the POP document.
• Managers of any of the above, who need to be aware of the importance, scope, and cost of producing a high-quality POP document.

Non-goals

This paper is not intended to cover any of the following:

1. Hardware details not directly visible to or detectable by a quantum program. See the Implementation Specification section.
2. Software applications.
3. Application frameworks.
4. Algorithms.
5. Operating software.
6. User interface.
7. General introduction to quantum computing.
8. Fundamentals of quantum computing. Although it is debatable whether a standardized set of quantum logic gates should be considered part of those fundamentals rather than being detailed in a POP. Maybe, someday, but we’re not there yet.
9. The physics of quantum computing.
10. The mathematics of quantum computing — linear algebra.
11. A universal quantum computer comprised of all features of a classical computer plus the full set of quantum features. The focus here is solely on the full set of quantum features, excluding the features needed to support a full-blown Turing machine.

Fundamentals of quantum computing

The POP is not intended to offer either an introduction to quantum computing or the detailed fundamentals of quantum computing, but both are essential before the quantum programmer will be able to make sense of the POP.

A standardized fundamentals of quantum computing document is needed. Some of the concepts it would cover include:

• Definition of a qubit.
• Definition of computational basis.
• Probability of quantum states.
• Bloch sphere for quantum states and actions of quantum logic gates. Or at least the three axes of rotation.
• Superposition.
• Entanglement. Bell states.
• Interference.
• Measurement.
• Probabilistic nature of quantum computing.
• Probabilities and amplitudes.
• Quantum logic gate.
• Quantum circuit.
• Quantum program.
• Quantum logic gates must be reversible.
• Quantum errors.

Plain English, please

The jargon of quantum mechanics and linear algebra may be very tempting and is used very commonly in discussions of quantum computing, but it is an explicit goal of this paper to encourage plain English language to the maximal extent possible. Or at least the common language of classical computing if any jargon is needed.

To the extent reasonable, greek symbols should not be used, in favor of plain English. The goal is to be greek-free.

Some of the jargon of quantum mechanics, linear algebra, and quantum computing will certainly be relevant and warranted, but much of it is used to excess and really isn’t needed.

The jargon of quantum mechanics and linear algebra was quite appropriate 20 years ago when quantum computing was still dominated by physicists, but that time is now past, or at least passing quickly. Sure, the physicists should continue with their jargon, just as electrical engineers continue with their jargon for classical computing, but documents such as a POP, intended for consumption by programmers, should have an appropriate level of terminology and usage.

Plain English vocabulary

A lot of the cryptic jargon of quantum mechanics and early quantum computing needs to be replaced with plain English.

The only exceptions are when the existing jargon is more helpful to quantum programmers.

Some examples of terms which need to be simplified if not avoided entirely — in the context of the POP:

• Computational basis, computational basis states
• Basis states
• Eigenvectors
• Eigenvalues
• Ground state
• Excited states
• Logic gates — they’re really operations or instructions
• Unitary matrices
• Coherence
• Interference
• amplitude
• phase
• wavefunction
• Bell states
• Transmon qubits
• Superconducting
• Cryogenic

The goal is not unlike classical computing where the jargon of electrical engineering and integrated circuit design is not needed for software developers.

Much of the vocabulary should be established in the separate fundamentals of quantum computing document, which provides the foundation upon which the POP is built.

Glossary

Both the POP and fundamentals of quantum computing should have reasonable glossaries of the common and important terms.

I have compiled a super-glossary of terminology relevant to quantum computing, with over 2,800 entries:

• Quantum Computing Glossary — Introduction

Some reasonable subset of 50–100 or so terms would be appropriate as a glossary for the POP and fundamentals of quantum computing.

Ket (Dirac bra-ket) notation has to go

The cryptic ket (Dirac or bra-ket) notation for quantum state adds no real value to the lives of quantum programmers. Researchers and mathematicians may prefer it, but it doesn’t facilitate the understanding and use of qubits and quantum logic gates.

Exactly what should replace it remains to be been, but simply using 0, 1, 00, 01, 10, 11, etc. are probably sufficient 99% of the time.

And use a simpler notation such as 0/1 or 0+1 for superposition.

Ditch the Bloch sphere?

The Bloch sphere has only a little utility. It may have some limited utility for teaching the basic concepts of quantum computing, but not much more. Three axes, X, Y, and Z, and that’s all it really does for you.

Most problematic, the Bloch sphere only applies to a single, isolated qubit, and does not extend to multiple qubits or even entanglement of two qubits, so it is indeed of very, very limited utility.

The only real point of the Bloch sphere is that it represents a unit vector from the origin or intersection of the three axes and which can be rotated about any of the three axes as many times and directions as desired.

In short, quantum logic gates need to specify which axis the quantum state vector is being rotated about, but adding the verbiage “in the Bloch sphere” adds no information or real (or complex!) value to the description.

Bridging the world of quantum computing to the world of classical computing

The overarching goal here is to bridge the emerging world of quantum computing to the existing (and evolving) world of classical computing.

To date, the world of quantum computing was able to grow in its own world, but if we want to enable more mainstream applications to utilize quantum computing, we need to start speaking a single, unified language, not two disparate universes.

Of course this will mean introducing a number of novel concepts to the world of classical computing, but that’s not a new process to computing, although the extreme nature of of the quantum world does take the process to a whole new level.

Universal quantum computers?

There is a lack of clarity over the meaning of the term universal quantum computing:

1. A single, unified computing architecture which combines a full set of quantum logic operations as well as all of the features of a classical computer. Capable of executing all programs which are supported by a Turing machine, plus the quantum operations.
2. The full set of quantum logic operations, but none (or very few) of the features of a classical computer. Not capable of executing programs supported by a Turing machine.

I’ve explored the former in my paper, What Is a Universal Quantum Computer?, but that’s more of a pie-in-the-sky pipe-dream rather than anything we either have today or are likely to see in the next few years.

I still want to leave the door open for that ultimate machine, but this paper was written presuming the reality of the latter, limited definition for a universal, general-purpose quantum computer — quantum-only, very few if any classical features, as they are available today and likely to appear over the next few years.

The general concepts of a POP are the same regardless of the details of the computing architecture, but the specific structure and details would vary greatly between these two variants of what constitutes a universal quantum computer.

This paper is prescriptive, not descriptive

This paper is not intended to describe existing documentation of quantum computers, other than mention some in passing, but is instead intended to prescribe what information should be included in any future documentation.

Family of machines

The early days (years and decades) of classical computing were marked by each new machine being rather unique relative to all machines which preceded it, with only modest to moderate similarities at most, but by the mid-1960’s the concept of a family of fairly similar machines became common. It became common to speak of models in a family, with the notion that most if not all programs which ran on one model would run unchanged on other models in the same family.

The concept of the POP is intended to document a family of machines which share details which enable a single program to run unchanged across all models of machines in that family.

To be clear, a family of machines is not the same as units of a machine — all machines manufactured according to identical specifications. The models of a family will each have their own hardware specifications — see the Implementation Specification section, which may be very different between models, even though their POP-level specifications would be identical, other than a few details such as number of qubits or coherence time, but the POP would at least give the minimum specifications which are guaranteed to be common across all models within the family.

Quantum computing is still in its early days, comparable to those early days of classical computing, so each new quantum computer is relatively unique, with only modest to moderate similarity to earlier machines, so the family concept is still not fully relevant, but the writing is on the wall, so within a few years we should see more instances of new machines which are incremental enhancement and extension of existing models, such as focusing on higher qubit counts and longer coherence time, rather than radical changes in architecture. Granted, a particular vendor might introduce a whole new family every few years, but still the models within a given family would have the same POP.

There will of course be differences in technologies and approaches of different vendors, with each vendor likely to define their own family concepts.

At some stage we could well see developments comparable to the Intel X86 architecture where the family concept crosses vendors, allowing programs to be run unchanged on machines from different vendors. That’s not a reality today, and not likely in the near future, but it is worth being prepared for that eventual reality.

The POP and family concepts are still very relevant even if the family has only a single model of machine. In many cases, this may simply the first model of an intended family of machines, with the POP clearly documenting the rules of the road so that quantum programs written for that initial model of the family will more likely be able to run unchanged on new models as they become available.

Details to be specified for a quantum computer

Now on to the actual details which a POP needs to specify for a quantum computer:

1. Vendor name.
2. Product name.
3. Model number or name.
4. Mnemonic name for the model. Such as for selecting from a list of available machines.
5. Number of qubits.
6. Number of states per qubit. Allow for qutrits, qudits, and qumodes.
7. Plain English names for the qubit states.
8. Whether qubits are guaranteed to be initialized to |0>. Seems to generally be true, but documentation should be explicit.
9. Connectivity of qubits. For entanglement. Both as general rules and specific combinations of qubits. Specify which qubits can be used as control qubits, and which qubits can be used as target qubit for each control qubit.
10. Maximum permitted circuit depth. May be a range, with degrees of error. Any special notes related to how many gates can be executed in parallel — until further gates cause sequential processing, adding to depth. Also, detail any gates which expand into multiple gates, increasing circuit depth.
11. Maximum coherence time. Longest quantum program guaranteed to succeed. May be a range, with degrees of error.
12. State coherence time as circuit depth as well as elapsed time.
13. Maximum and average error rate. Specific gates may have their own error rates — see below.
14. Number of gates which may be executed in parallel. Is it any different from the total number of qubits?
15. Total number of gates permitted in a single quantum program.
16. List of quantum logic gates supported. And their details — see below.
17. List of supported unitary matrix values for quantum logic gates. Make it easy to lookup by entry values to get reference to the symbolic gates.
18. List of special gates for preparation of qubit state.
19. List of special gates for measurement of qubit state.
20. List of any common quantum logic gates which are not supported.
21. List of any special gates which are supported by this particular machine
22. List of any gates which are macro sequences of more primitive gates. For example, SWAP.
23. List of any gaps of unitary matrix values which do not have a defined quantum logic gate.
24. List of any configurations of unitary matrices which are not supported or are problematic.
25. What degree of quantum error correction, if any, is automatically provided by the hardware.
26. Number of bits of precision supported for entries of unitary matrices and gate parameters. Single-precision floating point? Double? Quad precision? Exactly how many binary bits and decimal digits of precision are guaranteed to be supported by the POP for the entire family of machines? Clearly document which models of machines in the POP family, if any, have higher precision. Distinguish the software API precision from the firmware and hardware support. The primary goal here is that a quantum programmer can develop quantum programs which run unchanged on all models of machine in the family which the POP covers.
27. Precision of pi required for specification of angles for parameters of quantum logic gates. This may or may not be the same as the precision supported for specification of angles for parameters of quantum logic gates. Especially for pi, pi/2, pi/4, and pi/8.
28. Average quantum logic gate execution time. Individual gates may have differing execution times. See below.
29. Elapsed time required to start a new quantum program. Includes time needed for qubits to be forced to the |0> initial state.
30. Whether quantum program can be resumed after measuring qubits.
31. Whether quantum program can be rerun without manually reloading the program.
32. Whether quantum program can be rerun a specified number of times. Without any explicit external intervention.
33. Whether there is an explicit RESET gate. Exactly what it does and how long it takes to execute. Does it always reset to |0> or can it reset to a random or noise state?
34. Can the quantum consist of more than a single quantum circuit, such as a sequence of circuits with measurements of qubit state after each circuit to condition what the next circuit will look like? What limits are there to how many circuits can be executed for a single quantum program? What is the maximal time delay that the application program can introduce between circuits of the quantum program?
35. Special notes. Any special limitations. Any special modes.

See the following section for a framework for details for individuals quantum logic gates.

Details to be specified for each quantum logic gate

Each quantum logic gate needs the following detail to be defined:

1. Mnemonic name. Alternate mnemonic names as well — indicate preferred mnemonic name. For example, H or X.
2. Short phrase description. Optional. For example, Hadamard transform or bit flip. Alternate phrases as well. For example, Hadamard-Walsh transform.
3. One-line description.
4. Detailed description.
5. Detail citation. Such as a journal article, book, or web page.
6. List of parameters. Mnemonic names, one-line description, detailed description, any limitations on values of parameters, any quantization of values of parameters (e.g., minimum resolution or precision for angle of rotation.)
7. Clearly state the units for all parameters, such as radians for angles.
8. Detail parameterized unitary matrix. Some entries of matrix may be fixed, but some may be a function of parameters of the gate.
9. Provide a table of input quantum state values and the resulting quantum state values after execution of the gate. Including all four Bell states as input values.
10. State clearly if any quantum state values are undefined after execution of the gate.
11. State clearly whether execution of the gate results in quantum entanglement.
12. State clearly what happens to any preexisting entanglement of the qubit(s) referenced by a gate.
13. State clearly what happens to other qubits if they were already entangled with other qubits before execution of the gate. And the resulting state of those other qubits they may have been entangled with. Is re-entangling of two entangled qubits a no-op or identity, or what exactly will happen? Clearly state any cases whose outcome may be undefined.
14. Connectivity restrictions. Such as nearest neighbors only.
15. Whether the gate is a composite gate which expands into multiple gates executed sequentially, impacting circuit depth.
16. Range of execution time. Minimum. Maximum. Average. Distribution, if available. Detail what parameters or other factors impact execution time.
17. Minimum, maximum, and average error rates. Note if different from average numbers across all gates.
18. Stability of pure states, |0> or |1>, over execution of a quantum program. Virtually guaranteed, or as probabilistic and subject to error rates as mixed (superimposed) states.
19. Examples. Especially for any special or distinctive cases.

Any meta-gates, which impact execution but do not necessarily directly impact the state of any qubits, such as:

• Identity gate.
• No-op gate.
• Barrier gate to limit parallel execution of gates.
• Reset.
• Conditional execution.
• Loop execution.

Ultimately, most if not all of this detail for quantum logic gates should be standardized across a wide range of quantum computers. A generic POP, so that everyone won’t have to reinvent the wheel for every new machine.

Expectations for phase

Superficially, phase or phase angle is a continuous value, but theoretically and practically it cannot be an infinitely continuous value — it has to have some degree of granularity, precision, and gradations, which need to be specified for each model of quantum computer. Algorithm designers and application developers need to know:

1. Resolution or precision of phase, phase angle, phase difference, phase shift (rotation.) How fine-grained? How many gradations? How many decimal digits (nines) or classical bits of precision for values, for gates and unitary matrices.
2. Expectation for results of quantum Fourier transform (QFT) and phase estimation. Classical bits of precision of the result, maximum — a range.
3. Resolution or precision for phase estimation. How many classical bits, maximum — a range.

This information affects both gate execution and measurement.

Naming and numbering of qubits

The POP should state clearly how qubits are numbered. Typically they start at 0 (zero) and go to n-1, but that’s not mandatory.

Qubits might also have names, such as Q0, Q1, etc. Again, not mandatory, but any convention should be clearly documented.

User-defined operations

A given quantum computer may or may not support user-defined operations, such as specifying a particular unitary matrix and associating it with a symbolic name.

In any case, the POP should clearly document how this is to be done, or if it can be done at all.

Qubit connectivity

Eventually quantum computers may evolve to the stage where all degrees of connectivity are supported — any two qubits in any order, but current and near-term quantum computers have significant restrictions on connectivity.

Any restrictions on connectivity of qubits should be clearly stated in the POP, both as general rules and specific combinations of qubits. The POP should specify which qubits can be used as control qubits, and which qubits can be used as target qubits for each control qubit.

A table might be nice and appropriate, but is not mandatory.

A formula or set of formulas may also be appropriate, but not mandatory.

In any case, the POP must make it very easy for the programmer to understand which qubits can be entangled, which can be used as control qubits, and which can be used as target qubits.

Composite operations

Some quantum logic gates, such as SWAP, are not really single operations, but a composite of operations, a sequence of individual quantum logic gates which must be executed sequentially to accomplish the composite operation. The POP should make such cases very clear, detailing the composed quantum logic gates, and including any performance implications.

Parallel and register operations

Some quantum computers may support the ability to execute a single operation across an arbitrary number of qubits in parallel, such as the ability to define a register as a collection of continuous qubits and then execute a quantum logic gate on the collection as if the gate were being executed for each individual qubit of the collection. The POP should make such cases very clear, including any performance implications or limits.

Special features

The POP should also document whatever special features a particular machine or its operating software may support, presuming that such features are visible or controllable from a quantum program.

For example:

1. Support for registers and performing gate operations in parallel across all qubits in a register.
2. Support for classical register backing a qubit register. To prepare or measure all qubits of the register in parallel.
3. Support for classical control flow. Such as conditional execution and looping, contingent on measured results in the middle of a quantum program.
4. Pulse-level control of qubits.
5. Debugging features.
6. Ability to reset a qubit to |0> in mid-circuit, during circuit execution.

Support for registers

Quantum computers do not have registers per se in the sense of a classical computer. Except for entanglement between pairs of qubits, each qubit is a discrete entity, analogous to a classical flip-flop.

The programming tools for a quantum computer may syntactically support a conception that behaves as if it were a register to a limited degree, usually in terms of applying a single quantum logic gate to all qubits in the defined register in parallel, but operating on each qubit independently rather than treating the individual qubits as if they were connected as they are in a classical computer (such as for arithmetic on numbers.) The POP should make such cases very clear, including any performance implications or limits.

Specialized machines

Not all quantum computers will be general-purpose machines. This POP framework applies only to general-purpose machines which support quantum circuits consisting of a sequence of general-purpose quantum logic gates.

The D-Wave 200Q from D-Wave Systems is an example. It indeed does some form of quantum computing, focused on optimization, but is not a general-purpose quantum computer per se. In fact, it’s more of an analog computer than a digital computer. That doesn’t make it any less interesting or useful, but does keep it outside the realm of general-purpose quantum computing.

Instruction formats — bit layout, assembly language, and APIs

A classical computer places a lot of attention on precisely how bits and bytes are organized and packed into instruction formats. Operation codes and operations primarily focused on assembly language for symbolically representing machine instructions.

Some quantum computers may support an assembly language.

And some quantum computers may be controlled using an API used within a high-level programming language.

Ultimately the same quantum logic gates will be executed, but the precise syntax with which they are expressed may vary.

The POP should document quantum logic gates in any and all of the forms which programmers of the machine are permitted to utilize.

Bit-level layouts are probably a lot less important in this new era of high-level language APIs, but may in fact be welcome, especially if there are nuances of function which are made more clear using bit layouts. For example, the precision of various quantum logic gate parameters.

API bindings

The API for using a particular quantum computer may look rather different in different programming languages, such as Python, Java, C++, and Lisp. These differences in APIs are referred to as bindings or language bindings, with each programming language having its own binding for a given API function or feature.

Unfortunately, there is no universal API language at present, although Python seems quite popular right now.

Generally, APIs should be specified and discussed in language-neutral terms, such as pseudo-code or tabular form.

Alternatively, APIs in a POP could be specified with multiple bindings to cover the variety of languages expected to be useful for this type of machine.

Whether Python becomes the standard or at least the de facto standard for API language bindings remains to be seen. In any case, vendors could be excused if they jumped on the Python bandwagon at this juncture.

My personal preference and advice is to remain language-neutral as much as possible.

Programming model

The principles of operation is distinct from the programming model. The former specifies what the machine can do and how to control the machine, while the latter gives the programmer guidance as to how to accomplish application-level tasks — how to map application-level functions to machine-level functions.

A programming model employs metaphors to describe how the programmer should think, while the POP merely describes the full details of the most basic functions, the most basic building blocks for software, instructions or quantum logic gates. A programming model focuses more on larger, more sophisticated building blocks, such as functions, objects, classes, data structures, and modules. The POP is the atomic or molecular level of computation, while the programming model focuses on larger structures.

Granted, the programmer needs both, but this paper focuses only on the principles of operation level.

The jury is still out on how best to represent many application-level functions in the language of quantum logic gates. Much more research, experimentation, and development is needed.

Examples

Copious examples should be used for all features in the POP. They may not be exhaustive, but enough to illustrate all significant variations, especially where distinct quantum states cause distinctive results.

Not just examples of inputs, but examples which show the various possibilities for results of particular operations on particular inputs.

Algorithms

Algorithms are extremely important to exploit the capabilities of any computer, classical or quantum.

The programming model will be the place where algorithms begin to flourish.

The POP itself is below the level where algorithms take root. The POP defines the very basic building blocks, the soil, nutrients, water, air, sunlight, gravity, and physical environment where algorithms can be rooted, but doesn’t define what such plants will look like. Algorithms are essentially the DNA for the plants that are expected to grow in a quantum computer. The POP details the individual nucleotides of the DNA, but not the combinations of nucleotides which are composed as algorithms.

Issues related to algorithms for quantum computers are discussed in much greater detail in my paper The Greatest Challenges for Quantum Computing Are Hardware and Algorithms.

Document layout and formatting

This paper takes no position on layout and formatting of a POP document. Not that such matters are not important, but the focus here is on content (function) rather than on form.

Outline and template

Although this paper provides a very rough outline or roadmap for a POP document, it certainly fails to provide a true template for precisely the content and layout of such a document. That’s okay since that is not its intent, but ultimately it would be desirable to have something much closer to a true template.

Or a dummy document for a hypothetical machine.

Machine-readable principles of operation

In addition to a human-readable document, all of the technical details of the POP should be available in XML, JSON, and other structured information formats. This will facilitate comparing machines and also allow applications to query specific details which may be needed.

Machine-readable documentation should be available both a static files, such as on the GitHub repository, as well as a REST API which would facilitate narrow queries for specific details.

Some examples of principles of operation from classical computing

Quantum computers certainly do not have to follow in the precise same footsteps of classical computing, but there’s some value in learning from the hard-learned lessons of classical computing.

An example of this tradition from the 1960’s (1964) — over 50 years ago:

• IBM System/360 Principles of Operation
• IBM System/360 Principles of Operation

That same architecture, as upgraded over 40 years (2004) into IBM’s z architecture:

• z/Architecture Principles of Operation

Or for the common Intel computer architecture (x86):

• Intel® 64 and IA-32 Architectures Software Developer’s Manual

Intel provides a number of volumes, either separately or combined — the link above:

• Volume 1: Describes the architecture and programming environment of processors supporting IA-32 and Intel® 64 architectures.
• Volume 2: Includes the full instruction set reference, A-Z. Describes the format of the instruction and provides reference pages for instructions.
• Volume 3: Includes the full system programming guide, parts 1, 2, 3, and 4. Describes the operating-system support environment of Intel® 64 and IA-32 architectures, including: memory management, protection, task management, interrupt and exception handling, multi-processor support, thermal and power management features, debugging, performance monitoring, system management mode, virtual machine extensions (VMX) instructions, Intel® Virtualization Technology (Intel® VT), and Intel® Software Guard Extensions (Intel® SGX).
• Volume 4: Describes the model-specific registers of processors supporting IA-32 and Intel® 64 architectures.

Some current quantum computing documentation

Doc for quantum logic gates for use in Python for Rigetti Computing:

• http://docs.rigetti.com/en/latest/modules.html#module-pyquil.gates

Rigetti quantum processing unit specifications:

• https://www.rigetti.com/qpu

Quantum instruction language for Rigetti — A Practical Quantum Instruction Set Architecture:

• https://arxiv.org/abs/1608.03355

Open Quantum Assembly Language (OpenQASM) from Quantum Information Software Kit (QISKit) for IBM Q Experience:

• https://arxiv.org/abs/1707.03429
• https://github.com/Qiskit/openqasm/blob/master/spec/qasm2.rst
• https://en.wikipedia.org/wiki/OpenQASM

Simulators

A quantum simulator may be designed to specifically simulate an actual quantum computer with precise accuracy, or be more of a general, abstract simulator with no implied claim that it precisely mimics any particular real quantum computer.

Every simulator should have a detailed POP. If the simulator does indeed match a particular real quantum computer, the details can be by reference rather than duplicated. But usually there will be some differences, if only performance, so any differences or deviations should be very clearly spelled out in the simulator POP.

A special area of difference for simulators, besides raw performance, is quantum noise. Quantum computers are more probabilistic than deterministic, while simulators will tend to be strictly deterministic unless the simulator artificially introduces some element of probability, notably as simulated noise. The POP should clearly state the default degree of probability and noise, as well as any configuration settings to amplify, diminish, or otherwise control the degree of probability and noise.

Irrelevant but interesting hardware details

Information about the hardware of a quantum computer is of course interesting, but not really relevant to the task of developing and using quantum programs at the level of the POP:

1. Technology. Type of hardware architecture. Such as transmon, trapped ion, photonic, etc.
2. Hardware architecture. Unless it impacts what quantum programmers need to know.
3. Photos and diagrams illustrating the qubit hardware.
4. Chip fabrication process.
5. Details for the use of microwaves to control qubits. Such as frequencies.
6. Physical dimensions and configuration of the machine.
7. Operating temperature.
8. Operating environment requirements.
9. External shielding requirements.
10. Internal shielding.
11. Power requirements.
12. External cooling requirements.
13. Cost.
14. Specific details on performance.
15. Configuration parameters.
16. Calibration parameters.
17. Access controls. Who can use it. Any limits on usage.
18. Accounting. Records of usage.
19. Classical computers and firmware needed to operate the quantum computer and make it available as a networked server.
20. REST API or other specialized networked API to allow remote applications to utilize the quantum computer as a coprocessor.

Of course the quantum computer will have user documentation and software documentation beyond the level of the POP, including the Implementation Specification described in the next section.

Implementation specification

A subset of hardware details may not be absolutely required for development of quantum programs, but may well be of interest to the quantum programmer to better understand what is really going on in the physical machine. This may give the quantum programmer valuable insight, but again, the average quantum programmer should be able to fully develop a successful quantum program using only the POP. Some more advanced or specialized development may in fact require detailed knowledge of the implementation.

The implementation specification will be specific to specific models of a quantum computer even if a single POP describes a full family of multiple models of quantum computer.

The implementation specification might ideally be a separate, standalone document, but could also be an appendix to the POP, with multiples appendices for multiple models of a family of quantum computers. Or, it might be a single appendix in tabular form, with columns for each different model.

The implementation specification is distinct from the operations guide for a quantum computer. It’s not about electrical or cooling requirements or physical dimensions, but it would be about performance data.

A separate paper will elaborate the framework for an implementation specification, but some of the general features include:

1. Summary of the overall implementation technology. Plus links to papers with much finer detail.
2. Summary block diagram of the core hardware. Anything needed to support the qubits and gate execution, but excluding electrical, cooling, and physical enclosure.
3. Number of qubits. This may be exactly the same as in the POP, or the POP may be vague or variable, with a range if number of qubits varies by model within a family. This document would be very specific.
4. Table and/or map of qubit connectivity for entanglement or gate execution. Detail any variations of performance data on entanglement and gate execution if not uniform for all combinations of qubits.
5. Schematic and photograph of chip layout of qubits. Highlight major components and connectivity.
6. Physical parameters for each qubit. Size, voltages, frequencies, timing for state changes, whatever.
7. Physical parameters and limits for dynamic qubits such as trapped ions.
8. Physical parameters of major components. Including voltages and frequencies.
9. Implementation details for gates and unitary operators. Any restrictions?
10. Detail the specific hardware operations on qubits required to implement each quantum logic gate or unitary matrix configuration. Detail which gates and unitary matrix configurations expand into multiple hardware operations. For example, the SWAP and H gates. Detail impacts on performance and coherence of such expansions.
11. Gate performance. Average, minimum, maximum, distribution.
12. Coherence times for superposition, entanglement, and interference.
13. How many gates can execute in parallel.
14. Maximum rate of gate execution, throughput.
15. Maximum quantum program size.
16. Time to initialize qubits to |0>.
17. Whether |0> is the only state to which qubits can be initialized.
18. Time to fully initialize for a new quantum circuit.
19. Run rate per second for repetitions of the same quantum circuit.
20. Implementation details for measurement of qubit state. Technology and parameters. Including performance.
21. Number of binary bits and decimal digits of precision actually supported for entries of unitary matrices and gate parameters. Single-precision floating point? Double? Quad precision? In any case, clearly document the precision actually supported by both the firmware and hardware for the machine. This may differ from the precision guaranteed by the POP for a family of machines.

Each simulator should also have its own implementation specification, although it will be less about hardware and more about performance and simulating hardware features, including decoherence.

When might principles of operations documents become available?

Availability of POP documents is an indication of the level of maturity of the industry. The lack of availability indicates that the industry is still rather immature.

I would say that quantum computing is at a comparable level of maturity as classical computers were in the early 1940’s. Maybe in another five years the industry might advance to the level of maturity of classical computers in the early 1950’s. That’s still quite a ways off from classical computing in say the mid to late 1960’s when mainframes and minicomputers can be said to have finally hit their stride.

What’s next

This framework is a work in progress.

It may be a few years before any sense of maturity in specification of principles of operation is achieved for this still-nascent field and industry.

In the meantime, documentation for the detailed principles of operation of quantum computers will remain spotty and uneven at best.

In fact, what is really needed is not to carefully document existing machines, but to focus on incrementally leapfrogging current machines by at least several generations of hardware and architecture to produce systems which are actually able to support real applications rather than relatively toy-like proofs of concept.

I wouldn’t hold out for my own pie-in-the-sky universal quantum computer, but something much closer to it, at least part of that vision.

As I point out in my algorithms paper, The Greatest Challenges for Quantum Computing Are Hardware and Algorithms, the difficulty of developing algorithms for quantum computing is really holding the field back. And very limited hardware is holding algorithms back.

All of that said, each new machine should endeavor to be documented with a POP as defined by the framework presented in this paper.