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
fengling has joined #m-labs
sb0 has quit [Quit: Leaving]
rohitksingh has joined #m-labs
<mithro> cyrozap: re: UART over JTAG -- OMG, OMG! If you get that working, I'll send you a pizza/beer!
<mithro> cyrozap: btw, who are you and what are you doing with misoc / migen?
Gurty has quit [Ping timeout: 246 seconds]
rohitksingh has quit [Ping timeout: 246 seconds]
Gurty has joined #m-labs
FabM has joined #m-labs
rohitksingh has joined #m-labs
kyak has quit []
kyak has joined #m-labs
rohitksingh has quit [Ping timeout: 260 seconds]
<whitequark> rjo: ping
<rjo> whitequark: pong
<whitequark> oh, nevermind, the stupid backplane jtag problem hits again
<whitequark> do I just issue the load command?
<whitequark> via artiq_flash I mean. and wait the board to boot.
<rjo> whitequark: artiq_flash -t kc705 -d path_to_top.bit load
<whitequark> huh wtf
<whitequark> Memtest failed: 131332/532736 words incorrect
<whitequark> Memory initialization failed
<whitequark> oh
<whitequark> that was intermittent.
<rjo> is the fan ok?
<whitequark> the fan is running yes
<whitequark> spinning
<whitequark> rjo: btw would you share your scope interfacing code?
<whitequark> the layout seemed quite elegant to me
<rjo> whitequark: it's ~rj/src/artiq/run/capture.py
<rjo> it's a hack
<whitequark> oh
<whitequark> ah well. yes. less useful than I expected.
<whitequark> still I'm quite pleased that you were able to use this scope remotely. huge timesaver.
<whitequark> rjo: hm, no, I was wrong, that memory initialization problem is not intermittent
<whitequark> in fact now I get it every time
<rjo> whitequark: new gateware?
<whitequark> define 'new'?
<whitequark> I'm trying to load a patched gateware, yes
<rjo> iirc there were some changes in the ram stuff recently (last few days)
<rjo> patched?
<whitequark> hm
<rjo> _florent_: ^
<whitequark> yes, with all the TTLs as TTLInOut
<rjo> try an older misoc.
ylamarre has joined #m-labs
<whitequark> FYI I've flashed a gateware where all TTLs are TTLInOut
<whitequark> rjo: can you look at test_loopback?
<whitequark> I get this:
<whitequark> self.assertLess(rtt, 50*ns)
<whitequark> AssertionError: 5.0000000000000004e-08 not less than 5.0000000000000004e-08
<whitequark> this seems very suspicious.
<whitequark> is 50ns one RTIO clock period?
<rjo> no. its 6.25
<rjo> will have a look
<rjo> how are they connected?
<whitequark> a wire.
<rjo> backplane?
<whitequark> yeah
<rjo> how long is the wire?
<rjo> 1 ns?
<whitequark> no, it's a tiny breadboard jumper
<whitequark> 160ps?
<whitequark> not including breadboard itself
<rjo> let me calculate the expected delay.
<rjo> but 50ns sounds possible.
<rjo> could you just for fun try a cable that is at least 1ns longer?
<rjo> ah
<rjo> i know
<rjo> maybe the test was last run when that ttlout was still a simple TTLout. the simple TTLouts have less latency AFAIK.
<rjo> and/or the same for the TTLInOUt
<whitequark> actually it used to use loop_inout
<rjo> same pin?
<whitequark> yes
<whitequark> but I'm curious about the exact 50ns value
<rjo> well. you should try a slightly modified version of the test where they are the same.
<whitequark> that's not possible anymore
<whitequark> because of with parallel / with interleaving issue
<rjo> pretty sure that it is 48ns latency from the PHYs (and the SERDESes) and then 2 ns from the package, board, connector, backplane, jumper.
<rjo> you manually inline the gate_rising, right?
<whitequark> I don't inline anything here, I use with parallel
<whitequark> the new one
<whitequark> I could inline it perhas
<rjo> that's why i say you manually inline it.
<rjo> but the code looks fine. i would do the two things suggested to make you comfortable.
<whitequark> yep, I used a longer wire and here it is 2ns more
<rjo> let me estimate the latency
<whitequark> actually, how come it's 2ns more?
<whitequark> if the RTIO clock is 6.25ns
<rjo> the rtio clock is 8ns. 50ns/8ns=6.25
<rjo> cycles
<whitequark> I mean--it used to return 50ns, now it returns 52ns
<whitequark> that makes no sense
<rjo> i count 6 or 7 cycles rtt depending on details i am too lazy to confirm.
<whitequark> so with a short wire the rtt is 50mu with the long one it's 52mu
<whitequark> 1mu=1ns?
<whitequark> does rtio do 8 acquisitions per clock cycle?
<whitequark> oh. those are 10Gbps transceivers
ylamarre has quit [Ping timeout: 260 seconds]
<rjo> yes.
<rjo> 1ns = 1mu
<rjo> one coarse RTIO cycles is 8ns = 8mu.
<rjo> 1GBps
ylamarre has joined #m-labs
<GitHub34> [misoc] whitequark pushed 1 new commit to master: https://git.io/v2j9m
<GitHub34> misoc/master 3cf5dfe whitequark: flterm: fix typo: --kernel-adr → --kernel-addr.
<rjo> whitequark: 50ns is fine if you intend to run that way. other backplanes will measure wildly different things. i would say: decide on a reproducible wiring for that test, describe how you expect loop_in and loop_out to be connected in the device_db.pyon for the test, then make the test rtt value bounded by a few ns around the delay that you measure reproducibly.
<rjo> if you want to browse through old runs of the unittests on kc705 and compare: https://people.phys.ethz.ch/~robertjo/artiq-ci/
<_florent_> whitequark, rjo: the changes from the last days on the SDRAM are not impacting ARTIQ (SoCs with LASMICON were not compiling since refactoring)
<_florent_> the others changes are related to ethernet
<_florent_> I just tested MiniSoC here on my KC705 and memtest seems fine
<whitequark> this seems to be the problem with one specific gateware I compiled
<whitequark> dunno why
<whitequark> maybe some of the nondeterministic parts of layout got fucked?
<_florent_> and now it's fine with another compilation?
<whitequark> I didn't try another compilation
<whitequark> takes too much time
<rjo> _florent_: ack
<_florent_> ok, if it's still failing I'll do the test here and will fix it. Please ping me if it's the case.
<whitequark> rjo: I found your cache-related crash
<GitHub84> [artiq] whitequark pushed 2 new commits to master: https://git.io/v2jh7
<GitHub84> artiq/master 9ffa8cb whitequark: test_loopback: bump RTT limit to 60ns....
<GitHub84> artiq/master 739568f whitequark: runtime: fix sloppy memory management in cache_put.
<whitequark> ok. the testsuite reliably succeeds now, with the exception of one test, test_time_keeps_running.
<rjo> whitequark: where does it fail?
<rjo> whitequark: that test should not look at now_mu() but at the value of the timestamp counter. rtio_get_counter() should be exposed
<rjo> or break_realtime() and then now_mu() as a quick fix.
<rjo> oh. it is exposed. self.core.get_rtio_counter_mu() could use a docstring
ylamarre has quit [Ping timeout: 276 seconds]
ylamarre has joined #m-labs
bb-m-labs_ has quit [Quit: buildmaster reconfigured: bot disconnecting]
bb-m-labs has joined #m-labs
bb-m-labs has quit [Client Quit]
<GitHub70> [buildbot-config] whitequark pushed 2 new commits to master: https://github.com/m-labs/buildbot-config/compare/10e27741bfc3...3b4ebf4908e6
<GitHub70> buildbot-config/master 1a298c6 whitequark: Run hardware test as a part of the build.
<GitHub70> buildbot-config/master 3b4ebf4 whitequark: Ensure local changes are pushed before deploy.
bb-m-labs has joined #m-labs
<GitHub34> [buildbot-config] whitequark force-pushed master from 3b4ebf4 to 3a60ff1: https://github.com/m-labs/buildbot-config/commits/master
<GitHub34> buildbot-config/master 3a60ff1 whitequark: Run hardware test as a part of the build.
<GitHub34> buildbot-config/master 7612302 whitequark: Ensure local changes are pushed before deploy.
<bb-m-labs> build #345 of artiq is complete: Failure [failed python_unittest] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/345
<whitequark> there's a stupid circular dependency between artiq main package and board packages.
<whitequark> hm
<whitequark> ah well maybe not
bb-m-labs has quit [Quit: buildmaster reconfigured: bot disconnecting]
<GitHub133> [buildbot-config] whitequark pushed 1 new commit to master: https://github.com/m-labs/buildbot-config/commit/a859d4c095d3006b0c4b278dd055229865111bbf
<GitHub133> buildbot-config/master a859d4c whitequark: Flash the test board before testing.
bb-m-labs has joined #m-labs
<GitHub35> [buildbot-config] whitequark force-pushed master from a859d4c to c605691: https://github.com/m-labs/buildbot-config/commits/master
<GitHub35> buildbot-config/master c605691 whitequark: Flash the test board before testing.
<whitequark> bb-m-labs: force build artiq
<bb-m-labs> The build has been queued, I'll give a shout when it starts
<bb-m-labs> build #346 forced
<bb-m-labs> I'll give a shout when the build finishes