10:20 <mtrbot-ml> [mattermost] <hartytp> @sb10q am I right in thinking that this https://github.com/m-labs/artiq/blob/2538840756ee76ee49a72dc714361f25be2170ff/artiq/gateware/jesd204_tools.py#L197-L200 is basically S/H validation for the SYSREF signal?

10:21 <mtrbot-ml> [mattermost] <hartytp> You're just relying on the fact that the board delays always place the SYSREF edges in the final SERDES bin (without any tuning to ensure this)?

10:31 <mtrbot-ml> [mattermost] <sb10q> No

10:32 <mtrbot-ml> [mattermost] <sb10q> There is tuning, and then the tuned value is stored in flash and later validated at every restart

10:35 <mtrbot-ml> [mattermost] <sb10q> At the FPGA side, the serdes is only there for s/h validation. A normal register is sufficient if there's no validation

10:42 <mtrbot-ml> [mattermost] <hartytp> I see, the tuning happens in `sysref_auto_align`. I haven't understood the program control in satman, but doesn't the auto_align need to happen before rtio_align. But, from the code it looks to me like things happen the other way around (at least, rtio_align is higher up in the function code)

10:52 <mtrbot-ml> [mattermost] <hartytp> also, it looks like the SysrefSampler is on the AMC FPGA, but the S/H tuning uses the DDMTD core on the RTM FPGA. So, how are you ensuring S/H is met at the AMC with that tuning?

10:52 <mtrbot-ml> [mattermost] <hartytp> (I'm probably missing something, but just haven't understood the logic yet)

11:11 <mtrbot-ml> [mattermost] <sb10q> both RTM and AMC FPGAs are clocked from the same source

11:12 <mtrbot-ml> [mattermost] <sb10q> the target DDMTD value on the RTM that meets S/H on the AMC is determined and then fixed and stored in flash

11:18 <mtrbot-ml> [mattermost] <hartytp> right, thanks. I see that's how measure_sysref_sh_limits works

11:19 <mtrbot-ml> [mattermost] <hartytp> in satman/main is it guaranteed that sysref_rtio_align will always be called after sysref_rtio_auto_align

11:21 <mtrbot-ml> [mattermost] <sb10q> sysref_rtio_align does require sysref_rtio_auto_align to have been called before

11:22 <mtrbot-ml> [mattermost] <sb10q> and yes, it is only called when the TSC is reloaded, to move the SYSREF phase by integer multiples of the RTIO clock period

11:22 <mtrbot-ml> [mattermost] <sb10q> if satman receives a TSC reload event, it is after the link has been established and sysref_rtio_auto_align called

11:23 <mtrbot-ml> [mattermost] <hartytp> okay, that makes sense, thanks.

12:14 <mtrbot-ml> [mattermost] <hartytp> @sb10q the code looks much better now. I particularly appreciate all the test cases. They provide a really nice way of confirming that my reading of the datasheets is correct

12:16 <mtrbot-ml> [mattermost] <hartytp> @sb10q I've written some notes on Sayma clocking and sync on the wiki. When you get a moment, would you mind casting an eye over them and checking they're correct? https://github.com/sinara-hw/Sayma_RTM/wiki/clocking_synchronisation

13:28 <mtrbot-ml> [mattermost] <sb10q> "coarse" cycle-slip based delay with a resolution of 1/2 DAC clock cycle

13:28 <mtrbot-ml> [mattermost] <sb10q> It's 1 not 1/2

13:28 <mtrbot-ml> [mattermost] <sb10q> We're not anymore using that delay (which is also not slip based) that has 1/2 resolution

14:07 <mtrbot-ml> [mattermost] <sb10q> the optimal phase is saved into/loaded from the configuration EEPROM

14:07 <mtrbot-ml> [mattermost] <sb10q> It's the nor flash not eeprom

14:10 <mtrbot-ml> [mattermost] <sb10q> the DACs provide an internal S/H validator for alignment << we're not using it, we're measuring at what delay values there are rotations, and check that the target delay value is sufficiently away from them