04:19 <sb0> rjo, what did you load into the kasli to burn the fpga?

04:44 <kraza> Hello. rqou told me about this channel.

04:44 <sb0> hi kraza

04:45 <kraza> Yeah, I'm another high vacuum guy.

07:16 <GitHub133> [artiq] sbourdeauducq commented on issue #854: > I loaded both FPGA manually... https://github.com/m-labs/artiq/issues/854#issuecomment-361158617

07:16 <GitHub177> [artiq] sbourdeauducq commented on issue #854: > I loaded both FPGA manually... https://github.com/m-labs/artiq/issues/854#issuecomment-361158617

07:30 <GitHub46> [ionpak] whitequark pushed 1 new commit to master: https://github.com/m-labs/ionpak/commit/724221c64378624c51468fabd944e4f608ec386b

07:30 <GitHub46> ionpak/master 724221c whitequark: Revert the rx_buf_release() change in 8491394a.

07:43 <GitHub147> [ionpak] whitequark pushed 1 new commit to master: https://github.com/m-labs/ionpak/commit/dcb5321e8208ebbb883fa4bbb638da5842e6fa8d

07:43 <GitHub147> ionpak/master dcb5321 whitequark: Fix cmp::max/min mixup in 8491394a.

08:03 <whitequark> sb0: this is extremely strange

08:03 <whitequark> I haven't changed anything else...

08:05 <whitequark> sb0: can you check with this patch? https://hastebin.com/obututafak.php

08:31 <sb0> whitequark, just trying to get anything going right now; and I cannot compile the old version because the new rustc ICEs, and trying some old ones fail with "error[E0522]: definition of an unknown language item: `u128_rem`."

08:38 <sb0> in compiler_builtins

09:02 <sb0> okay, got the old version to work again. i'll just wait longer for the scan...

09:45 <GitHub54> [smoltcp] 0x7CFE commented on issue #100: > that doesn't work on #![no_std] unfortunately, which is smoltcp's primary deployment target.... https://github.com/m-labs/smoltcp/pull/100#issuecomment-361191570

10:49 <rjo> cr1901_modern: checking voltages and temperatures

10:49 <rjo> sb0: "burn the fpga"?

10:57 <_florent_> sb0: i'm testing drtio, link is fine between kcu105 and my artix7 board at 3.0gbps with code from my transceiver test repo. I'm now going to apply the small changes you did to be sure it does not break things.

12:13 <_florent_> sb0: when updating drtio code with what is in misoc/artiq, drtio is still running fine between kcu105 and my artix7 board. Can you do some basic checks: that you si5324 is generating a 150Mhz clock, that tx and rx init fsm are in the READY state?

13:00 <GitHub24> [smoltcp] dlrobertson commented on pull request #125 839fa3f: Yup. Thanks for the update. https://github.com/m-labs/smoltcp/pull/125#discussion_r164423292

13:05 <GitHub155> [smoltcp] dlrobertson commented on pull request #125 839fa3f: :+1: Thanks! Just a side note. I personally I tend to prefer using... https://github.com/m-labs/smoltcp/pull/125#discussion_r164424310

13:09 <GitHub104> [smoltcp] whitequark commented on pull request #125 839fa3f: No, this is fine in `mod fields`, since it has a specific structure. https://github.com/m-labs/smoltcp/pull/125#discussion_r164425157

14:30 <GitHub198> [smoltcp] LuoZijun commented on issue #136: @whitequark ... https://github.com/m-labs/smoltcp/pull/136#issuecomment-361262495

14:47 <sb0> rjo, didn't you have a kasli fpga overheating and burning?

14:48 <sb0> _florent_, can you connect to the m-labs server with ssh and try it on the two kasli connected there?

14:49 <_florent_> sb0: i can do some test on the server yes, but need to know how things are connected

14:49 <sb0> _florent_, there's kasli-1 and kasli-2 (just like sayma) and copper sfp between sfp2 of kasli-1 and sfp0 of kasli-2

14:50 <_florent_> sb0: have you checked the clock generated with the si5324?

14:50 <sb0> the si5324 locks but I have not looked further

14:51 <sb0> maybe the qpll has to be held in reset until the si5324 is initialized?

14:51 <_florent_> maybe, but that's strange you don't get anything on tx

14:52 <_florent_> i'm working on multi lane for the gth now

14:52 <_florent_> in case you have some time before i test on kasli, that would be interesting to check the clock and the init states machines

14:54 <sb0> if the qpll doesn't work, that would break tx as well

14:56 <_florent_> sb0: yes probably, can you at least check if the tx fsm goes to the ready state?

14:58 <sb0> _florent_, multilink is lower priority than getting single-link drtio actually working

15:07 <_florent_> sb0: ok, i'll take care of finishing/debugging drtio integration on kasli then

15:07 <GitHub168> [smoltcp] hjr3 commented on pull request #125 839fa3f: I was following the convention as I saw it here: https://github.com/m-labs/smoltcp/blob/c2d18ec071a2cd68aee2724ce13eefa6ccf1f0c1/src/wire/tcp.rs#L75 https://github.com/m-labs/smoltcp/pull/125#discussion_r164457511

15:42 <GitHub9> [artiq] jbqubit commented on issue #854: > @marmeladapk could you please check and ping the board?... https://github.com/m-labs/artiq/issues/854#issuecomment-361285820

15:46 <rjo> sb0: not me. pawel.

16:04 <GitHub130> [artiq] jbqubit opened issue #910: vivado version check https://github.com/m-labs/artiq/issues/910

16:04 <GitHub124> [artiq] jbqubit commented on issue #908: I'm using 2016.2. Will upgrade and try again. https://github.com/m-labs/artiq/issues/908#issuecomment-361293513

17:21 <GitHub26> [artiq] sbourdeauducq commented on issue #910: So what should this say, exactly? https://github.com/m-labs/artiq/issues/910#issuecomment-361318976

17:28 <dlrobertson> whitquark: RedoxOS is gathering up some GSoC projects and I proposed two projects that would involve a lot of smoltcp work

17:28 <dlrobertson> specifically IP fragmentation

17:29 <dlrobertson> And batonius proposed path MTU discovery

17:29 <dlrobertson> Are you okay with that?

17:32 <dlrobertson> whitequark: I can send you the writeup if you'd like

18:02 <rjo> dlrobertson: nice! i guess you guys will be supervising?

18:03 <dlrobertson> rjo: That is my second question :)

18:04 <dlrobertson> I'd be up for mentoring or if you guys would like to be more involved we could probably do that somehow

18:08 <GitHub100> [artiq] dhslichter commented on issue #652: @sbourdeauducq ack. Is the conda ecosystem ready for ARTIQ to upgrade to 3.6? This was one of the previous issues raised about it. https://github.com/m-labs/artiq/issues/652#issuecomment-361333657

18:09 <GitHub64> [artiq] dhslichter commented on issue #407: @sbourdeauducq what changed between your original measurement of 83 ms (before you edited the comment) and the edited value of 62 ms above? https://github.com/m-labs/artiq/issues/407#issuecomment-361334117

19:25 <GitHub94> [artiq] jbqubit commented on issue #910: Add Vivado version information to some file in ARTIQ codebase (like meta.yaml for conda). Scripts in artiq/gateware/targets halt if wrong version of vivado is used. A script flag permits build with outdated vivado. https://github.com/m-labs/artiq/issues/910#issuecomment-361357128

19:47 <GitHub2> [artiq] jbqubit commented on issue #910: [Instructions](http://www.m-labs.hk/artiq/manual-master/developing.html#) for installing Xilinx build tool need more specificity. ... https://github.com/m-labs/artiq/issues/910#issuecomment-361364055

20:18 <GitHub47> [artiq] marmeladapk commented on issue #854: @sbourdeauducq I flashed it now:... https://github.com/m-labs/artiq/issues/854#issuecomment-361372812

20:18 <GitHub86> [openocd] jordens pushed 1 new commit to master: https://github.com/m-labs/openocd/commit/9f8c46a7a01161deaa615bd097606a6160c587c6

20:18 <GitHub86> openocd/master 9f8c46a Robert Jordens: tcl/fpga/xilinx-xadc.cfg: add support for XADC...

20:18 <GitHub50> [artiq] marmeladapk commented on issue #854: @sbourdeauducq I flashed it now:... https://github.com/m-labs/artiq/issues/854#issuecomment-361372812

20:20 <GitHub24> [artiq] marmeladapk commented on issue #854: @sbourdeauducq I flashed it now:... https://github.com/m-labs/artiq/issues/854#issuecomment-361372812

21:22 <GitHub169> [artiq] marmeladapk commented on issue #908: I'm using 2017.4 and I also got this issue, though with build from 25.01. I'm currently building against 0edc34a, will update when it finishes. https://github.com/m-labs/artiq/issues/908#issuecomment-361390702

22:03 <GitHub178> [artiq] marmeladapk commented on issue #908: ```... https://github.com/m-labs/artiq/issues/908#issuecomment-361402430

22:32 <GitHub50> [artiq] jbqubit opened issue #911: building sayma_amc: no rule for libunwind-bare.a https://github.com/m-labs/artiq/issues/911

22:40 <GitHub123> [artiq] jbqubit commented on issue #895: @TheCakeIsAPi Please try again. Would like to close this Issue. https://github.com/m-labs/artiq/issues/895#issuecomment-361411986

22:50 <GitHub34> [artiq] philipkent commented on issue #888: @dhslichter we needed to expanded the FIFO depth to prevent underflow errors from occurring during the Raman cooling sequence. I'm working on more thorough tests using ARTIQ 3.1 and DMA but the expanded FIFO depth still seemed to be necessary on 3.1 after a first test, even when we used recorded DMA sequences for Raman cooling. The FIFO depth of 1024 was the first modifica

23:24 <GitHub99> [artiq] whitequark commented on issue #911: You need to update misoc. https://github.com/m-labs/artiq/issues/911#issuecomment-361422138

23:26 <GitHub20> [artiq] jbqubit commented on issue #898: > gateware_bit = artifact_path("gateware", "top.bit")... https://github.com/m-labs/artiq/issues/898#issuecomment-361422570

23:53 <GitHub126> [smoltcp] whitequark commented on issue #136: Put each packet into an individual Vec, then put all of them into VecDeque. https://github.com/m-labs/smoltcp/pull/136#issuecomment-361427874