I will be setting up a new Phaser board over the next few days and subsequently write a driver for multi-tone rf generation in our experiments. I would therefore like to get an understanding of the subtleties involved in setting rf parameters for different phaser oscillators. The docstrings clearly state that latencies between oscillators within a channel and between oscillator parameters are deterministic (with respect to the 25 MS/s sample clock) but not matched. There is not much information, however, on whether and how the unmatched latencies affect the use of phaser for the generation of pulses that should have definite frequency and phase when they turn on.

Question 1:
For the following code
at_mu(phaser.get_next_frame_mu())
phaser.channel[0].oscillator[0].set_frequency(xxx)
phaser.channel[0].oscillator[0].set_amplitude_phase(xxx)
can I expect the frequency and amplitude/phase settings to become active for the same sample or is it possible that latencies are such that one becomes active for a later sample than the other? Could this be dependent on which oscillator is used (so that they would become active for the same sample if osc0 is set, but different samples if osc4 is instead used in the code above)?

Question 2:
Assume that an rtio event is submitted to change the FTW of osc0 with a timestamp that happens to lie in the middle of the cycle of incrementing NCOs, say when the phase accumulator of osc2 is about to be incremented. Is updating FTWs (or amplitude,...) independent of incrementing phase accumulators or can the FTW only be updated when the corresponding phase accumulator is about to be addressed? In other words, will the FTW of osc0 be updated at the next rtio cycle (not touching the corresponding phase accumulator yet) or only at the next sample cycle? Depending on which behaviour applies, I think the sample at which the FTW becomes active might be different.

Question 3:
Is there an inherent difference between aligning to a frame or to a sample, apart from the factor of 8 in time? I believe only the former is explicitly provided as a method.

    For context: as I understand it, there are conceptually three inputs to the initial kasli DSP core per Phaser output channel: the rtio clock (125 MHz assumed), one rtio channel shared between the 5 oscillators to set frequencies and one shared rtio channel to set amplitudes/phases. Starting with oscillator (osc) 0, the phase accumulator of the corresponding NCO is incremented at one rtio clock cycle, then osc1 at the next rtio clock cycle..., which means that the whole collection of phase accumulators is incremented at a rate of 125e6/5 = 25e6 repeats per second. After all phase accumulators have been updated, the output from the NCOs is summed and this represents one 14-bit sample (sample rate 25 MS/s) output from the kasli DSP. 8 samples are combined into one frame and streamed over to Phaser.

    For the purpose of these questions, I call the start of a sample the point just before the phase accumulator of osc0 is touched.

    clos
    can I expect the frequency and amplitude/phase settings to become active for the same sample
    or is it possible that latencies are such that one becomes active for a later sample than the other? Could this be dependent on which oscillator is used (so that they would become active for the same sample if osc0 is set, but different samples if osc4 is instead used in the code above)?

    https://m-labs.hk/artiq/manual-beta/core_drivers_reference.html#artiq.coredevice.phaser.PhaserOscillator

    Latencies between oscillators within a channel and between oscillator parameters (amplitude and phase/frequency) are deterministic (with respect to the 25 MS/s sample clock) but not matched.

    Question 2:
    Assume that an rtio event is submitted to change the FTW of osc0 with a timestamp that happens to lie in the middle of the cycle of incrementing NCOs, say when the phase accumulator of osc2 is about to be incremented. Is updating FTWs (or amplitude,...) independent of incrementing phase accumulators or can the FTW only be updated when the corresponding phase accumulator is about to be addressed? In other words, will the FTW of osc0 be updated at the next rtio cycle (not touching the corresponding phase accumulator yet) or only at the next sample cycle? Depending on which behaviour applies, I think the sample at which the FTW becomes active might be different.

    Latencies between oscillators are not matched.
    Same as above.

    Question 3:
    Is there an inherent difference between aligning to a frame or to a sample, apart from the factor of 8 in time? I believe only the former is explicitly provided as a method.

    Since a frame is an integer number of samples, aligning to a frame is sufficient but not necessary to achieve deterministic latency. Aligning to the sample period is what counts.

      I am aware that latencies are deterministic, but not matched, which is why I have stated that at the start of my original question. What I am wondering is what differential latency can be expected (for example, between setting frequency and amplitude/phase).
      Taking the example I posted

      clos For the following code
      at_mu(phaser.get_next_frame_mu())
      phaser.channel[0].oscillator[0].set_frequency(xxx)
      phaser.channel[0].oscillator[0].set_amplitude_phase(xxx)

      there will be some finite latency between calling set_frequency and the update actually affecting the calculation in the corresponding phase accumulator (so new FTW will become active for some later sample). If the latency for set_amplitude_phase is not matched, I guess the POW might become active for a different sample. However, whether that is the case would depend on what the differential latency (in rtio clock cycles) is compared to the sample length of 5 clock cycles. Or are my assumptions wrong here?

        Yes. Either measure them in hardware, write a simulation harness for the gateware, or check on paper whether my numbers in that issue are correct.
        The oscillators are then just staggered by one cycle.
        You could also ask @pathfinder49 whether he or anyone else by now has confirmed/measured them.