Urukul FTW and attenuator update rate

[cjbe]

I am surprised at how long it takes to update the attenuator and FTW on Urukul. Using an AD9910 Urukul on Kasli, and running an underflow test experiment (https://hastebin.com/qonukomaku.py), I find that the following brackets in mu (here 1mu=1ns):

freq update: 46875 46878
freq update mu: 8286 8289
att update: 35152 35156
att update mu: 1998 2001

So it takes ~50us to update the FTW if it is provided as a float, or 8us if it is provided in mu. Similarly 35us / 2us to update the attenuator using a float / mu value.

1. I would expect the compiler to optimise the float cases into the mu cases, as everything is known at compile time.
2. I am surprised that the frequency update takes ~8us even when the FTW is provided in mu, as the SPI transaction itself only takes ~1.1us - is there any way to speed this up?

[jordens]

Yes. The compiler sometimes does not fold constants for reasons I don't understand either.
Yes. Raw 64 bit RTIO events tend to be around the 6-10µs mark. Same as the old DDS bus.

#535 #636 #661 #667 and maybe #624

[whitequark]

The compiler sometimes does not fold constants for reasons I don't understand either.

LLVM's IR is not powerful enough to express all invariants that we have, thus sometimes it does not recognize that it can hoist instructions out of loops. This is #655. There is a proper solution (adding metadata on GEP, as described in the linked review.llvm.org page) but it's not trivial.

[jordens]

You could also shave off one rtio_output(), i.e. one event, by not updating the spi config each time between two writes to the attenuators or the same DDS. But you'd do that in a separate API.

[jordens]

No new issue here.