08:05 <mtrbot-ml> [mattermost] <hartytp> Ok makes sense

13:25 <mtrbot-ml> [mattermost] <hartytp> @sb10q does Sayma SAWG master work atm or are you only supporting Sayma as a satellite?

14:09 <mtrbot-ml> [mattermost] <sb10q> only satellite

14:09 <mtrbot-ml> [mattermost] <sb10q> master shouldn't be too hard, but there's just a bunch of boring details to sort out re. RTM clocking and management

14:09 <mtrbot-ml> [mattermost] <sb10q> and not that interesting to have afaict

14:14 <mtrbot-ml> [mattermost] <hartytp> ok. I wanted to test, but don't have a kasli to hand is all

15:28 <mtrbot-ml> [mattermost] <sb10q> Do you have metlino?

15:43 <mtrbot-ml> [mattermost] <hartytp> nope

15:44 <mtrbot-ml> [mattermost] <hartytp> I'll find a kasli

16:09 <mtrbot-ml> [mattermost] <hartytp> @astro following the nix install instructions for Artiq here https://m-labs.hk/artiq/manual-beta/installing.html#installing-via-nix-linux when I run `nux-shell` it tries to build gateware locally, which fails because I don't have vivado installed. Am I doing something daft, or should this be pulling binaries from M-Labs?

17:17 <mtrbot-ml> [mattermost] <hartytp> @sb10q I want to have a detailed look at phases on Sayma. Can you remind me how you have the clocking on the Sayma satellite configured? Are you using the Si5324 on the RTM as the DAC clock? Or are you using an external clock at f_rtio (100MHz?) on the RTM? I assume we need an external clock for any application requiring precise phase alignment between Sayma cards due to the known issues with the Si5324

17:17 <mtrbot-ml> [mattermost] <hartytp> (or is it not so bad?)

18:07 <mtrbot-ml> [mattermost] <hartytp> https://github.com/m-labs/artiq/blob/2538840756ee76ee49a72dc714361f25be2170ff/artiq/gateware/targets/sayma_rtm.py#L229 okay, it's using the CDR_CLK_CLEAN as the DAC clock source. If the gw is built with `--with-wrpll==False` (default) we use the Si5324 output

18:08 <mtrbot-ml> [mattermost] <hartytp> that all makes sense. I have some limited time budgeted to investigate Sayma. The question is whether it's worth looking at the phase between my Kasli reference clock (on the MMCX) and Sayma or whether the Si5324 is so bad that it's not even worth looking. Thoughts?

20:42 <mtrbot-ml> [mattermost] <dpn> Eldra: Regarding external clocks, what we do here is to use a high-ish quality external oscillator (Wenzel Citrine) to generate a 125 MHz clock, and then distribute that. This is supported in the current firmware as a build-time option, and leads to nice 1 ns fine timestamps, and is overall a painless solution. Of course, it is necessarily a fractional-N PLL to a 10/100 MHz reference, but since there is no place whe

20:44 <mtrbot-ml> [mattermost] <dpn> Eldra: In your analysis, don't forget that the phase noise of the Urukuls is worse when using the AD9910-internal PLLs than when directly supplying the SYSCLK (1 GHz in our case).

20:49 <mtrbot-ml> [mattermost] <dpn> Eldra: Generally, I'd really think twice before going to a non-power-of-two ref_multiplier. 125 MHz RTIO clock and 1 GHz Urukul SYSCLK/1 ns fine timestamp resolution is what we have extensively tested here at Oxford (also for the upcoming phase-coherent SUServo support). There is no reason 100 MHz/800 MHz/1.25 ns shouldn't also just work (apart from any RTIO implementation details that might escape me right now). Ev

20:59 <mtrbot-ml> [mattermost] <astro> right, right, you can use the nixbld.m-labs.hk binary cache: `nix-shell --option substituters https://nixbld.m-labs.hk --option trusted-public-keys "nixbld.m-labs.hk-1:5aSRVA5b320xbNvu30tqxVPXpld73bhtOeH6uAjRyHc="`