QAT (Quantum Assembly Toolkit/Toolchain) is a low-level quantum compiler and runtime which facilitates executing quantum IRs such as QASM, OpenPulse and QIR against QPU drivers. It facilitates the execution of largely-optimised code, converted into abstract pulse-level and hardware-level instructions, which are then transformed and delivered to an appropriate driver.
For the official QAT documentation, please see QAT.
QAT can be installed from PyPI via:
pip install qat-compiler
We use poetry for dependency management and run on
Python 3.8+.
Once both of these are installed run this in the root folder to install all the dependencies that you need:
poetry install
Note
If you are contributing to the project we recommend that you also run
poetry run pre-commit install
to enable pre-commit checks.
Here's a list of what we're currently working on, if you want to get involved contact the person or group linked.
In-development:
- Classical-quantum hybrid computation. John Dumbell
- Runtime-embedded QEC. Jamie Friel
Designing / verifying suitability:
- Distributed QPU execution. John Dumbell
To-do:
- Full QASM v3 support. Currently waiting for available parsers.
To take the first steps towards contributing to QAT, visit our contribution documents, which provides details about our process. We also encourage new contributors to familiarise themselves with the code of conduct and to adhere to these expectations.
For support, please reach out in the Discussions tab of this repository or file an issue.
This code in this repository is licensed under the BSD 3-Clause Licence. Please see LICENSE for more information.
Please let us know your feedback and any suggestions by reaching out in Discussions. Additionally, to report any concerns or code of conduct violations please use this form.
The performance of QAT can be measured using our pre-defined benchmarks: poetry run pytest --benchmark-only.
To compare to main, checkout the main branch and run poetry run pytest benchmarks/run.py --benchmark-only --benchmark-save="<benchmark-name>".
Then checkout back to the branch you are working and run poetry run pytest benchmarks/run.py --benchmark-only --benchmark-save="<benchmark-name>" --benchmark-compare --benchmark-compare-fail=min:50%.
If the test fails, it might indicate a performance regression: use the comparison table that is outputted to verify.
The performance of pull requests to main will be automatically tested.
See the pytest-benchmark documentation for more information on how to use it.
Why is this in Python?
Mixture of reasons. Primary one is that v1.0 was an early prototype and since the majority of the quantum community know Python it was the fastest way to build a system which the most people could contribute to building. The API's would always stick around anyway, but as time goes on the majority of its internals has been, is being, or will be moved to Rust/C++.
Where do I get started?
Our tests are a good place to start as they will show you the various ways to run QAT. Running and then stepping through how it functions is the best way to learn.
We have what's known as an echo model and engine which is used to test QATs functionality when not attached to a QPU. You'll see these used almost exclusively in the tests, but you can also use this model to see how QAT functions on larger and more novel architectures.
High-level architectural documents are incoming and will help explain its various concepts at a glance, but right now aren't complete.
What OS's does QAT run on?
Windows and Linux are its primary development environments. Most of its code is OS-agnostic but we can't guarantee it won't have bugs on untried ones. Dependencies are usually where you'll have problems, not the core QAT code itself.
If you need to make changes to get your OS running feel free to PR them to get them included.
I don't see anything related to OQC's hardware here!
Certain parts of how we run our QPU have to stay propriety and for our initial release we did not have time to properly unpick this from things we can happily release. We want to release as much as possible and as you're reading this are likely busy doing just that.
Do you have your own simulator?
We have a real-time chip simulator that is used to help test potential changes and their ramifications to hardware. It focuses on accuracy and testing small-scale changes so should not be considered a general simulator. 3/4 qubit simulations is its maximum without runtime being prohibitive.