On 10/30/2014 03:29 AM, Slichter, Daniel H. wrote: > 1. If a DDS frequency needs to be changed, how long would it > take to load the required data for reprogramming into the output > queue of the RTIO core? Let’s assume we need to change freq, phase, > and amplitude – thus 64 bits sent over an 8 bit parallel bus to the > DDS boards – and that the values are pre-calculated on the computer > rather than being calculated on the fly by the SoC.
The DDS reprogramming routine is as follows: 1. wait for all previous RF switch commands to be completed 2. wait for any previous FUD pulse to be completed 3. load the data into the DDS registers 4. determine the FUD timing: a. if FUD is not required to be real-time (because the RF switch is currently off), take the current RTIO counter value + 4000 cycles b. if real-time FUD is required (because the RF switch is on and we are changing the frequency on-the-fly), use the "now" value 5. later we will probably want to adjust that FUD timing depending on the SYNC_CLK phase 6. program the FUD pulse and the RF switch command(s) into the RTIO I guesstimate the whole routine would take a couple microseconds. Steps 1-5 are automatically removed by the compiler when it determines that the frequency is the same as previously programmed, in which case it boils down to the regular RTIO pulse case. Amplitude and phase control are not currently implemented. Amplitude control sounds straightforward; for the phase control, I'm not sure about your exact needs. Should the driver give basic access to the phase control word (with some conversion for experiment code portability, e.g. the phase would be specified in turns or in radians by the user) or should there be some phase tracking algorithm built into the driver? Sébastien _______________________________________________ ARTIQ mailing list https://ssl.serverraum.org/lists/listinfo/artiq
