01:25 <sb0> jbqubit, yes, as i said you have an old artiq-dev

01:25 <sb0> look at its version it's 2.4, and you're installing a 3.0 phaser

01:27 <GitHub51> [artiq] sbourdeauducq closed issue #833: ARTIQ 3 release candidate? https://github.com/m-labs/artiq/issues/833

01:27 <GitHub50> [artiq] sbourdeauducq commented on issue #833: This is not an Issue. Yes we will make one as soon as #830 is resolved. https://github.com/m-labs/artiq/issues/833#issuecomment-332059198

01:44 <cr1901_modern> https://twitter.com/cr1901/status/912491635052892161 Been meaning to do this ever since I got iCEStick support, but better late than never. Should help others get started w/ Migen for boards not yet supported.

04:21 <GitHub126> [artiq] sbourdeauducq closed issue #485: figure out strange runtime timing behavior https://github.com/m-labs/artiq/issues/485

07:09 <sb0> bb-m-labs, force build --branch=rtio-sed artiq

07:09 <bb-m-labs> build forced [ETA 34m35s]

07:09 <bb-m-labs> I'll give a shout when the build finishes

07:09 <GitHub168> [artiq] sbourdeauducq pushed 1 new commit to rtio-sed: https://github.com/m-labs/artiq/commit/4112e403de6350d67343475f0b367878c4ce5980

07:09 <GitHub168> artiq/rtio-sed 4112e40 Sebastien Bourdeauducq: rtio/sed: latency compensation

07:40 <sb0> gee, it met timing!

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

07:42 <bb-m-labs> build #1686 of artiq is complete: Failure [failed artiq_flash] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1686

07:48 <cr1901_modern> My favorite is when Xilinx claims the design doesn't meet timing but only issues a warning instead of an error (And of course I can't check how the tool decides b/c lol proprietary)

07:50 <sb0> you can still do something with the output, e.g. load it anyway, or analyze it to determine the source of the problem

07:53 <cr1901_modern> Well in my case, the design actually works. Fair point re: analyze (don't remember the critical path)

08:11 <GitHub95> [artiq] sbourdeauducq pushed 3 new commits to rtio-sed: https://github.com/m-labs/artiq/compare/4112e403de63...e6f0ce3abad0

08:11 <GitHub95> artiq/rtio-sed f079ac6 Sebastien Bourdeauducq: rtio/sed: disable wait in TestLaneDistributor.test_regular

08:11 <GitHub95> artiq/rtio-sed 9905b87 Sebastien Bourdeauducq: rtio/sed: support negative latency compensation

08:11 <GitHub95> artiq/rtio-sed e6f0ce3 Sebastien Bourdeauducq: rtio/sed: test latency compensation

08:37 <hartytp> sb0: is that compensation as in #40?

08:38 <sb0> part of it, just to operate the sawg

08:39 <sb0> #40 would expose the value, and have fine timestamp resolution

08:44 <GitHub36> [artiq] sbourdeauducq pushed 1 new commit to rtio-sed: https://github.com/m-labs/artiq/commit/d7ef07a0c256f9aeb7d0fc43a5f3c20ed58117e1

08:44 <GitHub36> artiq/rtio-sed d7ef07a Sebastien Bourdeauducq: rtio/sed: document architecture

08:48 <GitHub70> [artiq] sbourdeauducq pushed 1 new commit to rtio-sed: https://github.com/m-labs/artiq/commit/73043c34641b2910cf802bc7aeaaccda19ea25f9

08:48 <GitHub70> artiq/rtio-sed 73043c3 Sebastien Bourdeauducq: drtio: disable SED lane spread...

08:55 <hartytp> thanks, good to know

09:07 <GitHub44> [artiq] sbourdeauducq commented on issue #778: The SED latency at the FIFO output is:... https://github.com/m-labs/artiq/issues/778#issuecomment-332135664

09:08 <GitHub184> [artiq] sbourdeauducq commented on issue #778: The SED latency at the FIFO output is:... https://github.com/m-labs/artiq/issues/778#issuecomment-332135664

09:08 <GitHub94> [artiq] sbourdeauducq commented on issue #778: The SED latency at the FIFO output is:... https://github.com/m-labs/artiq/issues/778#issuecomment-332135664

09:09 <GitHub178> [artiq] sbourdeauducq commented on issue #778: The SED latency at the FIFO output is:... https://github.com/m-labs/artiq/issues/778#issuecomment-332135664

09:14 <GitHub47> [artiq] sbourdeauducq pushed 1 new commit to rtio-sed: https://github.com/m-labs/artiq/commit/4e31e9a9ac3c26fee24238e388fc55c04622f69f

09:14 <GitHub47> artiq/rtio-sed 4e31e9a Sebastien Bourdeauducq: test: relax test_rtio.test_loopback...

09:14 <sb0> bb-m-labs, force build --branch=rtio-sed artiq

09:14 <bb-m-labs> build forced [ETA 34m35s]

09:14 <bb-m-labs> I'll give a shout when the build finishes

09:14 <GitHub166> [artiq] sbourdeauducq closed issue #778: RTIO scalable event dispatcher (fka. SRTIO) https://github.com/m-labs/artiq/issues/778

09:18 <GitHub14> [artiq] sbourdeauducq opened issue #834: SED made DMA startup slow https://github.com/m-labs/artiq/issues/834

09:27 <sb0> rjo, SED architecture description is in the __init__.py docstring. is there still something unclear about it?

09:32 <rjo> sb0: sounds good. thanks.

09:32 <rjo> sb0: does it also work at 150 MHz?

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

09:45 <bb-m-labs> build #1687 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1687

09:51 <sb0> rjo, isn't the clocking plan for Sinara still using a 125MHz RTIO clock?

09:51 <sb0> https://github.com/m-labs/sinara/wiki/SinaraClocking

09:52 <sb0> ah the kc705 phaser is 150

10:12 <rjo> sb0: sayma will be 150 MHz. b/c jesd etc.

10:27 <sb0> rjo, since when? I thought it was going to be the "B" option on the wiki page above

10:28 <sb0> and _florent_ has already started on configuring transceivers for 5Gbps

10:31 <sb0> rjo, SED meets timing at 150, so at least that part won't be a problem

10:43 <_florent_> sb0: what's the expected transceiver speed then?

10:43 <sb0> rjo, ^

10:44 <_florent_> sb0: but not sure it will be impacting a lot

11:02 <rjo> i mentioned that 6 gbps is the relevant option many times.

11:05 <sb0> rjo, the wiki needs updating then

11:05 <sb0> and I think the backplane is specified for 5

11:06 <rjo> sb0: that's why there is 3 gbps for drtio in there iirc.

11:07 <sb0> rjo, so which of those clocking options are we using?

11:07 <rjo> sb0: the rationale was that 600 mhz data rate would cover the frequency requuirements and save resources.

11:07 <rjo> A iirc.

11:07 <sb0> okay

11:08 <sb0> well that simplfies things actually, since the transceiver ratio is only 20 instead of 40

11:08 <sb0> less risk of comma alignment failing or timing problems

11:09 <rjo> the 600 vs 1000 MHz correspondes to 150 vs 125 MHz which weighs low resource usage and wider RTIO "baseband" width against wider carrier width.

11:09 <rjo> what part of the wiki needs updating?

11:09 <sb0> there is no 6Gbps option on the wiki

11:09 <sb0> https://github.com/m-labs/sinara/wiki/SinaraClocking

11:10 <sb0> well, unless you are talking about the JESD frequency

11:10 <_florent_> so 6gbps jesd / 3gbps drtio?

11:11 <sb0> _florent_, have you already tested the brute-force clock aligner at 40x?

11:12 <_florent_> sb0: I did a test at 40x, it was not working but haven't investigated

11:12 <sb0> also it would be good to keep the 40x code somewhere in case we need it later

11:12 <_florent_> yes i made things generic

11:14 <sb0> I need to check with Oxford because we have a spec for >= 4Gbps data rate ...

11:21 <rjo> yes. 6 gbps jesd.

11:22 <rjo> also let's check back with the jqi folks again (the new ones). their priorities may have shifted (again).

11:31 <sb0> rjo, can you send that JQI email?

12:14 <rjo> done.

12:27 <rjo> sb0, whitequark: could someone power toggle the sayma boards? or is the relais connected?

12:34 <sb0> rjo, all three of them? I can cycle them tomorrow

12:35 <sb0> I can connect the relay as well (one relay for all three boards)

15:54 <rjo> sb0: all three. yes. iirc whitequark wanted to connect the relais before but i don't know whether that was done.

16:01 <GitHub162> [artiq] jbqubit commented on issue #813: Moving email discussion to this Issue....... https://github.com/m-labs/artiq/issues/813#issuecomment-332247151

16:31 <GitHub101> [artiq] sbourdeauducq commented on issue #813: > Moving email discussion to this Issue....... https://github.com/m-labs/artiq/issues/813#issuecomment-332257256

21:12 <GitHub140> [artiq] dhslichter commented on issue #778: @sbourdeauducq this is nice. However, to continue the discussion from #40, if there is automatic latency compensation, you will get very different FIFO usage depending on the order in which pulses in a `with parallel` block are given (as the latency compensation might render them in order or out of order, after being applied). It seems that it would make sense, to the extent possible, to bring the `wi