- On Urukul, the AD9910 are connected via a serial interface to the on-board CPLD. A call to
AD9910.set() needs to write a 64-bits register (the requested single tone profile register) and pulse
IO_UPDATE. A register operation on AD9910 is always preceded by an instruction byte, so there are actually 72 bits to write (more if not operating in continuous phase mode, see
AD9910.set_mu). For writes, the serial clock ticks at 125 MHz/2, so the serial transfer takes roughly 1.15 µs followed by a ca. 60 ns wide
IO_UPDATE pulse. Hence the delay you observe. One can go faster, at the price of flexibility (probably not exhaustive):
A) If you want to switch between discrete, predefined, frequencies (maximum 8), the fastest is probably to use different profiles:
self.dds.set(5*MHz, profile=0) # outputs 5 MHz
self.dds.set(30*MHz, profile=1) # configure profile 1
self.dds.cpld.set_profile(1) # actually switch to profile 1, output = 30 MHz
A change of profile corresponds to a write of the Urukul CPLD configuration register (24 bits) so takes roughly 400 ns. Ad-hoc changes to the Urukul CPLD gateware could expose direct access to (some of) the profile pins (e.g. instead of the switches) to circumvent the CFG register write.
B) The AD9910 FTW is only 32 bits wide, so this (+ an
IO_UPDATE pulse) should be sufficient to just change frequency. Table 5 page 21 of the datasheet indicates that the FTW register (@0x07) is used in RAM mode when the destination is amplitude or phase (or both). So you could misuse the RAM for example like this:
from artiq.coredevice.ad9910 import RAM_DEST_ASF
data = [self.dds.amplitude_to_asf(1.) << 18] # full-scale amplitude
self.dds.set_profile_ram(start=0, end=0) # RAM profile 0, one value
self.dds.cpld.io_update.pulse_mu(8) # "commit"
# an example frequency change
The frequency change is now a (8+32)-bits write and an
IO_UPDATE pulse, that is roughly 700 ns.
Isn't this probe capacitance you're seeing? HMC349ALP4CE on/off time is expected around 150 ns.
This is expected and addressed by the
IO_UPDATE delay tuning routines in
AD9910. See #1143, in particular the example codes. You'd need to adapt the examples from point 1. to get absolute phase tracking (delay the
IO_UPDATE pulse by
This doesn't seem to be normal. Which board revision are you using? Is this stock CPLD gateware? Can you systematically reproduce the issue with a very minimal piece of code?