01:02 <GitHub128> [smoltcp] podhrmic commented on issue #52: After looking at [RFC 815](https://tools.ietf.org/html/rfc815) I have some ideas.... https://github.com/m-labs/smoltcp/issues/52#issuecomment-371987907

01:21 <GitHub89> [smoltcp] whitequark commented on issue #52: Sounds reasonable, though I think `FragmentedPacket::rx_buffer` shouldn't be a `RingBuffer`. https://github.com/m-labs/smoltcp/issues/52#issuecomment-371989958

01:39 <GitHub164> [smoltcp] podhrmic commented on issue #52: Thanks. It could simply be `ManagedSlice<u8>` to be closer to the example in RFC 815 https://github.com/m-labs/smoltcp/issues/52#issuecomment-371991728

02:36 <sb0> the fan on kasli makes a big difference. temperature dropped >20C

02:36 <sb0> if only there was a nice way of mounting it (also for cleaning and replacement ...)

04:15 <sb0> _florent_, i fixed sayma-3

11:11 <hartytp> _florent_: do you think there is any point playing with the drive strength for the SDRAM?

11:11 <hartytp> might make the eyes a bit nicer?

11:12 <hartytp> (if so, can you remind me what I need to do)

11:12 <hartytp> also, out of curiosity, does the latest build work well on all 3 Sayma you guys have?

11:12 <hartytp> seems you can fix the 1V8 issue by adding 100uF capacitor on the 1V8 output if that's still causing you problems

12:29 <GitHub-m-labs> [artiq] hartytp commented on issue #951: @sbourdeauducq The critical warnings have now gone, as have the timing violations. Thanks!... https://github.com/m-labs/artiq/issues/951#issuecomment-372026148

12:56 <sb0> FYI: I have swapped kasli-1 and kasli-2

12:56 <sb0> kasli-1 is now v1.0 with ethernet on sfp0 and drtio on sfp1

12:56 <sb0> kasli-2 is now v1.1 with drtio on sfp0

13:41 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #951: > WARNING: [Synth 8-6040] Register { driving address of a ROM cannot be packed in BRAM/URAM because of presence of initial value.... https://github.com/m-labs/artiq/issues/951#issuecomment-372030826

14:17 <travis-ci> [rust-managed] whitequark closed pull request #7: Catch insert() on ManagedMap with zero-sized backing store (master...catch-zero-sized-managedmap) https://github.com/m-labs/rust-managed/pull/7

14:19 <travis-ci> m-labs/rust-managed#36 (master - 10d1ba9 : Astro): The build passed.

14:19 <travis-ci> Change view : https://github.com/m-labs/rust-managed/compare/81b54caf4ded...10d1ba9db36f

14:19 <travis-ci> Build details : https://travis-ci.org/m-labs/rust-managed/builds/351703828

14:45 <GitHub-m-labs> [artiq] hartytp commented on issue #951: Hmm...any suggestions how we track that down? Does this only appear on Sayma? Worth a bit of old fashioned comment stuff out until the error goes so we can localize it? Suggestions about where to begin? https://github.com/m-labs/artiq/issues/951#issuecomment-372035192

14:51 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #951: Maybe @jbqubit's Xilinx contacts can look into that one, since this is clearly a Vivado bug.... https://github.com/m-labs/artiq/issues/951#issuecomment-372035638

14:55 <sb0> bb-m-labs, force build misoc

14:55 <bb-m-labs> build forced [ETA 7m30s]

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

14:55 <GitHub-m-labs> [misoc] sbourdeauducq tagged 0.10 at master: https://github.com/m-labs/misoc/commits/0.10

14:59 <GitHub-m-labs> [artiq] sbourdeauducq pushed 1 new commit to release-3: https://github.com/m-labs/artiq/commit/59fdb32b7bb43504f9aaa701cd990ee3fbb37baf

14:59 <GitHub-m-labs> artiq/release-3 59fdb32 Sebastien Bourdeauducq: conda: bump misoc

15:00 <bb-m-labs> build #412 of misoc is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/misoc/builds/412

15:17 <GitHub-m-labs> [artiq] hartytp commented on issue #951: The garbled output is clearly a vibado bug, but isn't it still pointing at a real gateware issue that we should fix? https://github.com/m-labs/artiq/issues/951#issuecomment-372037367

15:21 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #951: That looks like a minor detail that is sub-optimal; as long as Vivado produces a correct netlist (despite the memory corruption) and it passes timing then it's fine. https://github.com/m-labs/artiq/issues/951#issuecomment-372037676

15:23 <GitHub-m-labs> [artiq] hartytp commented on issue #951: Or is the apparent memory corruption in vivado the only thing that worries you about that message? If so then I agree there isn't much we can do about it. https://github.com/m-labs/artiq/issues/951#issuecomment-372037833

15:24 <GitHub-m-labs> [artiq] hartytp commented on issue #951: Okay. Well if there isn't anything else in the vivado output for sayma which we need to look at further then feel free to close this. https://github.com/m-labs/artiq/issues/951#issuecomment-372037956

15:27 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #951: > Or is the apparent memory corruption in vivado the only thing that worries you about that message?... https://github.com/m-labs/artiq/issues/951#issuecomment-372038165

15:30 <GitHub-m-labs> [artiq] sbourdeauducq closed issue #944: Sayma_AMC with SAWG congestion Level 5 https://github.com/m-labs/artiq/issues/944

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

15:37 <bb-m-labs> build #768 of artiq-win64-test is complete: Warnings [warnings python_unittest] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/768 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>

15:39 <GitHub-m-labs> [artiq] hartytp commented on issue #951: My thinking here is that the sdram issue could be vivado doing sonethibg silly in response to struggling to neet timing on the complex sawg desing. So, tripple checking all the cobstraints and fixing issues like this whuch are upsetting vivado could be a big help even if the warnings aren't directly related to the sdram. https://github.com/m-labs/artiq/issues/951#iss

15:40 <sb0> hartytp, currently which bitstreams work on your board re. sdram?

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

15:41 <sb0> bb-m-labs, force build --branch=release-3 artiq

15:41 <bb-m-labs> build forced [ETA 42m45s]

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

15:46 <GitHub-m-labs> [artiq] sbourdeauducq opened issue #952: kc705-phaser conda build broken on release-3 https://github.com/m-labs/artiq/issues/952

15:49 <sb0> bb-m-labs: force build --props=package=artiq-board,artiq_target=kc705,artiq_variant=nist_qc2 --branch=release-3 artiq-board

15:50 <sb0> bb-m-labs: force build --props=package=artiq-board,artiq_target=kc705,artiq_variant=nist_qc2 --branch=release-3 artiq-board

15:50 <bb-m-labs> The build has been queued, I'll give a shout when it starts

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

16:12 <bb-m-labs> build forced [ETA 24m03s]

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

16:12 <bb-m-labs> build #2172 of artiq is complete: Failure [failed conda_install] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2172

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

16:54 <sb0> bb-m-labs: force build --props=package=artiq-board,artiq_target=kc705,artiq_variant=nist_clock --branch=release-3 artiq-board

16:54 <bb-m-labs> build forced [ETA 26m01s]

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

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

18:10 <GitHub52> [smoltcp] astro commented on pull request #178 480ff97: I would really like to keep IPv4 and IPv6 mcast groups in separate maps.... https://github.com/m-labs/smoltcp/pull/178#discussion_r173629943

18:16 <GitHub184> [smoltcp] dlrobertson commented on pull request #178 480ff97: I would still prefer that we have one map, but I can be okay with separate maps and I don't think it should keep this PR from getting merged. https://github.com/m-labs/smoltcp/pull/178#discussion_r173630130