sb0 changed the topic of #m-labs to: ARTIQ, Migen, MiSoC, Mixxeo & other M-Labs projects :: fka #milkymist :: Logs http://irclog.whitequark.org/m-labs
rohitksingh has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
_whitelogger has joined #m-labs
<sb0> _florent_, how are things going with the sayma cards?
sb0 has quit [Quit: Leaving]
rohitksingh_work has joined #m-labs
mntng has joined #m-labs
mntng has quit [Client Quit]
froggytoad has quit [Ping timeout: 260 seconds]
<_florent_> sb0: fine, both are working, low level link between them is also almost working, I'm creating modules to calibrate things automatically
<_florent_> sb0: I expect that to work today, then I'll just have to put the etherbone module on top of that
sb0 has joined #m-labs
rohitksingh_work has quit [Read error: Connection reset by peer]
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
<GitHub0> [artiq] dhslichter commented on issue #778: My sense is that SRTIO as proposed, or some variant thereof, is probably where things will need to go in the long term, but that the near-term cost and delays and debugging from implementing it appear to me (and to the others who have commented above) to be problematic relative to the "hack" fix of DRTIO with "only allocate space on the master for the DRTIO channels that are actually used", as described by
<GitHub13> [artiq] dhslichter opened pull request #802: Update README links (master...patch-1) https://github.com/m-labs/artiq/pull/802
<GitHub52> [artiq] sbourdeauducq closed pull request #802: Update README links (master...patch-1) https://github.com/m-labs/artiq/pull/802
<GitHub67> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/61b0ad1982f3d292e75cce714516e1559f02709d
<GitHub67> artiq/master 61b0ad1 dhslichter: Update README links
<GitHub150> [artiq] sbourdeauducq commented on issue #802: Thanks https://github.com/m-labs/artiq/pull/802#issuecomment-317043463
<GitHub11> [artiq] sbourdeauducq pushed 1 new commit to release-2: https://github.com/m-labs/artiq/commit/7faa7278471892b385fb2d12f6202076223580f4
<GitHub11> artiq/release-2 7faa727 dhslichter: Update README links
stekern has quit [Read error: Connection reset by peer]
stekern has joined #m-labs
stekern has quit [Read error: Connection reset by peer]
<bb-m-labs> build #731 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/731
stekern has joined #m-labs
<GitHub18> [artiq] sbourdeauducq pushed 1 new commit to release-2: https://github.com/m-labs/artiq/commit/6fa2dca4023afb41394e9fc4294f6d710ddb38b8
<GitHub18> artiq/release-2 6fa2dca Sebastien Bourdeauducq: synchronize introduction.rst with README
<GitHub182> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/7eed4e7b6c42ad618b10a74bd58192e7b62894c4
<GitHub182> artiq/master 7eed4e7 Sebastien Bourdeauducq: synchronize introduction.rst with README
<GitHub141> [artiq] jordens commented on issue #778: @dleibrandt I'd estimate around 8-16 SRTIO FIFOs. Making all of them large enough to handle the max backlog does not sound too restrictive if one considers that it saves a lot of unused memory from "current RTIO". Also is enlarging the FIFOs just a workaround for a small sustained event rate? If yes, then avoiding (this) SRTIO design because it makes a work around for another bottle neck harder to implemen
<bb-m-labs> build #535 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/535
<bb-m-labs> build #1632 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1632
<bb-m-labs> build #732 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/732
<bb-m-labs> build #536 of artiq-win64-test is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/536
<bb-m-labs> build #1633 of artiq is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1633
<GitHub199> [artiq] dhslichter commented on issue #778: @jordens ack. Sounds like we should keep thinking about how to implement SRTIO in a good way and hammer out a good initial design spec in the near term that will handle the various issues discussed above, even as hacks are applied to the current DRTIO to keep it going. https://github.com/m-labs/artiq/issues/778#issuecomment-317097434
mumptai has joined #m-labs
<GitHub140> [artiq] dleibrandt commented on issue #778: > Also is enlarging the FIFOs just a workaround for a small sustained event rate? If yes, then avoiding (this) SRTIO design because it makes a work around for another bottle neck harder to implement is a priority inversion. If that work around is needed and ends up hard to do with SRTIO, one should work hard on increasing the sustained event rate (any or a combination of the options that are floating ar
mumptai has quit [Remote host closed the connection]