Incorrect NONBLOCKING Example?

[kalzoo]

Background

In the Quil-T proposal / de facto spec, there's these two following lines:

Re: blocking pulses:

The execution of a pulse operation on a frame blocks pulse operations on intersecting frames, i.e. frames with a qubit in common with the pulse frame.

Re: nonblocking pulses:

A pulse operation (PULSE, CAPTURE, and RAW-CAPTURE) with the NONBLOCKING modifier does not exclude pulse operations on other frames.

Then there's this example:

NONBLOCKING PULSE 0 "xy" flat(duration: 1.0, iq: 1.0)
PULSE 0 1 "ff" flat(duration: 1.0, iq: 1.0)

with the description

the two pulses could be emitted simultaneously. Nonetheless, a NONBLOCKING pulse does still exclude the usage of the pulse frame, so e.g. NONBLOCKING PULSE 0 "xy" ... ; PULSE 0 "xy" ... would require serial execution.

Problem

This is not inherently inconsistent, and can be implemented as-is. However, it adds complexity and possibly confusion for the program author, in that the behavior of the blocking PULSE is modified by the NONBLOCKING modifier on the earlier PULSE. I'll refer to these (from the cited example) as instruction [0] and [1]. I'd propose that the behavior of the blocking PULSE - that it is the only instruction executing on all common-qubit frames - should not be modified by other instructions in the program.

In this case, [0] uses only 0 "xy" but does not use or block any other frames. However, [1] still blocks 0 "xy" because it is not NONBLOCKING. In my opinion, that should mean that these two instructions cannot be scheduled concurrently.

The metaphor: [0] sits at the table, occupies a seat, but doesn't reserve any other seats. [1] sits at the table but wants to reserve a number of seats, and [0] is sitting in one of those seats. Just because [0] doesn't care doesn't mean that the two are compatible and can sit together at the table, and thus (escaping the metaphor) doesn't mean that the two should run concurrently.

Proposal

I can ship an MR to this effect depending on feedback, but I'd change the example to specifically include the concurrent pulse-and-capture pattern used in readout, and to retain this example but as a counterexample and clarify that the two would not be concurrent.

I'd also add the verbiage:

Within an instruction block, an instruction which uses a frame must start execution after all previous instructions which use or block that frame, and complete execution before all later instructions which use or block that frame.

[braised-babbage]

I agree that the current behavior could be a real source of confusion. And actually, even if we kept the current behavior, I think the document could be clarified.

My memory is a bit fuzzy on why this turned out the way that it did, but I think the main reason for supporting the seemingly contradictory notion of "play a pulse which thinks that it owns some qubits, while at the same time sneaking in some other pulses" is not just for readout, but to also support certain techniques for correcting crosstalk. In this setting, you may have a program which plays some pulses to perform some gates, and you'd like to add in correction pulses (perhaps on a blocked frame, I don't know) which otherwise do not change the timing of the program.

If the original pulse is PULSE 0 1 "ff" flat(duration: 1.0, iq: 1.0) and the correction is PULSE 0 "xy" flat(duration: 1.0, iq: 1.0) then combining these to get (with existing quilt semantics)

...
NONBLOCKING PULSE 0 "xy" flat(duration: 1.0, iq: 1.0)
PULSE 0 1 "ff" flat(duration: 1.0, iq: 1.0)
...

does the trick. With your proposal, we'd need

...
NONBLOCKING PULSE 0 "xy" flat(duration: 1.0, iq: 1.0)
NONBLOCKING PULSE 0 1 "ff" flat(duration: 1.0, iq: 1.0)
...

which also does the trick. However, the scheduling of ... could be different in this second program, due to the lack of exclusion. But I suppose this could be dealt with via

...
FENCE 0 1
NONBLOCKING PULSE 0 "xy" flat(duration: 1.0, iq: 1.0)
NONBLOCKING PULSE 0 1 "ff" flat(duration: 1.0, iq: 1.0)
FENCE 0 1
...

or something similar.

So in short, I think what you suggest makes sense, as long as whatever NONBLOCKING tricks that have traditionally been used can be supported or done away with under the revision.