RELEASE_NOTES: TTL timeline cursor API changes

This commit is contained in:
David Nadlinger 2018-10-26 16:54:46 +01:00 committed by Sébastien Bourdeauducq
parent f79b9d9e1e
commit 8b5df9c151
1 changed files with 26 additions and 0 deletions

View File

@ -9,6 +9,32 @@ ARTIQ-4
4.0 4.0
*** ***
* The ``artiq.coredevice.ttl`` drivers no longer track the timestamps of
submitted events in software, requiring the user to explicitly specify the
timeout for ``count()``/``timestamp_mu()``. Support for ``sync()`` has been dropped.
Now that RTIO has gained DMA support, there is no longer a reliable way for
the kernel CPU to track the individual events submitted on any one channel.
Requiring the timeouts to be specified explicitly ensures consistent API
behavior. To make this more convenient, the ``TTLInOut.gate_*()`` functions
now return the cursor position at the end of the gate, e.g.::
ttl_input.count(ttl_input.gate_rising(100 * us))
In most situations that is, unless the timeline cursor is rewound after the
respective ``gate_*()`` call simply passing ``now_mu()`` is also a valid
upgrade path::
ttl_input.count(now_mu())
The latter might use up more timeline slack than necessary, though.
In place of ``TTL(In)Out.sync``, the new ``Core.wait_until_mu()`` method can
be used, which blocks execution until the hardware RTIO cursor reaches the
given timestamp::
ttl_output.pulse(10 * us)
self.core.wait_until_mu(now_mu())
* RTIO outputs use a new architecture called Scalable Event Dispatcher (SED), * RTIO outputs use a new architecture called Scalable Event Dispatcher (SED),
which allows building systems with large number of RTIO channels more which allows building systems with large number of RTIO channels more
efficiently. efficiently.