riverlane / qhal

:no_entry: [DEPRECATED] A Quantum Hardware Abstraction Layer developed in the context of UK ISCF consortium

⛔ [DEPRECATED] Migrated to http://qhal.npl.co.uk/

QHAL - Quantum Hardware Abstraction Layer

Scope and Purpose

This document sets out a Hardware Abstraction Layer (HAL) for quantum computers (QHAL) based on four leading qubit technologies: superconducting qubits, trapped-ion qubits, photonic systems and silicon-based qubits. The aim is to define a multi-level HAL that makes software portable across platforms but not at the cost of performance. The HAL allows high-level quantum computer users, such as application developers, platform and system software engineers, cross-platform software architects, to abstract away the hardware implementation details while keeping the performance.

Disclaimer

This specification must be considered a work in progress. The document is currently used to guide discovery, initiate discussion and enable future improvements. Even though all the parties involved are putting their best efforts on verifying the validity and correctness of what is stated, extensive reviews are still to be conducted. This disclaimer will be removed once the document reaches sufficient maturity.

Contributors

Company/Entity
ARM
Duality Quantum Photonics (DQP)
Hitachi Europe Ltd (HEU)
National Physical Laboratory (NPL)
Oxford Ionics (OI)
Oxford Quantum Circuits (OQC)
Riverlane (RL)
Seeqc
Universal Quantum (UQ)

Current version

The specification file gets updated every time a merge into the dev branch happens. Any PR that entails a change to the specification PDF document will not get built until merged into the dev branch, so during a PR any changes on the PDF that need to be inspected can be viewed as an artifact of this workflow. See specification for the latest version.

Testing framework and code examples

More information are provided at code and testing

License

see License here

qhal's Issues

Reordering HAL command _OPCODES into mandatory and optional commands?

Would it make sense to reorder _OPCODES in HAL commands into a code section of mandatory and a consecutive code section of optional commands?

Reason: At the moment the list of optional commands is growing quite extensively making it hard to keep track of commands which must be supported by all partners. If partners keep adding optional commands to the list of _OPCODES it may become hard to identify the mandatory core commands from the code in the future.

Emulator specific commands

Would it make sense to introduce emulator specific commands? Would it make sense to make these commands mandatory?

1. Sample N shots : Would sample N shots from the full qubit register after executing a quantum circuit.
2. Probability in Zero : Would return a vector of probabilities to have qubits 0,...,M-1 in zero state.

Reason:

• Saves computing effort for emulation based on state vector or density matrix propagation.
• Emulation may be equally important to a user.

command creator returns wrong results when angle is negative

UQ HAL has been complaining when command packer is used with negative angles. There might be an issue with the below snippet form _commands.py

cmd = (
(opcode.code << Shifts.OPCODE.value)
| (arg0 << Shifts.ARG0.value)
| qidx0
)

when arg0 is negative and bitwise or is performed, all the prepended 1's to represent the negative number ( 2's complement ) overrides fields before it ( bitwise or with 1s ). This results in a wrong packed result being returned from command creator.
There are other few places where similar bitwise operations are performed in the codebase which would need changing.

One way to fix this would be to bitwise mask each field before the bitwise or.