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
<sb0>
the latency compensation is just adding/subtracting a number from the timestamp values of the rtio syscalls. i think it is easily added to the current drivers, and if it's zero (when latency compensation is not needed), the compiler should be able to optimize it away
fengling has joined #m-labs
nicksydney has joined #m-labs
nicksydney has quit [Ping timeout: 244 seconds]
nicksydney has joined #m-labs
<GitHub4>
[artiq] sbourdeauducq pushed 4 new commits to master: http://git.io/vkjON
<GitHub4>
artiq/master 448ba04 Sebastien Bourdeauducq: Merge branch 'master' of github.com:m-labs/artiq
<sb0>
ysionneau, simulating it will be difficult anyway
<sb0>
ysionneau, check that it gets the correct words, and that the leading bit counter works on inputs
<sb0>
(i.e. simulate the synchronous part)
<ysionneau>
secure ips can be simulated with ISim I think
<sb0>
just don't spend time on that
<ysionneau>
if I don't simulate the I/OSERDESE2 part, then I will not know whether I correctly use it or not
<sb0>
a synchronous (single clock) test bench that has rtlink on one end and iserdes and oserdes words on the other end is fine
<ysionneau>
all right
<sb0>
most of the issues with the serdes are 1) clocking them, which simulations won't find 2) order of the bits, which is easy to determine and fix if wrong 3) poorly documented bitslip feature which you won't need
<ysionneau>
ok
<ysionneau>
since I never used those I was a bit freaking out about just instanciating them without ever testing
<ysionneau>
but ok I'll test the remaining parts
<sb0>
and also, dealing with the io routing restrictions, again not detected in simulations but ISE will print you somewhat relevant error messages
<ysionneau>
I'll keep an eye on console errors/warnings while synthesizing
<whitequark>
sb0: a = 2,3
<GitHub159>
[artiq] whitequark pushed 1 new commit to new-py2llvm: http://git.io/vIf35
<GitHub159>
artiq/new-py2llvm 6c3b5a9 whitequark: Use proper format function.
antgreen has joined #m-labs
travis-ci has joined #m-labs
<travis-ci>
m-labs/artiq#186 (new-py2llvm - 6c3b5a9 : whitequark): The build is still failing.
<sb0>
python and signals is a complete clusterfuck
<ysionneau>
and even without my try/finally refactor, for instance if I checkout 78f92682772293445af1e3f9e55cbf7f8784b158 I get this: http://pastebin.com/gTC8SnGY
<ysionneau>
and the communicate() makes both those issues go away
<sb0>
yes, but communicate() can use lots of memory for a similar reason
<sb0>
there's asyncio_process_wait_timeout in artiq.tools
<ysionneau>
all right, asyncio_process_wait_timeout after the self.process.kill() fixes the issue
<sb0>
I'm committing the change rn
<ysionneau>
ok
<sb0>
bah, no, there's still another buig
<sb0>
*bug
<sb0>
RuntimeError: read() called while another coroutine is already waiting for incoming data
<ysionneau>
when doing python3 -m unittest worker.py ?
<sb0>
no, that's from watchdog.py. always a good idea to run all other tests...
<sb0>
hmm just running worker.py also has problems
<sb0>
blergh, another asyncio bug
<ysionneau>
(I don't have watchdog.py in artiq tree :o)
<sb0>
if you have a coroutine that does stream.read(), cancel it while it does that, then if another coroutine tries to read afterwards it causes this runtime error
<ysionneau>
arg :/
<GitHub36>
[artiq] sbourdeauducq pushed 1 new commit to master: http://git.io/vIJUr
<GitHub36>
artiq/master a6a4765 Sebastien Bourdeauducq: worker: wait for process termination...