ccv Can you clarify the need for 650*ns delays? My understanding is that updates can be sent every 40ns on phaser. It could also be helpful to see your implementation in code, as well as which kasli version you're using?
Is this an RTIOUnderflow/slack issue? If so, you could try recording onto DMA.
If it's an issue with saturating the SED's FIFOs, you could try:
If it's an issue with the sustained event rate (for kasli v2.0 only; my understanding is that kasli-soc's event rate is already pretty up there):
- disabling the coreanalyzer - seems like sb10q found ~ 650mu (similar to your case) sustained DMA event rate with analyzer on, which dropped to ~ 210mu with analyzer off (see https://github.com/m-labs/artiq/issues/946) - will require a very minor mod to the artiq gateware and reflashing your kasli
- you could also try merging this commit by occheung which brings the sustained DMA event rate to ~ 65mu (https://github.com/m-labs/artiq/pull/2592); i believe it's currently for the artiq-9 release though, so you'll have to merge it manually
However, I think a better solution might be to use the AD9910 DDS on urukul here - have you looked into the digital ramp generator (DRG) on the AD9910?
- you can set freq update intervals in multiples of 4ns (i.e. 4*t_SYSCLK, which is typically 1ns)
- you can set freq step sizes down to single bits (i.e. update ftw by 0b1 each step, which is <1 Hz)
If you need a nonlinear ramp, you can also use the AD9910's RAM mode, which works similarly to the DRG, but allows specification of only 1024 values.