Dependency of architecture on hardware

Question

How much of a role does the type of hardware used to implement the building blocks (like qubits, the circuits, the communication channels,quantum RAM etc.) have to play when designing the architecture for a full scale quantum computer?

My own thoughts on the matter: Architecture should not depend on the way the hardware is realised. Because if it did, then every time someone came up with a novel design for the hardware, it would require rethinking the architecture - not a bad idea if you are looking to improve your architecture but that rethinking should be born out of a desire to improve the computer in general and not simply accommodate some new RAM implementation.

Answer 1

It's a not-so-ideal-world and in short, architecture of quantum computers depends A LOT on the "hardware" used. There are currently several "models" for physical implementation of quantum computers and all of them require considerably distinct architecture. For example superconducting quantum computers have to be kept at close to absolute zero temperature. In trapped ion quantum computers there are lasers applied to induce coupling between the qubit states. For optical quantum computers you need linear optical elements (including beam splitters, phase shifters, and mirrors) to process quantum information, and photon detectors and quantum memories to detect and store quantum information.

Here's a list of the common architectures, as stated on Wikipedia:

• Superconducting quantum computing (qubit implemented by the state of small superconducting circuits (Josephson junctions))
• Trapped ion quantum computer (qubit implemented by the internal state of trapped ions)
• Optical lattices (qubit implemented by internal states of neutral atoms trapped in an optical lattice)
• Quantum dot computer, spin-based (e.g. the Loss-DiVincenzo quantum computer) (qubit given by the spin states of trapped electrons)
• Quantum dot computer, spatial-based (qubit given by electron position in double quantum dot)
• Nuclear magnetic resonance on molecules in solution (liquid-state NMR) (qubit provided by nuclear spins within the dissolved molecule)
• Solid-state NMR Kane quantum computers (qubit realized by the nuclear spin state of phosphorus donors in silicon)
• Electrons-on-helium quantum computers (qubit is the electron spin)
• Cavity quantum electrodynamics (CQED) (qubit provided by the internal state of trapped atoms coupled to high-finesse cavities)
• Molecular magnet (qubit given by spin states)
• Fullerene-based ESR quantum computer (qubit based on the electronic spin of atoms or molecules encased in fullerenes)
• Linear optical quantum computer (qubits realized by processing states of different modes of light through linear elements e.g. mirrors, beam splitters and phase shifters)
• Diamond-based quantum computer (qubit realized by electronic or nuclear spin of nitrogen-vacancy centers in diamond)
• Bose–Einstein condensate-based quantum computer
• Transistor-based quantum computer – string quantum computers with entrainment of positive holes using an electrostatic trap
• Rare-earth-metal-ion-doped inorganic crystal based quantum computers(qubit realized by the internal electronic state of dopants in optical fibers)
• Metallic-like carbon nanospheres based quantum computers.

Answer 2

At the current state of the art, quite a bit. As pointed out by the other answer, different architectures implement qubits in different physical substrates, which results in radically different techniques to generate, evolve, interact and measure the qubits. Moreover, different operations are easier in some architectures than in others.

To get something more similar to how we usually program classical computers one needs some kind of compilation pipeline, mapping a given computation, expressed in an abstract high-level language, down to the specific hardware details of a given architecture. This is still a work in progress, but there are people working in this direction. A relevant work that comes to mind is 1604.01401. Here is the pipeline proposed in this paper:

In theory, having software suites implementing such a pipeline would allow to write abstract code and have automatically compiled down to work on, say, superconducting chips as well as optical or ion-trap quantum computers.

In practice, there are so many things to still work out (first of all how to actually make scalable quantum computers) that it is hard to say how such scheme will work.