02:48 <sb0> "what's the right way of doing that over DRTIO" << I guess add aux packets similar to non-RT SPI and I2C

02:49 <sb0> "Kasli + DIO breakout + ADF eval board to get a driver written for the PLL before v2.0 hw arrives" << great! also check carefully that the phase is deterministic for all the frequencies we want.

02:50 <sb0> "there is no easy way of implementing DRTIO on Sayma RTM" << things are rarely "easy" :) what do you mean?

02:50 <sb0> the only significant issues are 1) using SRAM 2) getting a transceiver link

02:51 <sb0> for 2)we should be able to use a SATA cable between AMC and RTM

02:51 <sb0> then it's mostly dealing with the xilinx transceiver clocking BS

03:07 <hartytp> sb0: hmm... one of the things that made the HMC830 a PITA to work with was the fact that we couldn't read back registers in the VCO subsystem. That's still better than the ADF PLLs, which don't have a MISO at all

03:13 <hartytp> sb0: "I guess add aux packets similar to non-RT SPI and I2C "

03:14 <hartytp> okay, that was my assumption. Is using the DRTIO aux interface to do this documented? What is the best place to look for an example?

03:14 <hartytp> "great! also check carefully that the phase is deterministic for all the frequencies we want. " yes, will do

03:15 <hartytp> "<< things are rarely "easy" :) what do you mean? " << I'd forgotten there was a SATA and was worried we'd have to do something nasty like DRTIO over SERDES

03:15 <hartytp> (well not exactly "nasty" but quite a bit of work)

03:20 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #792: Yes, this is fully funded.... https://github.com/m-labs/artiq/issues/792#issuecomment-450064470

03:22 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #792: Yes, this is fully funded.... https://github.com/m-labs/artiq/issues/792#issuecomment-450064470

03:25 <sb0> oh it's nasty with the ultrascale tpws problem, and also the iodelay...

03:26 <hartytp> ouch

03:26 <hartytp> nasty

03:26 <sb0> anyway, just use SATA

03:26 <sb0> then it's exactly like DRTIO between Sayma and Kasli, which is tested, and works

03:26 <hartytp> well, imho, that's a good reason to put the SYSREF logic on the RTM FPGA rather than routing it via the AMC<->RTM connector

03:26 <hartytp> ack, let's do that

03:27 <sb0> so the ADF PLLs are fully write-only?

03:28 <sb0> for examples, look at the I2C/SPI routines

03:28 <sb0> anyway that's something I can do

03:33 <hartytp> sb0: yes, they are write only (same goes for the PLL on mirny) https://www.analog.com/media/en/technical-documentation/data-sheets/adf4356.pdf

03:33 <hartytp> just clk, sdi and LE

03:33 <hartytp> sb0: ok

03:33 <hartytp> how are we dividing the work for new sync etc?

03:34 <hartytp> things like configuring the JESD core via DRTIO aux will take me some time as I've never looked at that part of the codebase, other parts like porting the DAC config to a core device driver are boring but should be straightforward

03:40 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #619: @hartytp DRTIO switching is partly funded through your contract and through the Sayma contract (this Issue is about switching support, not transceiver-related issues).... https://github.com/m-labs/artiq/issues/619#issuecomment-450066672

03:44 <GitHub-m-labs> [artiq] hartytp commented on issue #619: ack... https://github.com/m-labs/artiq/issues/619#issuecomment-450067071

03:46 <GitHub-m-labs> [artiq] sbourdeauducq closed issue #619: DRTIO switch support for Sayma RTM https://github.com/m-labs/artiq/issues/619

03:50 <sb0> hartytp: I'll do JESD core control over DRTIO

03:52 <sb0> well aux channel or put it into a RTIO PHY, since everything seems to be moving to RT control

03:54 <hartytp> okay, so you want me to do the DAC SPI port?

03:54 <hartytp> (that's fine, just want to be clear about who's doing what)

03:56 <sb0> if you have time, but I'm happy to do that as well

03:57 <sb0> there is some old code for this BTW (initially it was a kernel already, on the kc705 phaser)

03:58 <hartytp> sb0: good

03:58 <hartytp> if you can do it, that would be great

03:59 <hartytp> I'm writing an ADF4356 core device driver now, to test next week

03:59 <sb0> ok, will do

03:59 <sb0> great

03:59 <sb0> so the chip will be ADF4356? sure? (assuming it does work)

03:59 <sb0> both on sayma and mirny

04:00 <hartytp> I haven't had much input on Mirny, think rjo had chosen ADF for that

04:00 <hartytp> for Sayma, seems that way unless someone has a better idea

04:01 <hartytp> (a) it's the only chip I saw with a BD that implied the output dividers are inside the feedback path

04:01 <hartytp> (b) the phase noise doesn't suck

04:01 <sb0> well it would be best to keep the same PLL, so we have less code to write and maintain and manufacturers have less parts to source and stock

04:01 <hartytp> right

04:02 <sb0> hartytp: Stabilizer would be used for the coil current control loop as well?

04:02 <hartytp> the only thing to be aware of is that mirny will probably have the ADF*5*356 which has an output doubler

04:02 <hartytp> the registers are similar but have a few differences (from a very quick skim over the data sheet) may need some annoying special casing to support both chips in the same driver, but I haven't given that too much thought

04:03 <hartytp> we could use that chip on Sayma as well, but it's more expensive and seems like a waste

04:03 <hartytp> sb0: yes, that's the idea

04:03 <hartytp> the idea is to have an AFE mezzanine that plugs into stabilizer

04:04 <hartytp> the afe has high-gain error subtractor with very low noise dacs. after that, the 16-bit ADC on stabilizer should provide enough dynamic range to do the job

04:05 <hartytp> the afe mezzanine also has current shunts for feedback and feedforward using the stabilizer DACs

04:05 <hartytp> so you get the complete solution on a 2x4 stacked eurocard

04:07 <sb0> okay, and all those things are funded or there are agreements for the hardware to get made?

04:08 <hartytp> stabilizer itself is now complete (well, maybe one or two things left to finish, but will be sent to manufacture in a week or two)

04:09 <hartytp> the current sense afe you'd have to ask cjbe as he's the one who's doing it, but I suspect it will be done by end of week 1 jan

04:16 <hartytp> ps: thanks for the cheese :)

08:21 <sb0> ah, there's another of those stupid US government shutdowns

08:23 <cr1901_modern> You tried accessing NIST website, didn't you?

08:24 <cr1901_modern> I just love how everyone else on this planet needs to be privy to the dysfunction of a single country because said country is full of deeply unpleasant people.

09:46 <sb0> hartytp: BTW if you have more time for sayma, you can look into the "ramp generator bug". it might be because of the clocking changes, or the JESD204 bugfixes. if that is indeed the case, as tedious as it is, bisecting and pinpointing the exact change that caused the problem will be very helpful

09:46 <sb0> _florent_: do you have any idea what could be causing the problem btw? https://github.com/m-labs/artiq/issues/1166

09:46 <sb0> I won't have access to boards before Jan 1

14:00 <hartytp> sb0: ack, I'm not back in the lab until the 3rd

14:00 <hartytp> testing out the new PLL is higher on my to do list than the ramp gen issue

14:01 <hartytp> once that's done, I may be able to help, but I have a few deadlines coming up so lengthly dissection is going to be tough for me to do soon

14:02 <hartytp> if you have specific commits you want checked then I can look at that, but we'd need to find one where ser-wb isn't so broken that nothing works (or just apply the ser-wb fix to an old commit)

14:03 <hartytp> anyway, I'd prefer not to start digging into the git history until you've confirmed that you can reproduce this issue

14:35 <GitHub-m-labs> [artiq] hartytp commented on issue #1166: Digging through the issue trackers to remind myself the history of this issue:... https://github.com/m-labs/artiq/issues/1166#issuecomment-450161347

15:21 <_florent_> sb0: i'll rebuild and test my simple design with KCU105 + AD9154 FMC next week to verify

16:19 <_whitenotifier-6> [m-labs/nmigen] whitequark pushed 2 commits to master [+0/-0/±4] https://git.io/fhkBO

16:19 <_whitenotifier-6> [m-labs/nmigen] whitequark de50cce - hdl.mem: add missing __all__.

16:19 <_whitenotifier-6> [m-labs/nmigen] whitequark 470d669 - hdl.dsl: add support for fsm.ongoing().

16:21 <_whitenotifier-6> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/472701617?utm_source=github_status&utm_medium=notification

16:21 <_whitenotifier-6> [nmigen] Success. 80.67% (+0.06%) compared to 73ed870 - https://codecov.io/gh/m-labs/nmigen/commit/470d66934f9b1939c896389d06867342adf2cc66

16:21 <_whitenotifier-6> [nmigen] Success. 100% of diff hit (target 80.61%) - https://codecov.io/gh/m-labs/nmigen/commit/470d66934f9b1939c896389d06867342adf2cc66

17:29 <GitHub114> [smoltcp] 1uka commented on issue #268: If there is nothing more to be done about this PR, could you please merge it and close it? https://github.com/m-labs/smoltcp/pull/268#issuecomment-450196223

17:32 <GitHub101> [smoltcp] whitequark commented on issue #268: Can you please add a Travis builder that uses macOS? After that I'll merge. https://github.com/m-labs/smoltcp/pull/268#issuecomment-450196834

17:46 <GitHub136> [smoltcp] 1uka commented on issue #268: Should I add one only for builds with the 'phy-raw_socket' feature or for all builds? I am not familiar with Travis CI, just now I am reading through the docs (specifically [this page](https://docs.travis-ci.com/user/multi-os)) https://github.com/m-labs/smoltcp/pull/268#issuecomment-450199006

17:47 <GitHub189> [smoltcp] whitequark commented on issue #268: I think one build with `phy-raw_socket` feature enabled, as everything else is not platform-dependent. Thanks! https://github.com/m-labs/smoltcp/pull/268#issuecomment-450199110

18:05 <GitHub8> [smoltcp] 1uka commented on issue #268: Sorry if I am annoying, there was an error when building only with 'phy-raw_socket', namely:... https://github.com/m-labs/smoltcp/pull/268#issuecomment-450201992

18:13 <GitHub86> [smoltcp] whitequark commented on issue #268: That's fine. https://github.com/m-labs/smoltcp/pull/268#issuecomment-450203358

18:28 <key2> what is the fwft parameter of SyncFIFO ?

19:41 <rohitksingh> key2: do you mean to ask what is fwft? it refers to "first word fall through", a fifo behaviour where the first word written to the fifo is immediately available on the output, at the expense of comparatively worse timing. https://www.google.co.in/search?q=fwft+fifo

21:46 <_whitenotifier-6> [m-labs/nmigen] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/fhk6H

21:46 <_whitenotifier-6> [m-labs/nmigen] whitequark 3ea35b8 - lib.coding: fix tests to actually run, and fix code to fix tests.

21:47 <_whitenotifier-6> [nmigen] Success. The Travis CI build passed - https://travis-ci.org/m-labs/nmigen/builds/472795818?utm_source=github_status&utm_medium=notification

21:47 <_whitenotifier-6> [nmigen] Success. Absolute coverage decreased by -<.01% but relative coverage increased by +19.32% compared to 470d669 - https://codecov.io/gh/m-labs/nmigen/commit/3ea35b8566e4fe6b0ba24fb61257c6667cdbbf17

21:47 <_whitenotifier-6> [nmigen] Success. 100% of diff hit (target 80.67%) - https://codecov.io/gh/m-labs/nmigen/commit/3ea35b8566e4fe6b0ba24fb61257c6667cdbbf17

23:48 <whitequark> sb0: why is there both a Record.connect and Record.connect_flat?