RFC: API for lowering a cirq.Circuit to squin

[david-pl]

Looking for feedback on the API for #283, where we want to add interoperability with cirq.

There is already a draft PR here: #294

The currently chosen API there looks like this:

import cirq
from bloqade import squin

qubit = cirq.GridQubit(0, 0)
qubit2 = cirq.GridQubit(1, 0)

# Create a circuit.
circuit = cirq.Circuit(
        cirq.X(qubit),
        cirq.Y(qubit2),
        cirq.Z(qubit),
        cirq.H(qubit),
        cirq.S(qubit),
        cirq.T(qubit2),
        cirq.Rx(rads=math.pi / 4).on(qubit),
        cirq.Ry(rads=math.pi / 3).on(qubit2),
        cirq.Rz(rads=math.pi / 10).on(qubit),
        cirq.CX(qubit2, qubit),
        cirq.CZ(qubit, qubit2),
        cirq.measure(qubit, key="m"),  # Measurement.
    )

kernel = squin.load_circuit(circuit)

kernel.print()

The created kernel is a method as it would be when defined using the @squin.kernel decorator on a function. So we can then run passes / rewrites on that and throw it e.g. into a pyqrack simulator.

There are still some features missing (e.g. noisy circuits) and the API is still up for discussion.

Note, that we are also looking into potentially adding support to create a circuit from a kernel in the future. Just to keep that in mind, although there should no be discussion on this part in this issue.

[jon-wurtz]

How to make the qubit registers usable elsewhere? In what order? By what labels? QuEraComputing/bloqade#249.

[david-pl]

How to make the qubit registers usable elsewhere?

@jon-wurtz Good point! I hadn't thought of that and right now there's just a new register being created that is of the appropriate size.

Down the line, if we do something like QuEraComputing/bloqade#249, this won't actually be needed here. Or am I misunderstanding?

Regardless, I think you are correct that we need this in the short term too, until we have something more general.

How about this:

• We could add a returns keyword, similar to what we have in qasm2.loads, allowing the user to specify what should be returned from the kernel. However, a circuit doesn't really return anything, so it might make sense to be more restrictive (e.g. just allowing returning the quantum register or a measurement of the register).
• Now, another tricky part here is that the qubits are actually defined outside the circuit.
  • We can allow the user to specify whether the register should be passed in as argument.
  • If it's not an argument, we can allow the user to pass in a name for a register that is created internally.

The result may be something like this:

kernel = squin.load_circuit(circuit, returns="q", qreg_name="q", qreg_as_argument=False)

That API isn't super nice and a bit overloaded, but may serve the purpose until we have something better.

In what order?

Right now we're just creating a register of the correct size and index into it in a "first come, first serve" fashion, i.e. they are in the order the are accessed within the circuit. Now, don't tell me that's not sufficiently user friendly 😛

Jokes aside, I'd suggest we just order them by the Qid, which is what cirq uses to order them as well. I'm not sure how to fetch all Qids from the circuit yet, but I'll figure it out.

[Roger-luo]

Is it possible to generate a kernel with a single argument that is an IList of qubits? I'm not sure if this has a compatible meaning to how you declare qubits in cirq, e.g via LineQubit

[david-pl]

This has been implemented already.