jbroz seems to work if you do not disable the RAM when writing the waveform to another chip/channel. This allows for the setting of independent frequency modulated signals to the different chips.

It says in the manual however that it is strongly recommended that RAM_enable = 0 when performing load/retrieve operations - do you believe writing to the RAM whilst it is still enabled would cause any damage.

    Ahh, that makes sense. I think the warning in the manual doesn't apply since the load/retrieve operations are just being performed on a single DDS (even though we've switched the profile setting on all of them). But I could be wrong.

    a month later

    No additional interest or development that I know of.

      airwoodix Thanks for the information.
      rjo Exposure of the DRG api would simplify the programming significantly in some frequency sweep tasks. Is there any advice on what I can do since I really need the function?

          As always: fund the development and talk to people that can implement it or if you feel up to it, do it yourself.

            han94ros Thanks for the advice. In fact, I've implemented a workable solution with DMA. But I still think that being able to get direct access to DRG would enable us to tackle the problem in a more elegant way.

              a year later

              airwoodix
              I tried your method and the DDS frequency was stuck in the lower limit for >250 us.

              I am not sure how to control/eliminate the time gap (where its stuck at lower limit). Couldn't find anything relevant in the datasheet. Alternatively I have fixed the DRCTL pins to high in the CPLD, and just use the increment fields instead. This is what I got by combining the DRG (frequency) and RAM (amplitude).

              Amplitude and frequency changes simultaneously at a defined interval.

              Are there any interest for this CPLD patch?
              Nvm, just enable load LRR @ I/O Update in CFR1. See the DRG usage in ARTIQ.