06:57 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #636: Funded by NIST. https://github.com/m-labs/artiq/issues/636#issuecomment-411656988

07:00 <GitHub-m-labs> [artiq] hartytp commented on issue #636: Great! https://github.com/m-labs/artiq/issues/636#issuecomment-411657611

07:27 <GitHub-m-labs> [artiq] sbourdeauducq opened issue #1130: Mirny support https://github.com/m-labs/artiq/issues/1130

07:31 <sb0> who suggested HMC833 for mirny? no way lol

08:41 <GitHub-m-labs> [artiq] hartytp commented on issue #1080: @gkasprow the AMC + RTM have been delivered and signed for in WUT. https://github.com/m-labs/artiq/issues/1080#issuecomment-411682941

10:11 <GitHub-m-labs> [artiq] sbourdeauducq pushed 4 new commits to master: https://github.com/m-labs/artiq/compare/a061ba250513...052e400f1217

10:11 <GitHub-m-labs> artiq/master 957645a Sebastien Bourdeauducq: examples: move kasli tester out of kasli_basic

10:11 <GitHub-m-labs> artiq/master bbc9841 Sebastien Bourdeauducq: test: dds → ad9914dds...

10:11 <GitHub-m-labs> artiq/master bf78e0c Sebastien Bourdeauducq: test: fix handling of missing devices

10:20 <GitHub-m-labs> [buildbot-config] sbourdeauducq pushed 1 new commit to master: https://git.io/fN9hE

10:20 <GitHub-m-labs> buildbot-config/master 00ce4bf Sebastien Bourdeauducq: style

10:47 <bb-m-labs> build #1770 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/1770

11:08 <bb-m-labs> build #1771 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/1771

11:19 <bb-m-labs> build #940 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/940

11:19 <bb-m-labs> build #2557 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2557

13:17 <hartytp> sb0: okay, the issues with my board were due to a missing capacitor

13:18 <hartytp> greg fixed it

13:18 <hartytp> sysref and PRBS now work!

13:18 <hartytp> so, that explains that. what a waste of time, but at least it's done

13:24 <hartytp> sb0: other than the sync, are there any other major Sayma issues remaining?

13:25 <hartytp> I should have my board back on Monday, is there anything you want me to look at when it arrives?

15:14 <sb0> hartytp, what capacitor is this, and why was the problem not found when looking at the clock at the FPGA or after it was received?

15:15 <sb0> hartytp, there is the sync (https://github.com/m-labs/artiq/issues/1129) and the STPL issue (https://github.com/m-labs/artiq/issues/1127)

15:17 <hartytp> sb0: not sure, Greg just sent me UART logs before and after fixing the cap

15:17 <hartytp> he'll post soon on GitHub I think

15:18 <hartytp> not sure why it wasn't seen when I looked at the output from the FPGA

15:18 <hartytp> maybe infrequent glitches that I missed?

15:18 <hartytp> or some high-frequency noise that only propagates through the GTX clock path, not the path I used?

15:19 <hartytp> STPL: hmm..not sure there is much I can contribute to that

15:20 <hartytp> #1129 -- yes, I can have a look at that

15:21 <sb0> hartytp, well, I don't really know what is going on with STPL either

15:21 <sb0> if I wasn't baffled by sayma-bugsⓇ 99.9% of the time, things would go a lot faster

15:22 <sb0> anyway, I guess the STPL bug can be worked around by reinitalizing JESD until it behaves - so it's not super high priority

15:22 <hartytp> agreed

15:23 <hartytp> did you see it on the KC705 + DAC eval board?

15:23 <hartytp> #1129 I'm happy to help with

15:23 <hartytp> can you post a description of what you want me to do

15:24 <hartytp> and remind me what your setup is?

15:24 <hartytp> e.g. which target, what clocks, etc

15:25 <sb0> hartytp, you can take the standalone target

15:25 <sb0> they all do SYSREF/RTIO align - including standalone, so that other RTIOs like TTLs are also synced with the DACs

15:27 <sb0> hartytp, then you can reboot the boards several times, looking at SYSREF at each DAC, and at the DAC outputs, and check that when the DAC go out of sync this corresponds to some abnormal phase difference between the SYSREFs

15:31 <hartytp> okay, so how about I program a startup kernel which sets all DAC channels to 100MHz and look at the phase difference between channels on a scope, checking that it's constant over power cycles?

15:31 <hartytp> can also toggle a TTL-SMA and check that it's constant w.r.t. the RTIO

15:33 <hartytp> (check that DAC zero-crossing timing is constant w.r.t. ttl after calling core.reset I mean)

15:33 <sb0> yes, sure

15:34 <sb0> but I already know what the result of #1 is. you'll see phase jumps as mentioned in the issue. better use a lower frequency than 100MHz so you get more range.

15:34 <sb0> well you can try reproducing the issue first before looking at SYSREF, it's not like Sayma doesn't have a massive track record of board-dependent bugs

15:37 <GitHub-m-labs> [artiq] hartytp commented on issue #1129: > Maybe someone with a fast scope, e.g. @hartytp or @gkasprow can confirm? It should be sufficient to measure the time difference of SYSREF edges between DAC0 and DAC1, and confirm that it is incorrectly varying between board reboots. (Those two SYSREF should actually occur at the same time, i.e. the time difference should be ~0, since everything is delay-matched)...

15:37 <hartytp> ack, will have a look at that

15:37 <hartytp> or see if greg/pawel can

15:40 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1129: You can try that, it's straightforward on the standalone target - but I doubt that'll make a change. The DACs are in one-shot sync mode now, and the code does not trigger any syncs until SYSREF/RTIO alignment is done. As I wrote, I suspect the HMC7043 sometimes permanently outputs broken SYSREFs after you use the cycle slip.... https://github.com/m-labs/artiq/

15:42 <GitHub-m-labs> [artiq] hartytp commented on issue #1129: okay, well it's easy to look at the two sysrefs and verify that their phase is constant w.r.t. each other and to the DAC clock. That's a good starting point. https://github.com/m-labs/artiq/issues/1129#issuecomment-411802834

15:49 <hartytp> anyway, if the PRBS issues are really gone on all boards, then we're finally at the point where Sayma at least produces RF reliably, which is a huge step forwards

15:49 <hartytp> just need the synchronisation to work and we're done

15:49 <hartytp> :)