00:17 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1129: Or more simply, the margin scans can be disabled (if that doesn't make the bug disappear). https://github.com/m-labs/artiq/issues/1129#issuecomment-415913344

01:35 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1137: > However, does this "latency" change for remote input events from somewhere down the DRTIO tree?... https://github.com/m-labs/artiq/issues/1137#issuecomment-415921243

07:10 <hartytp> larsc: any idea why ADI seem to have given up on high-quality fast 16-bit DACs like the AD9726?

07:10 <hartytp> all newer models are 14-bits

07:10 <hartytp> do they just feel that there is no market for the 16-bit parallel DACs?

07:11 <hartytp> also, am I right in thinking that there are still no plans to obsolete/end of life the AD9726? I'm assuming that the "not recommended for new designs" is someone trying to push the newer 14-bit DACs on users, not an indicator of impending EOL

10:18 <sb0> hartytp, how important is it right now, considering you can use a 10-port master from sayma, which also has lower-latency than switching?

10:18 <sb0> my plan was to look into it after 4.0 is out, and after #636 is working

14:21 <hartytp> sb0: it's becoming pressing for us because we need to get it completed, tested and paid in good time before the grant runs out

14:22 <hartytp> if we leave it until the last possible minute then it's going to create a headache for me

14:25 <hartytp> I know there is a lot in the pipeline right now, but we're coming up to the one year anniversary of the order being placed, so it would be nice to start soon

14:26 <hartytp> also, the Sayma 10-port master is nice in principle, but we don't have enough of them to run our experiments and there won't be any more available any time soon

14:26 <hartytp> not to mention that, given the history of Sayma, I wouldn't want to rely on it being the master for my experiment just yet

17:14 <sb0> hartytp, I'm still worried that the 7044 will not work, not only because HMC chips are junk, but also because hitting the 100MHz edges from a 150MHz clock sounds tricky

17:14 <sb0> can we get the existing stuff to work before adding complex new features?

17:34 <hartytp> sb0: personally, I'm done looking into the current sync scheme

17:34 <hartytp> but, that shouldn't stop you from continuing work

17:35 <hartytp> my feeling is just that the HMC7044 will be easiest and most reliable in the long run

17:35 <hartytp> re your concern with the reference clock being different to the rtio clock...

17:35 <hartytp> I'd advocate that, at least in the short term, we demand that users use a reference clock at f_rtio

17:36 <hartytp> 125MHz/150MHz references from Wenzel etc are not expensive or hard to come by

17:36 <hartytp> or expensive compared to Sayma

17:36 <hartytp> and most people have synths anyway

17:36 <sb0> does the hmc7044 provide a constant input-to-output skew without bug? isn't that one of the "advanced" features that no one else uses and is a total mess due to silicon bugs and poor HMC design?

17:37 <hartytp> afaict, yes

17:37 <hartytp> but, I have an eval board and I can test that very quickly

17:39 <hartytp> the sync schemes I've seen in various white papers (and some papers from SCQC groups building systems like ours) use the HMC7044 in combination with an FPGA-generated trigger to provide deterministic latency between the FPGA clock and the DACs

17:40 <hartytp> put it this way: can we come up with a series of tests that I can do in half a day or so using stuff I have in my lab that will give us an indication of whether the HMC7044 is likely to do what we want without too much pain

17:41 <hartytp> if we can, then I think it's worth exploring it as an alternative

17:45 <sb0> well first of all, every test has to be repeated ~100 times, the HMC crap is sneaky

17:46 <hartytp> sure

17:47 <sb0> so there is:

17:47 <sb0> in-to-out skew with 150MHz in and 150MHz out

17:47 <sb0> 600MHz out, also constant skew (that one is hard to mess up, but HMC are experts at messing up)

17:48 <sb0> two SYSREF generated at the right frequency

17:48 <hartytp> yes

17:48 <hartytp> all sounds fairly easy to test with a multi-channel fast scope

17:48 <hartytp> right?

17:48 <sb0> SYSREF delay tunable smoothly over one DAC clock cycle

17:48 <hartytp> yes

17:49 <sb0> and then constant skew between a CLKIN edge designated by RFSYNCIN and the next SYSREF edge

17:49 <sb0> and no bug and other HMC shenanigans with every combination of the above

17:49 <hartytp> anyway, before we discuss this too much further, let me re-read the white papers as it's been a while since I thought about that

17:49 <sb0> that is all, I think. JESD sync isn't that complicated, it's only the HMC7043...

17:50 <hartytp> okay, well that sounds like a plan then, pending my re-reading the white papers and checking that my memory for how the 44 works is correct

17:50 <hartytp> (well, how it's supposed to work at any rate)

17:51 <sb0> yes, a fast scope definitely helps with those tests

17:52 <hartytp> cool. I'll write this up and post a detailed proposal on GitHub in the next few days. First, I need to finish stress-testing booster

17:52 <hartytp> (if you find £25k under a mattress at some point, I'd really recommend the key sight scopes. they're ace)

17:53 <sb0> also, the SYSREF delay tuning does not have to be hitless - we can put the DAC into single-shot mode, so it ignores the HMC output when it is incorrect

17:54 <sb0> ah and while you're at it, you can check the setup/hold numbers on RFSYNCIN. don't trust the datasheet.

17:55 <hartytp> ack