This is difficult to test without hardware mocks or some
form of phase readback, but the symptom was that e.g.
`self.dds.set(…, ref_time=now_mu() - 1)` would fail
periodically, that is, whenever bit 32 of the timestamp
would be set (which would be turned into the sign bit).
This is a fairly sinister issue, and is probably a compiler
bug of some sort (either accepts-invalid or wrong type inference).
* tune_sync_delay: the opposite IO_UPDATE to SYNC_CLK alignment may not be perfectly
mis-aligned
* set_mu_speed: seems to be slower on the buildbot
Signed-off-by: Robert Jördens <rj@quartiq.de>
Previously the TSC was truncated to an even coarse RTIO periods before doing
the setting SPI xfer. Afterwards the the IO update pulse would introduce
at least one but less than two RTIO cycles. Ultimately the RTIO TSC was
truncated again to even. If the SPI xfer takes an odd number of RTIO
periods, then a subsequent xfer would collide.
close#1229
Signed-off-by: Robert Jördens <rj@quartiq.de>
This allows the migen namer to derive names for the ADC return clock
domain in the case of multiple SUServos
close#1201
Signed-off-by: Robert Jördens <rj@quartiq.de>
* parametrized by center/span/step instead of
start/stop/npoints which is more convenient in some applications
* no scan widget support so far
Signed-off-by: Robert Jördens <rj@quartiq.de>
Before this commit, the main loop in session code was laid like:
1. process_kern_queued_rpc
2. process_host_message
3. process_kern_message
If a host message (such as an RPC reply) caused the kernel to exit,
then any async RPCs would not complete, since RunFinished immediately
shuts down the kernel.
Fix this by reordering 1 and 2.
This now reliably locates the SYNC_CLK-IO_UPDATE edge by doing two
scans at different delays between start and stop IO_UPDATE.
It also works well when one delay is very close to the edge.
And it correctly identifies which (start or stop) pulse hit or crossed
the SYNC_CLK edge.
for #1143
Signed-off-by: Robert Jördens <rj@quartiq.de>
