How Programs Are Built & Run
Last updated
Last updated
Rigetti QCS is designed to run programs as you write them:
In Quil or another language
As a gate-model (e.g. Quil) or pulse-model (e.g. Quil-T) program
For an ideal topology or native to a live hardware device
Optimized by the Quil compiler (quilc), an alternative compiler, or by hand
The below diagram shows the workflows available to the QCS user to run a program on a live QPU.
A native Quil program uses only the qubits, edges, gates, and reference frames available on the target device. A non-native program requires nativization prior to execution, where the elements used in your program are remapped onto those which exist on the target device.
As shown, there are three ways you can write programs for QCS:
A non-native gate-model program using Quil
A native gate- and/or pulse-model program using Quil
A non-native, gate-model program written in a language with a Quil integration
Let's take a look at the individual components here:
quilc is the Quil Compiler, which can perform advanced optimization for a program to target a specific, characterized hardware device. It operates on gate-model programs only. See the quilc reference for more information.
We support several integrations to run programs written in other languages on QCS, including Qiskit/QASM, Cirq, and QIR. See the references for each. All of these, underneath, rely on transpilation to Quil; QCS only natively accepts Quil for execution.
Quil programs themselves may be gate-model, pulse-model, or a combination of the two. In all cases, programs are decomposed into pulse-model programs on arrival at the QCS Translation Service.
The QCS Translation Service is itself responsible for the compilation of Quil programs to the machine code necessary to run that program on our control hardware.
In order to be compiled for hardware, a Quil program must be native.
A gate-model program must fully decompose into a pulse-control program using the provided Quil calibrations. Those calibrations are themselves a Quil program which can be prepended to your own program.
A pulse-model program must use only the frames defined within the program in its PULSE, CAPTURE, and RAW-CAPTUREinstructions.
Further, the program must use only the supported subset of Quil instructions. For example, most classical instructions - such as JUMP and ADD - are not supported for execution on live hardware.
Quil programs are compiled into a target-specific machine-code binary by the QCS Translation Service:
First, this service applies the current, default Quil-T calibrations to your program. This expands gates into pulse instructions, and serves as the practical definition for what is native on that target device. Input programs may be a mix of gate-model and pulse-model instructions.
For closer control over your program's execution, you can modify these calibrations and expand them locally using pyQuil or quil-rs, rather than leaving that to the service. See the Quil-T documentation for more information.
Certain program settings, such as frame frequencies and slow-flux settings, may not be altered by the user and must be used as-is. DEFFRAME instructions, for example, are viewable by the user for your reference but may not be altered.
The resulting machine code executable is encrypted and cannot currently be inspected or modified by the user. This is for the safety of Rigetti systems. This encrypted job must be returned by the client to QCS as-is for execution, together with program parameter values.
The Quil simulator, QVM, is simple to use:
It operates on Quil directly and does not need or accept a QCS-encrypted binary for execution.
All topology and standard gates are native by default on QVM. You can, however, use pyQuil to supply a device-specific or custom topology for simulation.
It supports all non-pulse-model Quil instructions, including classical arithmetic and control flow.
