iqm-pulse 9.20.0__tar.gz → 10.0.0__tar.gz

{iqm_pulse-9.20.0 → iqm_pulse-10.0.0}/CHANGELOG.rst

@@ -2,6 +2,26 @@
 Changelog
 =========
 
+Version 10.0.0 (2025-07-16)
+===========================
+
+Breaking changes
+----------------
+
+- :class:`.CompositeGate` subclasses must now include all their member gates in :attr:`.CompositeGate.registered_gates`.
+  The subclasses should apply the member gates using :meth:`.CompositeGate.build`.
+- Removed the :meth:`.PRX_SinglePulse_GateImplementation.iq_pulse` alias, use ``.pulse`` instead.
+- :func:`.register_implementation` no longer can register or define a QuantumOp.
+  :func:`.register_operation` is introduced for that purpose.
+
+Version 9.21.0 (2025-07-10)
+===========================
+
+Bug fixes
+---------
+
+- Fix instructions with same field names being treated as equal in building the playlist
+
 Version 9.20.0 (2025-07-09)
 ===========================
 
@@ -192,7 +212,7 @@ Version 8.12.0 (2025-04-03)
 ===========================
 
 Feature
-*******
+-------
 
 - Format code and enable PEP 604 in linting rules, :issue:`SW-1230`.
 
@@ -209,7 +229,7 @@ Version 8.10.0 (2025-04-02)
 ===========================
 
 Features
-********
+--------
 
 - Update the documentation footer to display the package version.
 

{iqm_pulse-9.20.0/src/iqm_pulse.egg-info → iqm_pulse-10.0.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.1
 Name: iqm-pulse
-Version: 9.20.0
+Version: 10.0.0
 Summary: A Python-based project for providing interface and implementations for control pulses.
 Author-email: IQM Finland Oy <info@meetiqm.com>
 License:                                  Apache License

{iqm_pulse-9.20.0 → iqm_pulse-10.0.0}/docs/API.rst

@@ -1,4 +1,4 @@
-API Reference
+API reference
 =============
 
 .. autosummary::

{iqm_pulse-9.20.0 → iqm_pulse-10.0.0}/docs/concepts.rst

@@ -1,4 +1,4 @@
-Concepts and Classes
+Concepts and classes
 ####################
 
 This section gives an overview of the main concepts and terminology in IQM Pulse.
@@ -20,7 +20,7 @@ The assembly of a Playlist, or a batch of quantum circuits, can be summarized as
   assumed to be preserved. A quantum circuit corresponds to one segment.
 * What is executed during a segment is determined by a **Schedule**.
 * A Schedule is a set of hardware control channels, each with a strictly timed sequence of **Instructions**.
-* A Schedule is formed by scheduling a **Timebox**.
+* A Schedule is formed by scheduling a number of **Timeboxes**.
 * A TimeBox can contain other TimeBoxes without precise relative timing,
   or it can be atomic, in which case it contains a single **Schedule**.
 
@@ -68,7 +68,7 @@ Instead, the magic happens on the client side so that it is transparent to the u
 Schedules
 ---------
 
-:class:`~iqm.pulse.playlist.schedule.Schedule` contains a number of control channels, each with a lists of Instructions.
+:class:`~iqm.pulse.playlist.schedule.Schedule` contains a number of control channels, each with a list of Instructions.
 All channels in a Schedule start executing at the same instant, and the timing is defined by the duration of the
 individual Instructions.
 Schedules can be thought of as a fixed block that occupies some interval on a timeline of some channels.
@@ -87,7 +87,7 @@ Whereas a Schedule is a container with strict relative timing, a :class:`.TimeBo
 relative timing.
 Each TimeBox can be labeled using a human-readable label describing it, and operates on a number
 of *locus components*, using some of their control channels.
-A composite TimeBox contains other TimeBoxes as children, whereas atomic TimeBoxes contain a Schedule.
+A composite TimeBox contains other TimeBoxes as children, whereas atomic TimeBoxes contain a single Schedule.
 
 TimeBoxes are the main language in which users define the order and relative alignment of execution elements, be it
 gates, Schedules, or larger TimeBoxes.
@@ -95,10 +95,10 @@ gates, Schedules, or larger TimeBoxes.
 A key process is the scheduling, in which TimeBoxes are resolved recursively into a fixed Schedule.
 When resolving, all Schedules inside the TimeBox are concatenated and are either left-aligned (ASAP) or right-aligned
 (ALAP), respecting the hardware constraints.
-Importantly, if some TimeBoxes have content on disjoint channels, the Schedules are allowed to happen simultaneously.
+Importantly, if some TimeBoxes have content on disjoint channels, their Schedules are allowed to happen simultaneously.
 If they have content on partly overlapping channels, the Schedules are concatenated while preserving their internal
 timing.
-Any interval that does not have explicit instructions is filled with Wait Instructions.
+Any interval that does not have explicit instructions is filled with Wait instructions.
 The figure above demonstrates how TimeBoxes are resolved.
 
 The syntax and rules are explained in more detail in :doc:`using_builder`.
@@ -106,56 +106,60 @@ The syntax and rules are explained in more detail in :doc:`using_builder`.
 QuantumOps
 ----------
 
-A higher-level concept, a :class:`.QuantumOp` can represent a unitary quantum gate,
-or for example a measurement operation (not all QuantumOps necessarily represent a unitary gate).
-QuantumOps are simple, abstract, self-contained actions one can execute on a station as parts of a quantum circuit.
-They include quantum gates like PRX, CZ, and measurements and resets.
-Whereas Schedules and Instructions act on control channels, QuantumOps act on named components on the QPU, such as
-qubits or computational resonators.
+A higher-level concept, a :class:`.QuantumOp` (quantum operation) can represent a unitary quantum gate like PRX or CZ,
+or a nonunitary operation like a measurement or a reset.
+QuantumOps are simple, abstract, self-contained actions one can apply on the quantum state of the QPU
+as parts of a quantum circuit.
+Whereas Schedules and Instructions act on control channels, QuantumOps act on *loci* which are ordered sequences of
+QPU components, such as qubits or computational resonators.
 
-A QuantumOp has unambiguous definition in terms of its *intended* effect on the computational subspace of the
-QPU component, but it can be *implemented* in various ways.
+A QuantumOp has an unambiguous definition in terms of its *intended* effect on the computational subspace of its
+locus components, but it can be *implemented* on a station in various ways.
 Each implementation is represented as a GateImplementation.
 
 The list of available QuantumOps at runtime can be obtained with :func:`iqm.pulse.builder.build_quantum_ops`.
-A new QuantumOp can be registered at runtime, together with an implementation, with
-:func:`iqm.pulse.gates.register_implementation`.
+A new QuantumOp can be registered at runtime using :func:`iqm.pulse.gates.register_operation`.
 
 GateImplementations
 -------------------
 
 A :class:`.GateImplementation` bridges the gap between QuantumOps and TimeBoxes.
+It represents the concrete control signals sent to the station in order to apply a QuantumOp.
+Despite the name, GateImplementations are used to implement all QuantumOps, not just unitary quantum gates.
+
 When a user requests a QuantumOp from :class:`.ScheduleBuilder` with specific parameters and locus components, the
 chosen GateImplementation (usually the default) for the operation is used to produce a TimeBox.
 This TimeBox, usually atomic, contains a Schedule on the appropriate control channels.
-The Instructions within are constructed following the calibration values from the ScheduleBuilder.
+The Instructions within are constructed using the calibration values for that operation, implementation and locus
+from the ScheduleBuilder.
 
 All gate implementations are listed in :mod:`iqm.pulse.gates`.
 Section :doc:`custom_gates` explains how to add more implementations.
-
+A new GateImplementation can be added to a known (registered) QuantumOp using
+:func:`iqm.pulse.gates.register_implementation`.
 
 Playlists
 ---------
 
 Once all TimeBoxes are scheduled into large Schedules, one for each segment/circuit,
-the Schedules are collected into a :class:`.Playlist`.
+the Schedules are collected into a :class:`~iqm.models.playlist.playlist.Playlist`.
 The Playlist is the final product that is sent to Station Control.
 Its contents are compressed by indexing all unique Instructions and waveforms on each channel,
 and representing the control channels in each segment as lists of Instruction indices.
 
 During execution, the segments in the Playlist are executed in order, and the whole sequence is repeated
-a number of times equal to the number of repetitions (shots).
+a number of times equal to the number of repetitions (shots) requested.
 
 Segments are separated in time by **end delay**, a parameter outside the Playlist.
 A long end delay can be used to prevent quantum information carrying from one segment to the next,
 thus resetting the qubits.
 Alternatively, the reset can be encoded in each segment as a long Wait instruction or using some active reset scheme.
 
-Station Control aims to execute all segments together, but sometimes this is not possible due to various memory
-constraints.
+Station Control aims to execute all segments one after another in one go, but sometimes this is not
+possible due to various memory constraints.
 In case the whole Playlist does not fit in memory, the segments are split into chunks which are executed separately.
 The delay between chunks is undefined.
 Therefore, the time between segments is guaranteed to be at least the duration of the end delay, but can be much larger.
 
 :func:`.inspect_playlist` provides a neat visual representation of the playlist, as blocks of instructions on a
-timeline.
+timeline.

{iqm_pulse-9.20.0 → iqm_pulse-10.0.0}/docs/conf.py

@@ -183,6 +183,7 @@ intersphinx_mapping = {
     "scipy": ("https://docs.scipy.org/doc/scipy-1.6.3/reference", None),
     "xarray": ("https://docs.xarray.dev/en/stable", None),
     "exa.common": ("../exa-common", "../../exa-common/build/sphinx/objects.inv"),
+    "iqm.models": ("../iqm-data-definitions", "https://iqm.gitlab-pages.iqm.fi/qccsw/iqm-data-definitions/objects.inv"),
 }
 
 use_local_target = os.getenv("USE_LOCAL_TARGET", "").lower()

{iqm_pulse-9.20.0 → iqm_pulse-10.0.0}/docs/custom_gates.rst

@@ -4,29 +4,29 @@ Custom gate implementations
 QuantumOp
 ---------
 
-Quantum gates are represented by :class:`~iqm.pulse.quantum_ops.QuantumOp` data classes, containing the required
-metadata to define the gate. A QuantumOp is identified by its :attr:`~iqm.pulse.quantum_ops.QuantumOp.name`, and
-:attr:`~iqm.pulse.quantum_ops.QuantumOp.arity` defines number of locus components the operation acts on. For example,
-the PRX operation (Phased X Rotation) is a single-qubit operation, so its arity is 1, whereas the CZ (Controlled-Z) gate
+Quantum gates are represented by :class:`.QuantumOp` data classes, containing the required
+metadata to define the gate. A QuantumOp is identified by its :attr:`~.QuantumOp.name`, and
+:attr:`.QuantumOp.arity` defines number of locus components the operation acts on. For example,
+the ``prx`` operation (Phased X Rotation) is a single-qubit operation, so its arity is 1, whereas the ``cz`` (Controlled-Z) gate
 acts on two qubits, having arity 2. Arity 0 has a special meaning that the operation in question can act on any number
-of components (for example :class:`~iqm.pulse.gates.barrier.Barrier`).
+of components (for example ``measure`` or ``barrier``).
 
-The attribute :attr:`~iqm.pulse.quantum_ops.QuantumOp.symmetric` defines whether the effect of the quantum operation
+The attribute :attr:`.QuantumOp.symmetric` defines whether the effect of the quantum operation
 is symmetric with respect to changing the order of its locus components. As an example, the CZ gate is a symmetric
 two-qubit gate, whereas CNOT (Controlled-NOT) is not symmetric.
 
 Some quantum operations are defined as "functions", taking one or more parameters to define the effect. These
-arguments are stored in the attribute :attr:`~iqm.pulse.quantum_ops.QuantumOp.params`. As an example, the PRX gate
+arguments are stored in the attribute :attr:`.QuantumOp.params`. As an example, the PRX gate
 takes two arguments, ``angle`` (the rotation angle with respect to the z-axis of the Bloch sphere), and ``phase``
 (the rotation phase in the rotating frame). On the other hand, many operations do not require any parameters, in
 which case this field is an empty tuple (e.g. the CZ gate).
 
 A QuantumOp has unambiguous definition in terms of its *intended* effect on the computational subspace of the
 QPU component, but it can be *implemented* in various ways. Each implementation is represented as a
-:class:`~iqm.pulse.gate_implementation.GateImplementation` subclass. A QuantumOp stores its known implementations in the
-field :attr:`~iqm.pulse.quantum_ops.QuantumOp.implementations`. Note that even though
-:class:`~iqm.pulse.quantum_ops.QuantumOp` is a frozen data class, the implementations dictionary can be modified, e.g.
-to add new implementations or to change their order (usually programmatically by some client procedure, but nothing as
+:class:`.GateImplementation` subclass. A QuantumOp stores its known implementations in
+:attr:`.QuantumOp.implementations`. Note that even though
+:class:`.QuantumOp` is a frozen data class, the implementations dictionary can be modified, e.g.
+to add new implementations (usually programmatically by some client procedure, but nothing as
 such prevents the user from manipulating the contents manually). The default implementation is how the user prefers
 to implement the operation unless otherwise specified (in effect, this is what will get called in most cases the
 operation is invoked). In the implementations dict, the default implementation is defined as the first entry.
@@ -35,17 +35,17 @@ QuantumOp contains helpful methods that allow setting and returning the default
 :meth:`~iqm.pulse.quantum_ops.QuantumOp.get_default_implementation_for_locus`, and
 :meth:`~iqm.pulse.quantum_ops.QuantumOp.set_default_implementation_for_locus`.
 
-The attribute :attr:`~iqm.pulse.quantum_ops.QuantumOp.unitary` stores a function that can be used to get the unitary
+The attribute :attr:`.QuantumOp.unitary` stores a function that can be used to get the unitary
 matrix representing the quantum operation in question. The unitary function must have the same arguments
-as defined in :attr:`~iqm.pulse.quantum_ops.QuantumOp.params`, such that for each collection of these parameters it
-gives the associated unitary matrix. Note that not all QuantumOps necessarily even represent a unitary gate (e.g.
-the measure operation is not one), or the exact form of the unitary matrix might not be known. In these cases, the
-field can be left ``None``. The unitary does not need to be defined for most of the basic usage of a QuantumOp, but certain
+as defined in :attr:`.QuantumOp.params`, such that for each set of values for these parameters it
+gives the associated unitary matrix. Note that not all QuantumOps represent a unitary gate (e.g.
+the ``measure`` operation is not one), or the exact form of the unitary matrix might not be known. In these cases, the
+field can be left to ``None``. The unitary does not need to be defined for most of the basic usage of a QuantumOp, but certain
 algorithmic methods (e.g. some implementations of Randomized Benchmarking) may require the unitary matrices to be known,
-and such operations that do not define the getter function cannot then be used in these contexts.
+and operations that do not define :attr:`.QuantumOp.unitary` cannot be used in these contexts.
 
-For more information, see the API docs of :class:`~iqm.pulse.quantum_ops.QuantumOp` for the full list of fields needed
-to define a quantum operation and the available class methods.
+For more information, see the API docs of :class:`.QuantumOp` for the full list of attributes needed
+to define a quantum operation, and the available methods.
 
 Custom gate implementations
 ---------------------------
@@ -56,7 +56,7 @@ GateImplementation class
 While :class:`~iqm.pulse.quantum_ops.QuantumOp` represents an abstract quantum operation, its *implementations*  contain
 the concrete logic of how to make that operation happen using QC hardware. Gate implementations are subclasses of
 :class:`~iqm.pulse.gate_implementation.GateImplementation`. In this section, the main features of that class are
-introduced (for a full list of class methods see the API docs), with the emphasis being on how to create your own
+introduced (for a full list of methods see the API docs), with the emphasis being on how to create your own
 gate implementations.
 
 Starting with :meth:`~iqm.pulse.gate_implementation.GateImplementation.__init__`, it is important to note that the init
@@ -73,22 +73,23 @@ methods of all gate implementations must have the exact same signature:
         builder: ScheduleBuilder
     ):
 
-Here, ``parent`` is the ``QuantumOp`` this gate implementation implements, and ``name`` is the implementation's name in
+Here, ``parent`` is the :class:`.QuantumOp` this gate implementation implements, and ``name`` is the implementation's name in
 the dictionary :attr:`~iqm.pulse.quantum_ops.QuantumOp.implementations`. ``locus`` is the set of (usually logical) components
 the QuantumOp acts on (the size of the locus must be consistent with the ``parent``'s
 :attr:`~iqm.pulse.quantum_ops.QuantumOp.arity`), while ``calibration_data`` gives the required calibration data values
 for this implementation and ``locus`` (can be empty in case the implementation needs no calibration data). Finally,
-The implementations store a reference to the :class:`~iqm.pulse.builder.ScheduleBuilder` that created it. This is
+the implementations store a reference to the :class:`~iqm.pulse.builder.ScheduleBuilder` that created it. This is
 because GateImplementations are practically never created manually by calling the init method itself. Instead, one
 needs a builder and uses :meth:`~iqm.pulse.builder.ScheduleBuilder.get_implementation`.
 
-The responsibility of the init method is to (at least) store the ``calibration_data`` provided from the builder for
-further use, but in many cases, one might want to create some intermediate objects like pulses or instructions **from**
-that calibration data already at this point. Note that ScheduleBuilder caches its GateImplementations per each locus and
-``calibration_data``, so as long as the calibration is not changed, the code in init will be called just once per locus.
+The responsibility of the init method is to initialize the superclass, but in many cases one might want to create
+and cache some intermediate objects like waveforms or instructions **from**
+that calibration data already at this point. Note that ScheduleBuilder caches the GateImplementation instances it
+creates for each (quantum op, implementation, locus) triplet,
+so as long as the calibration is not changed, the code in init will be called just once for each such triplet.
 
-GateImplementations are Callables, i.e. they implement the `__call__` method. It should take as its arguments at least
-the QuantumOpt parameters defined for the ``parent`` in :attr:`~iqm.pulse.quantum_ops.QuantumOp.params`, but in
+GateImplementations are Callables, i.e. they implement the :meth:`__call__` method. It should take as its arguments at least
+the ``parent`` QuantumOp parameters defined in :attr:`~.QuantumOp.params`, but in
 addition it may have optional extra arguments. The call method should return a :class:`~iqm.pulse.timebox.TimeBox` object
 that contains the pulses, instructions and other logic required to implement the quantum operation in question. The
 typical usage of gate implementations then looks like this (See :doc:`using_builder` and :doc:`pulse_timing` for more
@@ -105,13 +106,13 @@ info on scheduling and the ScheduleBuilder):
     default_box = default_prx_QB1(angle=np.pi, phase=np.pi/2)
 
     # the initialization of the impl class and the call can of course be also chained together like this:
-    default_cz_box =  builder..get_implementation("cz", ("QB1", "QB2"))()  # CZ has no QuantumOp params!
+    default_cz_box =  builder.get_implementation("cz", ("QB1", "QB2"))()  # CZ has no params
 
-The base class :meth:`~iqm.pulse.gate_implementation.GateImplementation.__call__` method does automatic TimeBox caching based
+The base class :meth:`__call__` method does automatic TimeBox caching based
 on the unique values of the call arguments, and in many cases, one does not want to reimplement this caching in their own
-implementations. For this reason, there is the method ``_call`` which contains just the pure TimeBox creation logic.
-Developers can choose to override that instead of ``__call__`` in cases where the call args are hashable python types,
-and then they can utilize the default caching of TimeBoxes from the base class.
+implementations. For this reason, there is the method :meth:`~.GateImplementation._call` which contains just the pure TimeBox creation logic.
+Developers should override that instead of :meth:`__call__` in cases where the call args are hashable Python types,
+so they can utilize the caching of TimeBoxes from the base class.
 
 When writing a GateImplementation, a developer should consider what parts of the logic should go to the class init and
 what to the ``__call__`` or ``_call`` method. A general rule of thumb would be that any parts that can be precomputed
@@ -138,18 +139,18 @@ use this exact call method, as this is a simplified example for educational purp
         )
 
 Here, we first create an :class:`.IQPulse` object which is a low-level Instruction. IQPulse
-means a "complex pulse" which has two orthogonal components i and q -- this what drive pulses look like in general. In
+means a "complex pulse" which has two orthogonal components I and Q --- this what drive pulses look like in general. In
 this simplified example, we have hardcoded the pulse waveforms into :class:`.TruncatedGaussian` and
-:class:`.TruncatedGaussianDerivative` for the i and q components, respectively (this is a DRAG implementation, so the
-q component is the derivative of the i component). The waveforms are parametrized by the ``calibration_data`` for the
-given ``locus`` (see the next subsection for more info on Waveforms and calibration data). The PRX QuantumOp param
-``angle`` scales the pulse amplitude linearly (the waveforms are normalized to one), and the param ``phase`` defines relative
+:class:`.TruncatedGaussianDerivative` for the I and Q components, respectively (this is a DRAG implementation, so the
+Q component is the scaled derivative of the I component). The waveforms are parametrized by the ``calibration_data`` for the
+given ``locus`` (see the next subsection for more info on Waveforms and calibration data). The PRX parameter
+``angle`` scales the pulse amplitude linearly (the waveforms are normalized to one), and the parameter ``phase`` defines relative
 phase modulation. Then the returned TimeBox is created out of the ``instruction``. Note that
 since we override ``_call`` here, instead of ``__call__``, so this implementation would utilize the default base class
-caching such that the TimeBoxes are cached per unique values of ``(angle, phase)``.
+caching such that the TimeBoxes are cached for unique values of ``(angle, phase)``.
 
 Another important concept is a the so called locus mapping of a gate implementation. Locus mappings define on which
-loci, i.e. groups of components, a given implementation can be defined. They are used to relay the information which
+loci, i.e. groups of components, a given implementation can act. They are used to relay the information which
 loci are supported to a client application (e.g. EXA). In addition, the gate implementation itself can programmatically
 use this information ``self.builder.chip_topology``.
 
@@ -177,10 +178,10 @@ Instructions, Waveforms and calibration data
 In order to implement most QuantumOps, one has to physically alter the state of the QPU. This is typically done by playing
 specified and correctly calibrated pulses via the control electronics (this applies to all typical logical gates such as
 e.g. PRX or CZ -- non-physcial metaoperations such as Barrier are an exception). In defining these pulses, there are two
-levels of abstractions: :class:`.Waveform` and :class:`.Instruction`.
+levels of abstractions: :class:`~iqm.models.playlist.waveforms.Waveform` and :class:`.Instruction`.
 
-Waveform represents the physical form of the control pulse, typically normalized to the interval ``[-1.0, 1.0]``. The
-Each :class:`~iqm.models.playlist.waveforms.Waveform` subclass can define any number of waveform parameters as class
+Waveform represents the physical form of the control pulse, typically normalized to the interval ``[-1.0, 1.0]``.
+Each Waveform subclass can define any number of parameters as class
 attributes, which can be used to programmatically define the waveform. For example, a Gaussian could be defined in terms
 of the average ``mu`` and spread ``sigma``. A Waveform class then essentially contains just the parameters
 and a recipe for computing the samples as an ``np.ndarray``. As an example, here is how one writes the Waveform class
@@ -201,10 +202,10 @@ for ``Gaussian``:
 The Instructions :class:`.RealPulse` and
 :class:`.IQPulse` allow handling the amplitudes (via the attribute ``scale``) without
 having to resample the waveform for every different amplitude value. However, one can always choose to include
-the amplitude into the sampling and then use ``scale=1``.
+the amplitude into the sampling and use ``scale=1``.
 
 The waveform parameters (like ``sigma`` in the above Gaussian) typically require calibration when the Waveform is used
-in a quantum gate. However, the GateImplementation usually has other calibrated parameters as well defined in the
+in a quantum gate. The GateImplementation usually also has other calibrated parameters as well defined in the
 implementation itself. As an example, here are the implementation-level parameters of the default PRX implementation,
 defined as class attribute:
 
@@ -243,26 +244,23 @@ To make creating new GateImplementations more comfortable, there are additional
 
 :class:`.CompositeGate` allows quick implementation of gates in terms of other gates,
 using a similar syntax as with creating/scheduling several TimeBoxes together (see :doc:`using_builder`). At it
-simplest, a ComposteGate is just the `_call` method:
+simplest, a CompositeGate is just the :meth:`~.GateImplementation._call` method:
 
 .. code-block:: python
 
     class CompositeHadamard(CompositeGate):
         """Composite Hadamard that uses PRX"""
-        registered_gates = ["prx"]
-        # registering member gates is not mandatory, but allows calibrating them specifically inside _this_ composite
+        registered_gates = ("prx",)
 
         def _call(self) -> TimeBox:
             member_prx = self.build("prx", self.locus)
             return member_prx(np.pi / 2, np.pi / 2 ) + member_prx(np.pi, 0.0)
 
-Here, one could use also ``builder.get_implementation`` instead of
-:meth:`~iqm.pulse.gate_implementation.CompositeGate.build`, but the latter allows calibrating the member gates
-case specifically for this composite if they are first registered via
-:attr:`~iqm.pulse.gate_implementation.CompositeGate.registered_gates` (in this case, there is
-just one member, PRX).
+The :meth:`.CompositeGate.build` method is used to access the member gate implementations.
+It allows providing a special calibration for the member gates just for this composite gate.
+In this example there is just one member, ``prx``.
 
-Creating new implementations for the PRX, CZ and Measure gates often means just coming up with new waveforms for the
+Creating new implementations for the ``prx``, ``cz`` and ``measure`` gates often means just coming up with new waveforms for the
 control pulses. If this is the case, there are helpful base classes that make those implementations into oneliners
 (outside of defining the Waveforms themselves): :class:`~iqm.pulse.gates.prx.PRX_CustomWaveforms`,
 :class:`~iqm.pulse.gates.cz.FluxPulseGate`, and :class:`~iqm.pulse.gates.measure.Measure_CustomWaveforms`. Using these
@@ -280,21 +278,21 @@ base classes at its simplest looks like this:
         """Measure with my cool custom waveforms for the i and q probe pulse components"""
 
 All of these classes automatically include the associated Waveform parameters into the calibration parameters of
-the implementation itself. There is also a general base class for any gate that implements a single ``IQPulse``
-(both PRX_CustomWaveForms and Measure_MyCoolWaveforms actually inherit from it), regardless of the context:
-:class:`~iqm.pulse.gate_implementation.CustomIQWaveforms`.
+the implementation itself. There is also a general base class :class:`~iqm.pulse.gate_implementation.CustomIQWaveforms`.
+for any gate whose implementation consists of a single IQPulse
+(both :class:`.PRX_CustomWaveforms` and :class:`.Measure_CustomWaveforms` actually inherit from it).
 
 
 Registering gates and implementations
 -------------------------------------
 
-Gate definitions (i.e. QuantumOps) are stored in :class:`~iqm.pulse.builder.ScheduleBuilder`'s attribute
-``op_table``. When the builder is created, the ``op_table`` comes preloaded with the all the basic QuantumOps needed for
-typical circuit execution and their default implementations. These include e.g. the PRX gate, the CZ gate, the measure
-operation, the conditional prx operation, the reset operation, and the barrier operation.
+Gate definitions (i.e. QuantumOps) are stored in :attr:`.ScheduleBuilder.op_table`.
+When the builder is created, the ``op_table`` comes preloaded with the all the basic QuantumOps needed for
+typical circuit execution and their default implementations. These include e.g. the ``prx`` gate, the ``cz`` gate, the ``measure``
+operation, the conditional PRX operation ``cc_prx``, the ``reset`` operation, and the ``barrier`` operation.
 
-In order to add custom operations, there is a helpful function :func:`~iqm.pulse.gates.register_implementation` that
-in addition to adding new implementations allows one to add altogether new quantum operations.
+New quantum operations can be registered using :func:`~iqm.pulse.gates.register_operation`.
+For adding implementations to the operations, there is :func:`~iqm.pulse.gates.register_implementation`.
 
 As an example here is a snippet that adds the CNOT gate, and its implementation, into an existing builder:
 
@@ -306,19 +304,25 @@ As an example here is a snippet that adds the CNOT gate, and its implementation,
                             [0, 0, 1, 0]], dtype=complex)
     cnot_op = QuantumOp(name="cnot", arity=2, symmetric=False, unitary=lambda: cnot_matrix)
 
+    register_operation(
+        operations=my_builder.op_table,
+        op=cnot_op,
+    )
     register_implementation(
         operations=my_builder.op_table,
-        gate_name="cnot",
+        op_name="cnot"
         impl_name="my_cnot_impl",
         impl_class=MyCNotClass,
-        quantum_op_specs=cnot_op
     )
 
-Here, the CNOT implementation ``MyCNotClass`` needs to be of course defined first (a QuantumOp always needs at least one
+Here, the CNOT implementation ``MyCNotClass`` needs to be defined first (a QuantumOp always needs at least one
 implementation).
 
-**Note:** The end user cannot modify the canonical mapping (defined in iqm-pulse) between ``implementation_name`` and 
-``implementation_class``.
+.. note::
+
+   Certain implementation names are *canonical* for certain operations. This means they always map to the same iqm-pulse
+   GateImplementation class, and the user cannot modify this mapping, defined in
+   :attr:`iqm.pulse.gates.default_gates._default_implementations`.
 
 Note that often :class:`.ScheduleBuilder` is created and operated by some client application, and the same application usually
 has its own interface for adding/manipulating QuantumOps. However, if the user has access to the builder object, the

{iqm_pulse-9.20.0 → iqm_pulse-10.0.0}/docs/pulse_timing.rst

@@ -6,19 +6,19 @@ Measure and ReadoutTrigger
 
 The :class:`~iqm.pulse.playlist.instructions.ReadoutTrigger` Instruction responsible of qubit readout has several
 timing-related attributes.
-The ``measure.constant`` gate implementation produces the lower-level ReadoutTrigger instruction
-from a simplified set of settings.
-The figure below shows how the settings relate to the more flexible attributes of the instruction.
+The ``measure.constant`` gate implementation produces a ReadoutTrigger instruction
+from a simplified set of parameters.
+The figure below shows how these parameters relate to the more flexible attributes of the instruction.
 
 .. image:: /_static/images/readout_timing.svg
 
 Fast feedback timing
 --------------------
 
-With conditional Instructions, we specify how the information from readout operations should affect Instructions at
-runtime.
+With conditional instructions, we can specify how the output from readout operations should affect
+other instructions in the same Segment.
 Usually, the goal is use the information as soon as possible, but it takes a finite time to propagate from the
-acquisition unit to the drive channels that execute the Instructions conditionally.
+acquisition unit to the AWG that execute the Instructions conditionally.
 
 .. note::
 
@@ -31,7 +31,7 @@ To facilitate efficient timing of the feedback signals, IQM Pulse uses virtual c
 (the source of the signals) and drive channels (the destinations).
 Block instructions on the virtual channel represent the travel time of the signals.
 
-:class:`.CCPRX_Composite` is GateImplementation of the ``cc_prx`` (classically controlled PRX) that outputs two
+:class:`.CCPRX_Composite` is a GateImplementation of the ``cc_prx`` (classically controlled PRX) gate that outputs two
 TimeBoxes:
 the first one to represent the travel time, and the second one with the actual :class:`.ConditionalInstruction`.
 In typical use, both should be scheduled in the same order, to ensure the Conditionalinstrucion starts when the
@@ -62,7 +62,7 @@ The equaivalent code would be
 
 
 Instructions are spaced out in time only for visual clarity. When scheduled ASAP, they would be left-aligned
-such that the ConditionalInstructions start right after the associated `control_delay` has passed.
+such that the ConditionalInstructions start right after the associated ``control_delay`` has passed.
 
 The bottom of the image illustrates an alternative use of ``CCPRX_Composite`` to have more freedom in the timing.
 There, the optional delay TimeBox is not used for scheduling the Instructions on QB4.
@@ -85,7 +85,7 @@ complex number or a bit, corresponding to a particular qubit in a particular seg
 In the figure, one of the AWGs has been selected as the trigger master, which means it sends trigger pulses to
 start the execution on the slave devices.
 As shown in the picture, different delays caused by the travel time of signals can be compensated for by
-adjusting the `trigger_delay` setting of each device.
+adjusting the ``trigger_delay`` setting of each device.
 
 
 .. image:: /_static/images/pulse_timing.svg
@@ -120,4 +120,4 @@ Other notes:
 * Pipeline delays are delays between the execution of a command and the pulse actually getting outputted
   from a device. This delay is caused by the hardware and cannot be changed.
   In practice, it can be thought as being part of the cable delays, and thus can be compensated with
-  ``trigger_delay`` setting.
+  the ``trigger_delay`` setting.