feat: allow skipping Measure's acquisition delay in subsequent operations

Explanation of changes

When scheduling a Measurement quantify accounts for a delay between sending a signal and being able to measure this. This is controlled by the qubit parameter <qubit>.measure.acq_delay and is the sum of the delay caused by the finiteness of cables together with the time it takes a hardware equipment to generate and play a waveform (on Qblox hardware 146 ns).

This delay however also shifts subsequent operations forward in time which is inefficient and unwanted. See the following images for clarification

image

image

new API

To prevent the wasted time (see figure 2), we added a new keyword argument to the Measure gate,

schedule.add(Measure("q0", apply_acquisition_delay=False))

Setting apply_acquisition_delay=True is the default behavior as before, but setting it to False will effectively shift subsequent operations acq_delay back in time.

Note that you will have to pass , apply_acquisition_delay=False to all Measure operations, not just the first one.

We've written some integration tests: test_acq_delay.ipynb

Motivation of changes

Motivate why the particular solution was chosen.


Merge checklist

See also merge request guidelines

  • Merge request has been reviewed (in-depth by a knowledgeable contributor), and is approved by a project maintainer.
  • New code is covered by unit tests (or N/A).
  • New code is documented and docstrings use numpydoc format (or N/A).
  • New functionality: considered making private instead of extending public API (or N/A).
  • Public API changed: added @deprecated and entry in deprecated code suggestions (or N/A).
  • Newly added/adjusted documentation and docstrings render properly (or N/A).
  • Pipeline fix or dependency update: post in #software-for-developers channel to merge main back in or update local packages (or N/A).
  • Tested on hardware (or N/A).
  • CHANGELOG.md for breaking changes and AUTHORS.md have been updated (or N/A).
  • Update Hardware backends documentation if backend interface change or N/A
  • Check whether performance is significantly affected by looking at the Performance metrics results.
  • Windows tests in CI pipeline pass (manually triggered by maintainers before merging).
    • Maintainers do not hit Auto-merge, we need to actively check as manual tests do not block pipeline

For reference, the issues workflow is described in the contribution guidelines.

Merge request reports

Loading