Proposal: Calibrating conditional reset

[antalsz]

Calibrating conditional reset

Summary

This proposal extends Quil with the ability to define the behavior of RESET 0 to be a conditional RESET made up of existing measurements and gates. Conditional reset uses measurement as a building block, and so this proposal interacts with how measurement is specified in Quil; thus, this proposal as written builds on the "named measurements" proposal, although alternatives that don't are also presented.

Motivation

Quil provides a RESET instruction for resetting qubit state. However, the Quil-T pulse-level control extension doesn't provide any way to lower RESETs to analog control instructions, as it does for arbitrary gates and measurements; the details of RESET are left entirely opaque. This is understandable, as there are many different ways one might implement RESET, not all of which are expressible in Quil-T as it stands. However, as NISQ systems grow more capable, we'd like to begin having the ability to talk about RESET.

In particular, this proposal focuses on conditional RESET, which is almost but not quite expressible in plain Quil. Recall that conditionally resetting a qubit, in outline, is implemented by the following algorithm:

1. Measure the qubit.
2. If it was found to be in the 1 state, execute an X gate on it.
3. Repeat this process n times for some positive integer n.

This is almost equivalent to the following Quil program:

# An almost-implementation of `RESET q`

DECLARE reset_count INTEGER # Loop counter
DECLARE reset_ro BIT # Readout result

# Set up the "repeat n" loop
MOVE reset_count n
LABEL @reset_loop

# Reset q one time
MEASURE q reset_ro
JUMP-UNLESS @reset_done reset_ro
X q
LABEL @reset_done

# Loop
SUB reset_count 1
JUMP-WHEN @reset_loop reset_count

However, the problem with this program is that it occupies the whole quantum abstract machine; nothing can happen in parallel while the machine is jumping around. At both the abstract machine level and the pulse-control level, it is important that RESET 0 not require juggling the program counter of the full Quil program around. Thus, we need some way to specify the behavior of conditional reset at a lower level than plain Quil-T.

This focuses on conditional reset, but that's not the only way to reset a qubit. The change proposed here is deliberately designed to be forwards-compatible with future ways of calibrating RESET such as a pulse-based unconditional RESET; we want to provide the features we need currently without foreclosing further evolution.

Proposed change

Recall the outline of conditional reset provided above:

1. Measure the qubit.
2. If it was found to be in the 1 state, execute an X gate on it.
3. Repeat this process n times for some positive integer n.

Even if we assume that Quil's RESET is to be realized as as conditional RESET, each of these three steps must be lowered to the hardware separately:

1. Which measurement calibration do we use?
2. Which X gate calibration do we use?
3. How many times should we repeat this (i.e., what's n)?

Quil-T has existing facilities for specifying measurement and gate calibrations; all that remains is providing a way to link these calibrations to RESET and to specify the repeat count. We propose handling this by using a pragma to specify each of these three things for an individual RESET operation. For instance, to specify that RESET 0 should be implemented using MEASURE[midcircuit] for the measure, using RX(pi) for the X gate, and executing three iterations, we might write:

PRAGMA RESET 0 CONDITIONAL 3 "MEASURE[midcircuit]; RX(pi)"

The grammar for this pragma is as follows:

⟨Conditional Reset Pragma⟩ ::= PRAGMA RESET ⟨Formal qubit⟩ CONDITIONAL ⟨Integer⟩ "⟨Conditional Reset Calibrations⟩"

⟨Conditional Reset Calibrations⟩ ::= MEASURE ([ ⟨Identifier⟩ ])? ; ⟨Identifier⟩ (( ⟨Expression List⟩ ))?

The name of the pragma is RESET, and it is followed by the qubit whose behavior is being specified; if this is a formal qubit, it defines the behavior for every explicit single-qubit RESET that does not reset a qubit which has a concrete PRAGMA RESET. The qubit is then followed by the word CONDITIONAL to indicate that we are defining this RESET to be conditional reset; this allows PRAGMA RESET to be extended in the future to define other forms of reset. Finally, we provide the three parameters that define conditional reset: a positive integer specifying the number of iterations (it is an error for this to be zero or negative), and then, in quotes, the name of the measurement operation and the name of the X gate separated with a semicolon. (This presumes the "named measurements" proposal has been adopted; see the "Alternative designs" section for details on how we might approach this without that proposal in place.) The provided qubit to reset will then be measured with the provided measurement and flipped with the provided X gate; for instance, our above PRAGMA RESET would produce the following more precise outline of conditional reset.

1. Perform a MEASURE[midcircuit] 0 reset_ro for some reserved memory location reset_ro that is a BIT.

2. If reset_ro is 1, perform an RX(pi) 0

3. Repeat this process 3 times.

It is almost the case that this would be entirely sufficient to calibrate conditional reset without needing to modify the Quil specification, since it lives entirely in a PRAGMA, but it would still be worthwhile to include it in the specification. This is because a PRAGMA RESET, coupled with an actual RESET that matches it, causes the measurement and gate in that pragma to be used in the program. Existing tooling that, say, tries to remove unused DEFCALs might see a program containing the above PRAGMA RESET but no other references to MEASURE[midcircuit] 0 addr or RX(pi) 0 and attempt to remove the corresponding DEFCALs, causing the simplified program to be invalid. (This is not a hypothetical; Rigetti's initial implementation of active RESET ran into precisely this problem even without user-provided calibrations!) For more discussion on this, see the "Issues" section.

Unresolved questions

PRAGMA vs. a new DEFCAL vs. a new keyword

It is a little bit unusual to specify this calibration-like structure by using a PRAGMA, which usually corresponds to a form of interaction with the system running the program. One can argue this is the case for RESET, but it feels a lot like a calibration. We could thus alternatively specify the behavior of RESET by introducing a new form of DEFCAL, specifically DEFCAL RESET qubit AS CONDITIONAL, which allows us to specify the repeat count, measurement, and X gate in its body. For example, to replace the PRAGMA RESET 0 CONDITIONAL "MEASURE[midcircuit]; RX(pi)" from above, we could write

DEFCAL RESET 0 AS CONDITIONAL:
    REPEAT 3
    MEASURE[midcircuit]
    RX(pi)

Unlike existing DEFCALs, this would not correspond to a simple replacement of RESET 0 with the body of the DEFCAL; RESET would remain an atomic operation even in a Quil-T program that has had all other calibrations expanded. Indeed, the body of DEFCAL RESET _ AS CONDITIONAL is not legal Quil: it contains the keyword RESET, an integer, and then the names of two operations.

This might feel too dissimilar from existing DEFCALs, so we could also introduce a new Quil-T operation just for RESET:

DEFRESET 0 AS CONDITIONAL:
    REPEAT 3
    MEASURE[midcircuit]
    RX(pi)

This would have the same semantics as the above, but – like DEFFRAME – could not be removed from the program even after calibrations have been fully expanded. It would technically break existing programs that use a gate or variable named DEFRESET (and, depending on how we implement it, CONDITIONAL), but I don't expect this to be a problem in practice.

I am genuinely not sure which of the three options is the best. The advantage of PRAGMA RESET is that it almost doesn't require updating existing implementations that ignore unknown pragmas, and in fact barely needs to be included in the Quil-T specification at all. But perhaps we don't want to shoehorn every new feature into a PRAGMA?

Names vs. instructions

Should the user have to specify full measure and gate applications instead of just their names? Right now, we assume that measurement and X for conditional reset will always be operations that apply precisely to the qubit being reset, and so we provide a short form for the calibration. But we could be more explicit and future-proof things:

PRAGMA RESET 0 CONDITIONAL 3 "MEASURE[midcircuit] 0 _; RX(pi) 0"

DEFCAL RESET 0 AS CONDITIONAL:
    REPEAT 3
    MEASURE[midcircuit] 0 _
    RX(pi) 0

DEFRESET 0 AS CONDITIONAL:
    REPEAT 3
    MEASURE[midcircuit] 0 _
    RX(pi) 0

Ultimately I think this does not provide any extra clarity, and raises questions about what to put for the memory location that is to be measured into (left as an underscore above).

Alternative designs

If implemented as specified above, the design of this feature as requires the "named measurements" proposal, and if we use DEFCAL RESET or DEFRESET, it requires updating the Quil specification as well. But we can provide an implementation of this feature without named measurements, working solely with pragmas. There are two approaches here, both corresponding to alternative designs outlined in the "named measurements" proposal; for calibrating conditional RESET, they may be more useful, even if only as a stopgap measure until named measurements are adopted.

First, we could replace the MEASURE[midcircuit] part of the PRAGMA RESET with a gate name, and then use a PRAGMA to indicate that a DEFCAL for a gate is actually for a measurement. In this case, the pragma would provide the address parameter that would normally be part of a DEFCAL MEASURE. For our running example, that would look like

PRAGMA DEFCAL MEASURE midcircuit dest
DEFCAL midcircuit 0:
    ... dest ...

PRAGMA RESET 0 CONDITIONAL 3 "midcircuit; RX(pi)"

As outlined in the "named measurements" proposal, while this doesn't require any parsing extensions to Quil, tooling may still need to be aware of it; simplification of calibrations would try to remove this calibration for what looks like an "unused" gate named midcircuit, and tooling that attempted to check that DEFCAL bodies were well-formed would be caught off guard by the undefined dest. (See the "Issues" section for related discussion.)

More aggressively, we could simply inline the measurement calibration into the PRAGMA. In this case, I would propose using multiple pragmas, such as the following:

PRAGMA RESET 0 CONDITIONAL REPEAT 3
PRAGMA RESET 0 CONDITIONAL MEASURE "some; very; long; Quil-T; code"
PRAGMA RESET 0 CONDITIONAL X "some; other; very; long; Quil-T; code"

The primary virtue of this design is that it would require no updates to any tooling that wasn't thinking about RESET. The downside is that it's unergonomic to write and there's an additional constraint that we specify all three of these pragmas. Any feature can be defined to live in a PRAGMA in this way, but although it might be worthwhile here, there's a reason we don't generally do that.

Note also that I have expanded the calibration of the X, rather than writing PRAGMA RESET 0 CONDITIONAL X "RX(pi) 0". This is to make sure that the design here is entirely independent of existing tooling; in particular, it avoids the simplification issue described above, where a simplification pass could break programs by eliminating a seemingly-unused RX(pi) 0 calibration if RX(pi) 0 is only used in PRAGMA RESET CONDITIONAL X. (This is also discussed further in the "Issues" section.) Because the primary virtue of this design is that it is entirely compatible with existing tooling, avoiding this seems particularly beneficial.

Issues

I have not yet written the necessary text for §12.6 "Defining Calibrations" in Annex T. I am presently waiting until the design is specified precisely to write up the concrete text, but I expect it to borrow very heavily from this proposal document.

As discussed above, tooling may still need to be aware of this proposal even if it is implemented through PRAGMAs due to RESET making the measurement and gate mentioned in the PRAGMA RESET used. This raises the concern that a user might write a Quil program using PRAGMA RESET, pass it through existing tooling that is unaware of PRAGMA RESET, and silently get a buggy program back. If DEFCAL RESET or DEFRESET were used, this would not be an issue because the program would not be accepted by the unupdated tooling; if the three-PRAGMA implementation were used, then this would not be an issue because the behavior of RESET could be specified without reference to existing calibrations at all.

This change requires extending some existing implementations of Quil, including quil-rs and possibly also Quilc. This is not prohibitive, but is work that would need to be done. The PRAGMA-based designs attempt to avoid changes to Quilc, although due to the simplification issues mentioned above, it's not clear if they succeed. I would be happy to make the necessary changes to both the aforementioned projects.

[antalsz]

This is the second of three proposals related to measurement in Quil; see also #90 and #92.

[mhodson-rigetti]

What is the behavior under RESET with no arguments? The specification says this resets all qubits. I assume it would pick up any subset of PRAGMA directives for qubits within that full set and apply them, with defaults being used for the other qubits?

[antalsz]

That was my intended implication – that RESET with no arguments would need PRAGMAs to exist for every qubit in the program. (I expect, like for regular gates, that in a Quil-T aware environment, execution won't be supported without a PRAGMA just like gates need a calibration.) I agree that this should be clarified in the text.

[kalzoo]

This raises the concern that a user might write a Quil program using PRAGMA RESET, pass it through existing tooling that is unaware of PRAGMA RESET, and silently get a buggy program back.

In any of these cases, we could make RESET require a PRAGMA, right? Rather than the current (interim) behavior of assuming RX(pi) and MEASURE. This would prevent silent miscompilations.

I think that's a wise idea regardless - RESET must be calibrated, just as a gate. To @mhodson-rigetti 's question about unqualified RESET, we would need to formalize how "all the qubits in the program" is computed (e.g., does it include those named in DEFFRAME? Do calibrations need to be expanded/introspected? e.g. if MY_GATE 0 does not actually use qubit 0, and nothing else does, do we RESET qubit 0? and so on). I don't recall that being in the spec.

---

In both syntax options - pragma and DEF - I think we should be more explicit about the feedback and measurement blocks rather than "implying" them in the ordering of the body of the reset. You do mention that here, in the scope of dropping the dependency on #90 :

More aggressively, we could simply inline the measurement calibration into the PRAGMA

Just for color, a way to mix these options is a hybrid of a DEFCAL and DEFFRAME:

DEFCAL RESET 0 AS CONDITIONAL:
    REPEAT: 3
    FEEDBACK:
       ... body
    MEASUREMENT:
       ...

a benefit to that it that it keeps them (feedback, measurement) grouped; as you say, "The downside is that it's unergonomic to write and there's an additional constraint that we specify all three of these pragmas"

I'm not sure if I like that, and it may add more reserved words. Nowhere else in the spec explicitly supports nested blocks AFAICT but I don't think anything precludes them. It's also possible to make this exactly like a defframe and just have the values be strings, where the FEEDBACK and MEASUREMENT strings are stringified Quil (as with the PRAGMAs). I'm not enthusiastic about that option

---

I see a benefit in being able to inline RESET bodies directly in whatever format we use, so that:

• simplification stays simple
• reset can be customized without having to add a new calibration

But - for the user's benefit - we will want to publish mid circuit measurement calibrations for their direct use, and will likely just reuse those within our reset calibrations. So in practice we will likely not inline them in the calibrations we publish.

---

Formalizing support as a DEFCAL rather than a PRAGMA feels right but not strongly necessary. I do like the AS CONDITIONAL in that it leaves room in the syntax for other constructions.

---

[antalsz]

@kalzoo

This raises the concern that a user might write a Quil program using PRAGMA RESET, pass it through existing tooling that is unaware of PRAGMA RESET, and silently get a buggy program back.

In any of these cases, we could make RESET require a PRAGMA, right? Rather than the current (interim) behavior of assuming RX(pi) and MEASURE. This would prevent silent miscompilations.

Yes, that's not the concern I'm thinking about; that's the behavior I imagine we'd implement for our Quil-T–aware systems. I'm concerned about the case where PRAGMA RESETs are present but RESET-unaware simplification strips out the calibrations it refers to. Buggy isn't perhaps the right word; this will never produce code that does the wrong thing, but it can cause the simplification systems to happily output code that cannot compile in a Quil-T–aware system.

Although that said, I suppose there's an edge case where program behavior does change. Consider the following program. It has two RX calibrations, one general one for RX(%theta) and one specific one for RX(pi). However, the only use of the RX(pi) calibration is by the PRAGMA RESET. This means that a RESET-unaware simplification program could strip the RX(pi) calibration, and then RESET would unexpectedly fall back to using the RX(%theta) calibration.

DEFCAL RX(%theta) 0:
    …

DEFCAL RX(pi) 0:
    …

DEFCAL MEASURE 0:
    …

PRAGMA RESET 0 CONDITIONAL 3 "MEASURE; RX(pi)"

RESET 0
RX(pi/2) 0
MEASURE 0

we would need to formalize how "all the qubits in the program" is computed

Very good points. What behavior do we think makes sense? I'd be inclined to say either "every qubit in a DEFFRAME" or "every qubit that was actually used in the end"; I think in-between solutions are probably more confusing.

[using FEEDBACK and MEASUREMENT in a DEFCAL RESET] may add more reserved words.

We could use what are called "soft keywords", where they're only reserved in that context (the behavior I was imagining for REPEAT), or we could take advantage of the fact that Quil already reserves the keywords X and MEASURE which have precisely the right meanings here. (That's harder for REPEAT; the only options I see are HALT: 3, CALL: 3, JUMP: 3, and DECLARE: 3, all of which I dislike.)

Nowhere else in the spec explicitly supports nested blocks AFAICT but I don't think anything precludes them.

I don't think it's ambiguous, but would require some probably-significant rewriting; the spec as written requires 4-space indents that directly follow a newline. In §3.2 "Syntactic rudiments":

An indent is defined as exactly four spaces at the start of a line. Indents in Quil programs can only happen following a newline.

⟨Indent⟩ ::= ⟨Newline⟩ ⟨ASCII 32⟩⁴

It's also possible to make this exactly like a defframe and just have the values be strings, where the FEEDBACK and MEASUREMENT strings are stringified Quil (as with the PRAGMAs). I'm not enthusiastic about that option

I agree; I think if we're going to cram things in strings we should just use a PRAGMA.

I see a benefit in being able to inline RESET bodies directly in whatever format we use, so that:

• simplification stays simple

If we want the option of referring to non-inlined calibrations – and it sounds like we do – then simplification isn't any simpler, because it has to handle the case where they aren't inlined. ¯\_(ツ)_/¯

• reset can be customized without having to add a new calibration

I'm not sure how much of an advantage this is; the only overhead to adding a new calibration is the line DEFCAL MEASURE[my_reset_calibration] 0:

Formalizing support as a DEFCAL rather than a PRAGMA feels right but not strongly necessary.

Agreed.

[erichulburd]

The design path you embraced was motivated by "the problem ... that it occupies the whole quantum abstract machine; nothing can happen in parallel while the machine is jumping around" (in reference to a solution implemented with jumps and labels).

Question - is conditional reset, as we intend to implement it, of a known duration on hardware at compile time? If so, I wonder if we can distill this conditional reset pattern to lower-level constructs.

The first requirement would be a repeat block. Stim, for instance, has a repeat n { ... } block (for example see getting_started.ipynb). Repeat blocks would need to be parameterized by a compile-time constant when compiling for hardware. An alternative here would be just a re-invocation of DEFCIRCUITs. It's ugly, but aligns with the intention of DEFCIRCUIT as a preprocessor and should be compatible with calibration expansion as quil-rs implements it today.

The second requirement would be a conditional gate application. This can be done with Quil today using labels and jumps, as you mention, but recognizing this through static analysis is a challenge. The FORKED gate modifier is illustrative in syntax, but isn't what we want either as FORKED gates are purely quantum and can be expressed as 2 qubit unitary. Therefore, I suggest something like CONDITION c <Gate Application>, where c is a classical bit.

If those two requirements are met, then we should be able to express the contents of the DEFRESET or DEFCAL RESET in ordinary Quil without any additional new syntax.

[antalsz]

@erichulburd: Good questions there. Yes, as we intend to implement it, conditional RESET has a fixed duration – it's not if MEASURE 0 { X 0 }, but rather if MEASURE 0 { X 0 } else { DELAY 0 exactly_the_duration_of_an_X_0 }. I think changes to Quil to support this would be pretty invasive, though, and probably further away than just adding these calibrations. That said, here's me thinking it over.

I looked at the Stim notebook you shared, but it looks like Stim's repeat blocks are too powerful; from the example, the repeat is occurring on every wire, if I followed it right (please let me know if I didn't). The specific behavior we need is "repeat on just this qubit" (or, at the Quil-T level – and that may be all that matters here – "repeat on just this frame"). That said, we can do manual unrolling; that might work fine for our purposes.

As for conditional gate application – CONDITIONED c X 0 would be interesting, but getting the compilation model right could be tricky, since at the Quil-T level, this is most useful if it has a constant duration (otherwise, you could just implement it as JUMP-UNLESS c @after; X 0; LABEL @after). Still, that might be generically doable. If we suppose that we can add CONDITIONED c modifier and correspondingly useful DEFGATEs and/or DEFCALs, then the running PRAGMA RESET 0 CONDITIONAL 3 "MEASURE[midcircuit]; RX(pi)" could become a calibration adding literal text:

DEFCAL RESET 0 AS SEQUENCE:
    DECLARE reset_bit BIT
    MEASURE[midcircuit] 0 reset_bit
    CONDITIONED reset_bit RX(pi) 0
    MEASURE[midcircuit] 0 reset_bit
    CONDITIONED reset_bit RX(pi) 0
    MEASURE[midcircuit] 0 reset_bit
    CONDITIONED reset_bit RX(pi) 0

This might generate less efficient code if we couldn't generate a static loop, but it's possible we could add some sort of constant-iterations-only loop that would have the right semantics. I'm much fuzzier on how to do that, though, and I haven't thought through the full ramifications on the semantics of Quil if we try to add explicit concurrency like that.

[erichulburd]

Two follow up comments, then I'll exit stage left and leave it up to you and the Quil lang team to decide.

I think changes to Quil to support this would be pretty invasive, though, and probably further away than just adding these calibrations.

I understand where that perspective comes from (I think), but I'd contend that a lower level / general approach provides a clearer separation between the quil specification and hardware implementation details. The goal here would be to avoid introducing a new sub-syntax and knowledge of a particular reset hardware protocol.

the repeat is occurring on every wire, if I followed it right (please let me know if I didn't

That's not necessarily wrong, but I would assume that for any given repeat block, we could perform some static analysis to determine on which frames the repeat block plays, and the maximum duration of instructions between those frames; multiply that maximum duration by some constant multiple and then we would have a statically known duration for a repeat block that could then be inserted into its parent block as a higher level instruction with a known duration.

[antalsz]

So I've been implementing the "plain PRAGMA" approach to try to make progress on this so that we can figure out what we need before trying to formalize a DEFCAL RESET operation, and as a result:

1. I am more convinced we need DEFCAL RESET.
2. I have an idea for how it should look.

In particular, I do want to borrow @kalzoo's double-indented-blocks idea, I think it's the clearest option, and I want to set it up like so:

DEFCAL RESET 0 AS CONDITIONAL:
    REPEAT: 3
    DEFCAL MEASURE:
        PULSE …
        CAPTURE …
    DEFCAL X:
        PULSE …

Note the extra DEFCALs. This is specifically to allow a future extension where we say MEASURE: MEASURE[reset] and X: RESET_X if that turns out to be useful. The grammar for specifying this is as follows:

⟨Raw Indent⟩ ::= ⟨ASCII 32⟩⁴ | ⟨ASCII 9⟩

⟨Indent⟩ ::= ⟨Newline⟩ ⟨Raw Indent⟩

⟨Double Indent⟩ ::= ⟨Newline⟩ ⟨Raw Indent⟩²

⟨Reset Calibration⟩ := DEFCAL RESET ⟨Formal Qubit⟩ AS CONDITIONAL : ⟨Reset Repeat Count⟩ ⟨Reset Measure Calibration⟩ ⟨Reset X Calibration⟩

⟨Reset Repeat Count⟩ ::= ⟨Indent⟩ REPEAT : ⟨Integer⟩

⟨Reset Measure Calibration⟩ ::= ⟨Indent⟩ DEFCAL MEASURE : (⟨Double Indent⟩ ⟨Instruction⟩)*

⟨Reset X Calibration⟩ ::= ⟨Indent⟩ DEFCAL X : (⟨Double Indent⟩ ⟨Instruction⟩)*

This does impose some extra semantic complications on Quil-T, but only on Quil-T:

• Expanding calibrations needs to perform expansion in the body of the DEFCAL RESET, not just the main program.
• RESETs have a DEFCAL but don't expand to anything.

The only work that extends out to plain Quil is at the syntactic level:

• Parsing this new construct.
• Optionally reserving REPEAT as a keyword – but this isn't necessary, it could be a soft keyword since there's nothing else that would be legal at that position, and indeed that was my plan.
• Supporting tabs for indentation, which is an attempt to reflect existing practice and could be omitted.

I wonder about @erichulburd's idea of having a pulse-level construct that would in fact perform the whole loop, but this feels very hard to specify. The upside would be that we could remove the semantic complications in Quil-T, and that is a promising option if we can figure out how.