I was trying to figure out how scheduling works in IBM devices.
The thing that's bugging me is that in the quantum computer implementations I had seen before, the cycle concept is used. Say, for example, a cycle = 20ns. And all operations take that time or multiples of that time. This is handy because things like parallelism and depth can then be defined using this cycles concept, which makes things like scheduling very clear.
With IBM machines, however, the duration of the primitivies can vary a lot, as seen on IBM's Github repo containing this information. We can see that the time it takes to perform a CNOT gate varies a lot, depending on the link. Let's have an example to motivate the question. If I define the following circuit in Qiskit:
q = QuantumRegister(14, 'q')
c = ClassicalRegister(14, 'c')
circ = QuantumCircuit(q, c)
circ.cx(q[1], q[0])
circ.cx(q[1], q[0])
circ.h(q[3])
circ.h(q[3])
circ.h(q[3])
print(circ)
The output of the print command will be (with the tracks for q[x>=4] trimmed since nothing was happening on those qubits):
In IBM's Q16 Melbourne device, the duration of each Hadamard gate is 100ns (+ 20ns buffer) and for this specific CNOT gate (q[1]
, q[0]
) is 678ns (+80ns buffer). These values can be checked on the repository mentioned before.
If may look, from the printed circuit, that the 3 Hadamards on q[3]
would take more than the 2 CNOTs, but that is not the case. This raises some questions regarding how gates are actually scheduled on the device:
1 - Which gates were executed in parallel? The 3 Had gates can be executed faster than a single CNOT gate. Or was each Hadamard gate synchronized with the CNOT? If it's the 1st then this circuit output is pretty misleading, if the 2nd, when there's a lot of lost time for qubit q[3]
.
So reformulating the question: would the gates on q[3]
be executed asynchronously?
2 - Defining depth as the number of gates in the longest track, as compared to the number to cycles, or time to the circuit to end can be misleading. In this case, the depth of the circuit is 3, even though the upper track takes much more time. Is there a way to extract a circuit runtime?
3 - How does this synchrony / asynchrony gets translated when compiling to a OPENQasm file?