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
<GitHub84> [artiq] sbourdeauducq commented on issue #636: > fewer registers (merge address and data)... https://git.io/v1n2C
<GitHub17> [artiq] sbourdeauducq commented on issue #636: > maybe IRQs can be used to handle error conditions and perform submission retrials... https://git.io/v1n2B
<sb0> whitequark, #electrolab sometimes
<whitequark> ok...
<GitHub194> [artiq] sbourdeauducq pushed 1 new commit to phaser2: https://git.io/v1n66
<GitHub194> artiq/phaser2 3cee269 Sebastien Bourdeauducq: phaser: fix typo
<sb0> rjo, I suggest renaming artiq/gateware/phaser.py to artiq/gateware/ad9154_fmc_ebz.py
<whitequark> +1
* whitequark has just looked at tcp/ip stacks used in minix3 and reactos: lwip and lwip
<whitequark> minix3 is supposedly "high assurance". high assurance my ass.
<sb0> yeah well, it does seem to have users
<whitequark> though it seems to use an extremely old version of lwip (the entire tcp stack is tcp.c 1100 lines long)
<whitequark> maybe that's why it works at all
<whitequark> it doesn't have all the fancy things.
<whitequark> I wish we could use netbsd rump kernels
<sb0> there's a lot of activity on the lwip ml https://lists.nongnu.org/archive/html/lwip-users/2016-11/threads.html
rohitksingh_work has joined #m-labs
MiW has quit [Ping timeout: 260 seconds]
<cr1901_modern> Besides the fact that, netbsd kernel requires an MMU (and last I checked there was little interest in noMMU), what prevents you from using a rump kernel?
<cr1901_modern> It IS an open project tho :P
<sb0> rjo, ok, I think I have a clock distribution eval board somewhere in the lab, I'm going to use it to distribute to two FMCs on both KC705
<sb0> in case it is unsuitable or nonexistent and I need to order one, do you have a particular one to recommend?
_whitelogger has joined #m-labs
sb0 has quit [Quit: Leaving]
sandeepkr has joined #m-labs
FabM has joined #m-labs
sb0 has joined #m-labs
<sb0> whitequark, can you generate another set of si5324 register values for 150MHz?
<sb0> and we'll need 200MHz and 50MHz sets for the Sinara hardware
<sb0> does the Si software just do a brute-force search for good values? maybe we should just rewrite that...
MiW has joined #m-labs
sandeepkr has quit [Ping timeout: 246 seconds]
sandeepkr has joined #m-labs
<rjo> sb0: sounds good. both renaming and clock dist. a passive splitter would also be fine. 3 resistors.
<GitHub17> [artiq] sbourdeauducq pushed 1 new commit to drtio: https://git.io/v1nhj
<GitHub17> artiq/drtio 6353f6d Sebastien Bourdeauducq: drtio: support different configurations and speeds
<sb0> can't find the clock distribution board so I'm going to hack together a passive splitter
<sb0> are you using the kc705s right now, or planning to use them soon?
<rjo> sb0: take it. i am blessed with 30 kBit/s data here. not much fun.
<rjo> kill that one artiq_run and flterm.
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 260 seconds]
<sb0> ghetto splitter and second AD FMC installed on the buildbot kc705
Gurty has quit [Ping timeout: 246 seconds]
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
rohitksingh_work has joined #m-labs
<sb0> wtf is going on... I connected the two KC705s with four SMA cables to run DRTIO on them
<sb0> and it doesn't work, unless I disconnect the slave TXP
<sb0> amazing
<sb0> rjo, you said that connecting differential pairs over SMAs worked fine? =]
Gurty has joined #m-labs
Gurty has joined #m-labs
Gurty has quit [Changing host]
<sb0> I wonder how many crazy problems like that the backplanes will give is
<sb0> *us
<whitequark> cr1901_modern: really? rump kernels require an MMU? that sounds weird
<whitequark> sb0: no idea how it works tbh
<whitequark> but ok
<sb0> okay, so the 10G SFPs are picky (don't work at 1.25G), the SMAs are FUBAR, getting the two-DAC system to work will be fun
sb0 has quit [Quit: Leaving]
<rjo> there is one thing that i whitequark: how do i get the high 32 bits of a int64 as an int32?
<whitequark> int32(x >> 32) ?
<whitequark> LLVM ought to translate that to no code, and if it doesn't it's a bug
rohitksingh_work has quit [Read error: Connection reset by peer]
<rjo> sb0: i know that they should work.
<GitHub32> [artiq] jordens pushed 22 new commits to phaser2: https://git.io/v1c08
<GitHub32> artiq/phaser2 82c651c Robert Jordens: phaser: remove trivial sawg demo
<GitHub32> artiq/phaser2 27160f5 Robert Jordens: phaser: make sysref input only for timing
<GitHub32> artiq/phaser2 7816078 Robert Jordens: phaser/demo: update
kristianpaul has quit [Quit: Lost terminal]
kristianpaul has joined #m-labs
kristianpaul has joined #m-labs
kristianpaul has quit [Changing host]
<rjo> whitequark: how do i get an int64 from a double?
<whitequark> hrm
<whitequark> that actually ought to have worked, but it's inconsistent anyway, so let me modify round to always return int64
<whitequark> first let me see if trunc (fptosi) is optimized to fptosi to smaller type
<rjo> there is some inferencer test that uses that syntax
<whitequark> yes, it's weird that it doesn't work
<whitequark> but the width= syntax was phased out elsewhere anyway
<whitequark> so if LLVM optimizes int32(round(x)) with round always returning int64 correctly, i'm in favor of using that instead
<whitequark> it's simpler too
<whitequark> return value inference is... weird
<rjo> whitequark: or just round32 and round64
<whitequark> then we need to propagate that on the host...
<whitequark> well, I guess we can do that
<whitequark> nope. llvm doesn't merge fptosi+trunc. probably because fptosi to a narrower type than the value is sized is undefined, but trunc isn't
<whitequark> let me think a bit more about it
sb0 has joined #m-labs
<whitequark> rjo: I implemented it in a nicer way.
<GitHub96> [artiq] whitequark pushed 1 new commit to master: https://git.io/v1ciG
<GitHub96> artiq/master 68de724 whitequark: compiler: monomorphize int64(round(x)) to not lose precision....
<whitequark> if you cast something with an indeterminate width integer type to int64 then the entire thing is widened
<whitequark> now back to this tcp madness
<bb-m-labs> build #241 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/241
<bb-m-labs> build #1137 of artiq is complete: Failure [failed python_unittest_1] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1137 blamelist: whitequark <whitequark@whitequark.org>
fengling has quit [Read error: Connection reset by peer]
fengling has joined #m-labs
fengling has quit [*.net *.split]
fengling has joined #m-labs
sb0 has quit [Quit: Leaving]
<rjo> whitequark: one option would have been to behave as python/numpy: round(float) -> float always. let int32(ccccccevijuigbhnenlkgtcbdciulcdcclhlrhgclute)
<rjo> sorry.
<rjo> and int32({float,int?}) -> int32
mumptai has joined #m-labs
<bb-m-labs> build #242 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/242
<bb-m-labs> build #1138 of artiq is complete: Failure [failed python_unittest_1] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1138
<rjo> whitequark: that change broke or uncovered something in the dds code http://buildbot.m-labs.hk/builders/artiq/builds/1138/steps/python_unittest_1/logs/stdio
sandeepkr has quit [Ping timeout: 256 seconds]