Introduction

The main purpose of the HAL is to establish a unified northbound API-based framework across different QPU technologies. The challenges and architectural issues we endeavour to resolve in developing the HAL are:

  1. Defining the position of Multi-level HAL within the system stack (see Fig. 1 below) 1

  2. Maximising portability with minimal loss of performance

  3. Maximising the range of common features, while keeping the optional, hardware dependent features at a minimum

  4. Supporting for advanced features such as compiler optimisations, measurement-based control, and error correction

_images/image1.png

Fig. 1 Positions of Multi-level HAL layers within the QPU system stack

The HAL APIs considered in this document MAY be divided into the following groups:

  • General APIs These are most common APIs across different interfaces and platforms.

    • Register/De-register APIs

    • Discover APIs

    • HAL/APIs authentication/authorisation

    • HAL versioning

  • Technical area specific (QPU System related)

    • Metadata of the system capabilities/properties

    • Required HAL/QPU commands

    • Optional HAL/QPU hardware specific commands

  • Technical area specific (QPU System advanced features related)

    • HAL supported level authentication and authorisation

    • HAL Advanced/Optional features

Currently there are libraries similar to QHAL, such as Microsoft’s QIR or the MLIR quantum dialect designed for use in quantum compilers like qcor, XACC, and the Q# compiler.

1

Metadata is part of the HAL, and in some cases, it seems that data may reflect details of the lowest levels of the QPU stack including some details of the qubit implementation to help guide cross-implementation translation. The CPU could be involved in translation too, especially if it changes across implementations as should be anticipated (example: a constant representing the CPU architecture).