Support for virtual Z compilation

[AdriaanRol]

Support for virtual-Z gates is highly desirable to increase the flexibility/efficiency of the programs generated by OpenQL, increasing the performance of the resulting circuits. Virtual-Z gates make use of zero-duration pulses, instead changing the phase of all proceeding single-qubit rotations to encode the operation. Further reference on this topic can be found on McKay et all, Efficient Z-Gates for Quantum Computing.

Given the fact that phase changes to a specific waveform are encoded in new waveforms, codeword space management is highly important and may even be a worthy optimization parameter for the compiler to take into account. Therefore, the functionality described in issue #265, concerning pulse-level compilation features (and, in particular, the first point on waveform table generation) is highly relevant to this subject.

Concurrent work on this subject may even lead to native hardware support for this functionality being added. Updates on that should be taken with @AdriaanRol

[MiguelSMoreira]

Support for virtual-Z gates is highly desirable to increase the flexibility/efficiency of the programs generated by OpenQL, increasing the performance of the resulting circuits. Virtual-Z gates make use of zero-duration pulses, instead changing the phase of all proceeding single-qubit rotations to encode the operation. Further reference on this topic can be found on McKay et all, Efficient Z-Gates for Quantum Computing.

Given the fact that phase changes to a specific waveform are encoded in new waveforms, codeword space management is highly important and may even be a worthy optimization parameter for the compiler to take into account. Therefore, the functionality described in issue #265, concerning pulse-level compilation features (and, in particular, the first point on waveform table generation) is highly relevant to this subject.

Concurrent work on this subject may even lead to native hardware support for this functionality being added. Updates on that should be taken with @AdriaanRol

[jvansomeren]

This is what I understand from the paper, please correct me when I'm wrong; this is input to a discussion so that you all know what I think is the issue. The use case of virtual Z gates is as follows: When having a circuit with X and Y gates as primitive, both are not accurate. When we would transform this circuit to X and Z gates, with Z done in software, only the X is not accurate and the total is more accurate. The transformation from X/Y to X/Z can be done by a compiler of the circuit. I see it as replacing Y rotations by equivalent sequences expressed in X and Z, and then optimizing the resulting circuit. The optimization is similar to optimizing sequences of clifford gates to a minimum sequence. The Z state can be kept in classical code/registers.

[AdriaanRol]

@jvansomeren , I think your explanation of the use-case is inaccurate. I'll try to clarify.

When having a circuit with X and Y gates as primitive, both are not accurate.

Correct,

When we would transform this circuit to X and Z gates, with Z done in software, only the X is not accurate and the total is more accurate.

The normal way of doing a Y-rotation is already by updating the phase of the X-gate. Hence in both cases the hardware implementation is identical.

An example use-case is as follows. Use case 1.

• X q0
• CZ q0,q1
• X q0

We do an X gate on q0. We do a CZ gate on q0, q1. Due to some physical mechanism an extra phase is acquired on q0. This phase (Z rotation by some angle) can be corrected by either (a) performing a physical Z-operation which is noisy and needs to be calibrated to exactly that angle, or (b) by updating the phase of all subsequent operations, which is "perfect".

Use case 2. We are performing a VQE experiment. X q0 Z(32.5deg) q0 Y q0

The first operation is a standard operation. The second (Z operation) requires some custom angle. This can either be implemented using a physical operation or compiled into all subsequent microwave gates. so that no physical operation is required.

Let me know if you have any questions.

[jvansomeren]

These are descriptions at the system-level. Below, let us assume we have flexible waveform management/allocation support. I'd like to come to a series of descriptions of what:

• what the OpenQL compiler can do (circuit transformation: forward pass of dep graph updating gates/angles
• what the OpenQL compiler QISA code generator should do differently, codewords, etc.
• what should be done after the OpenQL compiler, but still in software
• any hardware issues?

[jvansomeren]

Let us look at use case 2 above. Into which circuit should this be transformed? Please use cQASM in the description of the output circuit.

[MiguelSMoreira]

In light of the fact that virtual-Z gates are now directly supported in hardware, the need for virtual-Z support in software (through compilation) is no longer required. This issue will be closed.