I've been working on this project in private for a fairly long time, there is quite a bit of work to be done especially on the documentation side as well as with making the components readily available, I think the best option is to start by re-formatting the existing documentation and theory of operation for the 8Q core processor, from there I need to create a new library for the logic gates and control circuitry in KiCAD.

Making the computer linux ready I don't foresee taking incredibly long as I've made the decision to isolate the quantum circuitry entirely from the digital circuitry and communicate over some form of digital bus.

I'm still debating whether to use the SPI to communicate with the quantum processing unit or if I should use the (much) faster (and much more complex) PCIe ports available on the H6.

Going with the PCIe side of things, as the design improves and the materials used shrink down (currently the QPU is going to be the size of a small table!), it would be advantageous to have PCIe capabilities from the start, you'd be able to upgrade any existing PC with the QPU without making any major hardware changes. As far as performance and the like goes, there isn't really any major advantage to be achieved as we're expecting these to start off painfully slow.

The ISA for the QPU is pretty much defined by the hardware and is a hard constraint, but if we want it to be compatible with existing quantum programming languages like e.g. OpenQASM, we need to do a little bit more to reduce the number of instructions required for the end user. This may also be a hard requirement due to the significant speed differences between the electrical and optical circuits. (Yes, electricity travels close to the speed of light, but not close enough for us to discount it entirely).

Basically you need to send instructions to the QPU in incredibly tight time constraints, and the QPU needs to execute them similarly. This is particularly the case with controlled gates which need to fire ancillary photons so that they arrive simultaneously with the control and target qubits to reduce unwanted phase synchronization problems. To reduce these time constraints from angstroms to something more reasonable with macro-scale hardware, we've introduced delay loops which allow just enough time (on the order of ms) for the QPU control logic to execute a single instruction; we could increase the delay loops to allow for more instructions, but every increase in latency exponentially increases the error rate (which is bad). There's far too much to get into with this, but ultimately we need a simplified ISA for our QPU/CPU bridge.

We also really should take the time to create an algorithm to determine success probabilities of a given algorithm to determine the number of times you need to repeat a given operation (and ultimately how long the operation will take), ideally this would be taken care of by the compiler, but given the fact we are working with exponential failure rates I think it would probably be very useful to have the QPU do some verification on its' own and raise a conditional error dependent on a flag so people don't inadvertently send a program that can't successfully be run in less than a reasonable time (e.g. several days).

Finally, we need to write a compiler for our new ISA; I'm looking to target a reduced version of OpenQASM to start as it's the Quantum Assembly Language I'm most familiar with.

Anywho, short summary of work to be done on the 8Q Core:

• Reformat Documentation For Github/ReadTheDocs
• Decide PCIe vs SPI
• Create a Simplified Instruction Set Architecture For QPU/CPU Bridge
• Upload KiCAD Libraries
• Create Pre-Processing Success Probability Algorithms
• Design QPU/CPU Bridge & QPU Controller