now_mu() affects Urukul AD9910's output #1702
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Bug Report
makes Urukul AD9910 output this:
makes Urukul AD9910 output this:
By the way:
self.urukul0_ch0.tune_io_update_delay()andprint(self.urukul0_ch0.sync_data.io_update_delay)both return0.Expected Behavior
Calling
now_mu()does not affect AD9910 output under any circumstances.Actual (undesired) Behavior
AD9910 output is clearly affected by call to
now_mu().Background info
delay_mu(1)makes a huge difference.My System
Experiment code that reproduces the bug
Trigger your oscilloscope on falling edge of
self.ttl0and set normal trigger mode and time span 100 ns.Why do you say that "AD9910 output is clearly affected by call to now_mu()"? From the short description, what seems to be going on is that shifting the IO_UPDATE edge by 1 ns has an effect (the delay being either taken into account in the calculation or not). This is completely expected, as for deterministic phase control, the IO_UPDATE pulse must be aligned with respect to the 250 MHz internal DDS logic clock (assuming you are running with 1 GHz SYSCLK).
io_update_delay(0, 1, 2 or 3) specifies the alignment with the 4 ns grid, i.e. it is not related to the an output delay of any kind, but specifies one of the four possible grids w.r.t. the 1 ns timeline resolution that is sure to meet the setup/hold requirements on the DDS end.@dnadlinger Thank you, you are absolutely right. It was late and I wasn't reasoning clearly.
Incidentally, do you know a good way to align io_update to the SYNC_CLK grid?
self.urukul0_ch0.tune_io_update_delay()andprint(self.urukul0_ch0.sync_data.io_update_delay)both return 0, so I would expect everything to be fine, but then I observe a dependence of the optimal alignment delay on the frequency tuning word, see my latest answer to "AD9910: Mirror frequencies invert sign of phase accumulation".tune_io_update_delay()is I think Robert Jördens's innovation when he integrated the multi-chip sync/phase calculations properly into upstream ARTIQ. We originally just mapped the four possible values manually when bringing up phase-coherent operation in Oxford, but I don't think I've ever seen the auto-tuning implementation fail. (If memory serves, it even uses the DRG to figure out the correct alignment, so one would hope it would definitely yield the correct result for your use case?)