defcal for reset

[jaygambetta]

Currently, we do not support a defcal for reset.

options add three gates, reset measurement

or can we get it all under one defcal

[blakejohnson]

Just to expand upon what Jay wrote a bit. The central issue here is: what is an acceptable target for a defcal? Right now it is gates + measure as a special case. However, that leaves open the question of how to handle reset, which definitely is problematic because we have typically said that defcals shouldn’t contain control flow, because that breaks the single-threaded control model that is implicit in OpenQASM3.

So, a couple options that were discussed:

1. Allow defcal to also target subroutines (def). Runs into the issue above about control flow.
2. Introduce a concept of a “operation” to QASM3 which is broader than gate but narrower than def. Add measure and reset to this family but also allow the user to add other things.
3. Add an additional special case for reset to defcal .

[jaygambetta]

As we discuss I initially preferred 3 but now like 2 as we can add operations to qasm and then define them to be used like gates. For instance I could envision that we may want to add D_phase(gamma) where we do a dephasing channel which could be implements by a defcal which could be done by adding white noise to a parameter that sets the qubit frequency or entangles with a second qubit and measures it there by doing this operation back on the qubit of interest.

I think we should start going this way (not sure of why for applications yet - maybe there is some bath engineering examples that could be interesting) but for studying noise effects could be interesting and as such I would add operation to qasm which is a bigger than a gate but less than a subroutine but it can not support conditional operations.

[stevenheidel]

In (2) there could also be additional measure-like operations that return level 0 or level 1 data, rather than a `bit.

[taalexander]

In (2) there could also be additional measure-like operations that return level 0 or level 1 data, rather than a `bit.

This could add significant complexity - two potential use-cases:

• Returning qudit measurements
• Real-time control/measurement bootstrapping routines in OpenQASM3.

[levbishop]

To flesh out Blake's suggestion (2): we could allow defcal to also target a new thing more general than unitary gate. Call it "foo" for now because choosing the correct name may be tricky. Just as

gate mygate(type1: param1, type2: param2 ) q1, q2 
{ 
   <mygate_body>
}

defines a unitary gate in order to teach the compiler what the meaning of mygate is, lets have

foo myfoo(type1: param1, type2: param2) q1, q2 -> c1, c2
{
   <myfoo_body>
}

to define teach the compiler what myfoo does, where the parameters and output cbit part of the syntax can be skipped if unused.

For both a foo or a gate we can bind it to a concrete pulse-level implementation with a defcal instruction, which would have to have extended syntax for the cbits (already this is already defined in the spec as a special case for defcal measure)

defcal myfoo(type1: param1, type2: param2) %5, %6 -> c1, c2
{
   <myfoo_pulse_implementation>
}

Remaining questions:

1. Do we need gate and foo since gate is just the unitary subset of foo? Argument in favour of keeping them distinct: you won't accidentally include eg a reset inside a gate body, and will get a useful error message if you try.
2. What to call foo? A foo is a POVM in general, so we could call it povm but in the case where you are defining something like a reset its a bit weird to call that a povm since it has a single effect: Id, and we are unlikely to allow arbitrary POVMs. Maybe a more neutral name is oper or instr?
3. What is allowed in the body of a foo? Consensus seems currently to be for keeping it quite restricted: straight line qasm with no loops, conditionals, qbit/cbit allocation. This would allow the obvious use cases: measurement in a new basis, destructive measurements, isometries. It would not allow things like arbitrary Kraus maps or weak measurements or noisy reset. We can always broaden the allowed contents in the future if needed. Probably the most general thing you can argue for is arbitrary qasm without qubit allocation, and with a guarantee that all paths through the body terminate after a finite time, allowing the compiler in the worst case to build a matrix representation by a brute-force enumeration of what are the operations/effects for the POVM as a function of the parameters. It's not clear that there would ever be demand for this and that the compiler would be anything useful for it anyway.

[stevenheidel]

What is allowed in the body of a foo? Consensus seems currently to be for keeping it quite restricted: straight line qasm with no loops, conditionals, qbit/cbit allocation

If this foo concept is added to cover reset then we still have to decide what actually goes in the body of the defcal reset, do we special case allow for an if statement as long as it has a well-defined time?

[taalexander]

do we special case allow for an if statement as long as it has a well-defined time?

I supposse control-flow only matters to the circuit compiler/scheduler insofar as the qubit instruction POVM can be reasoned about and the duration reported respectively. We might consider the circuit-level scheduling optional as well.