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
<GitHub> [artiq] cjbe opened pull request #680: language: add "W" (Watt) to units (master...watt-unit) https://github.com/m-labs/artiq/pull/680
<sb0> whitequark, speaking of glitches, you get the copy loop into the instruction cache (never heard of this I$$ abbreviation) but how do you get it out?
<GitHub> [artiq] sbourdeauducq closed pull request #680: language: add "W" (Watt) to units (master...watt-unit) https://github.com/m-labs/artiq/pull/680
<bb-m-labs> build #1380 of artiq is complete: Failure [failed conda_create] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1380 blamelist: Chris Ballance <chris.ballance@physics.ox.ac.uk>
rohitksingh has joined #m-labs
rohitksingh1 has joined #m-labs
rohitksingh has quit [Ping timeout: 240 seconds]
rohitksingh has joined #m-labs
rohitksingh1 has quit [Ping timeout: 260 seconds]
rohitksingh has quit [Ping timeout: 260 seconds]
<whitequark> sb0: it's actually I$ but the $ is escaped in inline assembly
<whitequark> sb0: anyway, crt0 does that
sb0 has quit [Quit: Leaving]
<GitHub1> [smoltcp] little-dude opened pull request #11: implement IntoIterator for SliceCache (master...master) https://git.io/vyRvR
kuldeep has quit [Remote host closed the connection]
kuldeep has joined #m-labs
AndChat|326081 has quit [Quit: Bye]
AndChat326081 has joined #m-labs
<GitHub47> [smoltcp] whitequark pushed 1 new commit to master: https://git.io/vyRUj
<GitHub47> smoltcp/master bd9a6bf Corentin Henry: arp: use valid unicast ip addresses for tests
<GitHub82> [smoltcp] whitequark pushed 1 new commit to master: https://git.io/vyRTv
<GitHub82> smoltcp/master eeaf7b6 Corentin Henry: arp: increment lru when inserting a new entry
<travis-ci> m-labs/smoltcp#91 (master - bd9a6bf : Corentin Henry): The build passed.
<travis-ci> m-labs/smoltcp#92 (master - eeaf7b6 : Corentin Henry): The build passed.
hedgeberg is now known as hedgeberg|away
rohitksingh has joined #m-labs
mumptai has joined #m-labs
<GitHub106> [smoltcp] whitequark pushed 1 new commit to master: https://git.io/vyRkc
<GitHub106> smoltcp/master 4e364d8 whitequark: Trace eviction and fill in SliceArpCache.
<travis-ci> m-labs/smoltcp#93 (master - 4e364d8 : whitequark): The build passed.
<GitHub148> [smoltcp] whitequark pushed 1 new commit to master: https://git.io/vyRk6
<GitHub148> smoltcp/master 15cf0cc whitequark: Don't put non-unicast (IP or Ethernet) addresses into ARP cache....
<travis-ci> m-labs/smoltcp#94 (master - 15cf0cc : whitequark): The build passed.
AndChat|326081 has joined #m-labs
AndChat326081 has quit [Ping timeout: 260 seconds]
AndChat|326081 has quit [Quit: Bye]
AndChat326081 has joined #m-labs
rohitksingh has quit [Ping timeout: 246 seconds]
AndChat|326081 has joined #m-labs
AndChat|326081 has quit [Client Quit]
AndChat|326081 has joined #m-labs
AndChat326081 has quit [Read error: Connection reset by peer]
FabM has quit [Ping timeout: 246 seconds]
kuldeep has quit [Remote host closed the connection]
kuldeep_ has joined #m-labs
AndChat326081 has joined #m-labs
FabM has joined #m-labs
AndChat|326081 has quit [Ping timeout: 240 seconds]
FabM has quit [Ping timeout: 246 seconds]
cedric has quit [Ping timeout: 260 seconds]
sandeepkr has quit [Ping timeout: 240 seconds]
cedric has joined #m-labs
cedric has joined #m-labs
cedric has quit [Changing host]
sandeepkr has joined #m-labs
FabM has joined #m-labs
rohitksingh has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
FabM has quit [Ping timeout: 258 seconds]
FabM has joined #m-labs
AndChat326081 has quit [Ping timeout: 240 seconds]
AndChat326081 has joined #m-labs
AndChat326081 has quit [Ping timeout: 256 seconds]
AndChat326081 has joined #m-labs
mumptai has quit [Remote host closed the connection]
kuldeep_ has quit [Read error: Connection reset by peer]
kuldeep_ has joined #m-labs
kuldeep_ has quit [Remote host closed the connection]
kuldeep_ has joined #m-labs
<GitHub147> [smoltcp] whitequark pushed 1 new commit to master: https://git.io/vyRBi
<GitHub147> smoltcp/master 293ea51 whitequark: Improve handling of TCP ACK packets in FIN-* states....
<travis-ci> m-labs/smoltcp#95 (master - 293ea51 : whitequark): The build passed.
sandeepkr has quit [Ping timeout: 268 seconds]
<GitHub88> [smoltcp] whitequark pushed 3 new commits to master: https://git.io/vyRrS
<GitHub88> smoltcp/master 1622244 whitequark: Clamp TCP receive window to MSS multiplied by maximum burst size....
<GitHub88> smoltcp/master 7381e7f whitequark: fn Device::mtu() -> usize → Device::limits() -> DeviceLimits
<GitHub88> smoltcp/master 1874549 whitequark: Bump version....
<travis-ci> m-labs/smoltcp#96 (master - 1622244 : whitequark): The build passed.
<whitequark> sb0: I made smoltcp quite a bit more robust when receiving large amounts of data
<bb-m-labs> build #451 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/451
AndChat326081 has quit [Quit: Bye]
AndChat326081 has joined #m-labs
AndChat326081 has quit [Ping timeout: 260 seconds]
AndChat326081 has joined #m-labs
<bb-m-labs> build #433 of artiq-win64-test is complete: Failure [failed python_unittest] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/433 blamelist: whitequark <whitequark@whitequark.org>
<bb-m-labs> build #1381 of artiq is complete: Failure [failed] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1381 blamelist: whitequark <whitequark@whitequark.org>
<whitequark> sb0: now I can also swap the firmware in 12s
<whitequark> and not "an eternity" like before (somewhere around 70s)
<whitequark> no more reading reddit until the firmware loads, finally
FabM has quit [Quit: ChatZilla 0.9.93 [Firefox 45.7.0/20170125001729]]
<whitequark> if I enable incremental compilation in cargo, I can rebuild and swap a firmware in just 25s
FabM has joined #m-labs
sb0 has joined #m-labs
AndChat326081 has quit [Quit: Bye]
AndChat326081 has joined #m-labs
AndChat|326081 has joined #m-labs
AndChat326081 has quit [Ping timeout: 258 seconds]
AndChat|326081 has quit [Quit: Bye]
AndChat326081 has joined #m-labs
AndChat|326081 has joined #m-labs
AndChat326081 has quit [Ping timeout: 258 seconds]
<whitequark> sb0: I want some solution for this DMA reset issue
<whitequark> I see two options
<whitequark> 1) also add the limit, like the analyzer DMA does
<whitequark> 2) add an explict reset to the core
<whitequark> I don't know how to do 2) in migen (do I need an additional clock domain?) and 1) sounds like a lot of effort
<whitequark> possibly introducing more bugs in the process, that is.
<whitequark> (swap the firmware) wow, if I do it on a decent uplink, that's 1.5s
<whitequark> now *this* is actually convenient
<cr1901_modern> what's wrong with using ResetSignal() and gating that with a manual reset?
<whitequark> I'm not sure how to propagate that through the implicit relationships migen builds
<whitequark> and only into the places where I need that
<whitequark> this should go into the migen FAQ once someone figures it
<cr1901_modern> IF you manually specify ClockDomains() in your design, reset signal is tied to 0 if you're not connecting it to anything IIRC.
<whitequark> hm, I found a work-around for doing this quickly
<whitequark> I reset an FPGA, let it load from flash then hotswap
kuldeep_ has quit [Remote host closed the connection]
kuldeep_ has joined #m-labs
<sb0> the analyzer dma has a limit because it wraps around, it's a fifo
<sb0> and you want an actual reset. if the DMA core is blocked on a RTIO FIFO that is full with timestamps far in the future, you want to interrupt it
<whitequark> right, an actual reset
<whitequark> okay
<whitequark> sb0: so I tried swapping endianness etc
<whitequark> it's quite interesting
<whitequark> changing the data doesn't do anything
<whitequark> it's nonsense either way, same nonsense on every startup
<whitequark> as far as I see, I can replay the traces several times in one kernel, and that doesn't crash anything
<whitequark> that's regardless of whether they were recorded in this time or the previous time
<whitequark> but if I replay the traces once in one kernel run and another time in another kernel run, I get ~infinite output from the DMA core
<sb0> did you get it to put anything in the analyzer?
<whitequark> it puts two identical nonsensical records into analyzer per DMA record
<sb0> always the same content in the analyzer?
<whitequark> yes
<sb0> and by "DMA record", you mean event? i.e. a playback would contain many of them
<whitequark> yes
<whitequark> it's called a record in the gateware
<sb0> so the number of analyzer events matches the number of dma records?
<whitequark> no
<sb0> doubled?
<whitequark> doubled
<whitequark> let me try slightly different patterns, perhaps
<sb0> and this holds true for different DMA sequences?
<sb0> there is still this rtio_counter weirdness
<sb0> interestingly, the difference between the rtio_counter values seem consistent
<sb0> 24 or 64
<sb0> except for the 4th to 5th message, on both traces
<whitequark> that's because 5th message is the start of 2nd replay
<whitequark> sb0: that's bizarre
<whitequark> it looks like the number of analyzer messages doesn't depend on the DMA trace length
<whitequark> well, no.
<whitequark> if I push four DMA records there, there are still the same four OutputMessages
<whitequark> if I push six, there are *none*
<whitequark> and, it doesn't crash the core
<whitequark> I can replay those six as many times as I want
<whitequark> same with five...
<whitequark> no, correction
<whitequark> three DMA records result in four OutputMessages
<whitequark> four DMA records result in no OutputMessages and a crash
<whitequark> five result in no OutputMessages and no crash
<whitequark> it seems like this behavior changes around SDRAM word size
<sb0> do you still have crashes after changing the wishbone arbiter behavior?
<whitequark> it's not a SoC crash
<whitequark> it's a DMA core crash, and yes, I can recover the SoC afterwards
<whitequark> oh, that's interesting
<sb0> and this, only after you made the arbiter change? before that it was a full SoC crash?
<whitequark> with four records, the core hangs but doesn't output any messages
<sb0> and note that your coreboot tool doesn't reset the DMA core.
<whitequark> I *think* it was a full SoC crash
<whitequark> at least I haven't encountered any full SoC crash after the arbiter change
<whitequark> and before, those were pretty common
<whitequark> as for coreboot, yes
<whitequark> I use $ artiq_devtool reset connect (another terminal)$ artiq_devtool build hotswap
<GitHub> [artiq] whitequark pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/b391598c879bd2c2cded53984f6c3dbf8cf900ec
<GitHub> artiq/master b391598 whitequark: artiq_devtool: add reset action.
<cr1901_modern> A core crashes by adding extra Records?
<sb0> ah, so you're using the runtime as "bootloader" :)
<sb0> what was wrong with TFTP?
<sb0> no UDP over SSH?
<whitequark> sb0: too many moving parts
<whitequark> I have to first make it netboot
<whitequark> then I have to upload the runtime *twice*
<whitequark> once to lab. another time to kc705.
<whitequark> ideally I would like to have ipv6, a separate core device management thread for logs and hotswap, and just get rid of `artiq_devtool connect` completely
<whitequark> and have it reboot with only the management thread enabled in case it crashes
<whitequark> sb0: also bios does some weird thing with network configuration
<whitequark> I think it's hardcoded?
<whitequark> I'm not even sure how that's supposed to work
<whitequark> okay, let me get to somewhere quieter and I'm just going to review the gateware
<whitequark> there's clearly some gateware bug that makes it read garbage
rohitksingh has joined #m-labs
rohitksingh has quit [Client Quit]
<bb-m-labs> build #452 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/452
<bb-m-labs> build #1382 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1382 blamelist: whitequark <whitequark@whitequark.org>
<sb0> test_rpc_timing
<whitequark> sb0: that's expected
<whitequark> the log level is set to DEBUG
<whitequark> having the log level set in persistent config has this sort of unfortunate consequence. hm.
rjo has quit [Read error: Connection reset by peer]
rjo has joined #m-labs
bb-m-labs has quit [Quit: buildmaster reconfigured: bot disconnecting]
bb-m-labs has joined #m-labs
<GitHub103> [buildbot-config] whitequark pushed 1 new commit to master: https://git.io/vy0cS
<GitHub103> buildbot-config/master d31fa2b whitequark: Set log level to INFO before running tests.
<whitequark> bb-m-labs: force build artiq
<bb-m-labs> build #1383 forced
<bb-m-labs> I'll give a shout when the build finishes
kuldeep_ has quit [Remote host closed the connection]
kuldeep_ has joined #m-labs
<bb-m-labs> build #453 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/453
<bb-m-labs> build #1383 of artiq is complete: Failure [failed artiq_corelog] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1383
sandeepkr has joined #m-labs
bb-m-labs has quit [Quit: buildmaster reconfigured: bot disconnecting]
bb-m-labs has joined #m-labs
<GitHub18> [buildbot-config] whitequark pushed 1 new commit to master: https://git.io/vy0zo
<GitHub18> buildbot-config/master 68aff8e whitequark: Use correct workdir for artiq_corelog step.
<whitequark> bb-m-labs: force build artiq
<bb-m-labs> build #1384 forced
<bb-m-labs> I'll give a shout when the build finishes
AndChat|326081 has quit [Quit: Bye]
AndChat326081 has joined #m-labs
<bb-m-labs> build #454 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/454
<bb-m-labs> build #1384 of artiq is complete: Failure [failed artiq_corelog] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1384
bb-m-labs has quit [Quit: buildmaster reconfigured: bot disconnecting]
bb-m-labs has joined #m-labs
<GitHub122> [buildbot-config] whitequark pushed 1 new commit to master: https://git.io/vy0ry
<GitHub122> buildbot-config/master d08783b whitequark: Fix path screwup.
AndChat|326081 has joined #m-labs
AndChat326081 has quit [Ping timeout: 258 seconds]
Gurty has quit [Read error: Connection reset by peer]
<whitequark> sb0: sure enough if base_address is not 0 then tests don't pass
Gurty has joined #m-labs
<whitequark> sb0: ah no
<whitequark> I misunderstood the arguments to wishbone.SRAM
sandeepkr has quit [Ping timeout: 240 seconds]
sandeepkr has joined #m-labs
<whitequark> sb0: so what I'm doing is I'm submitting this data:
<whitequark> as you can see no zeroes
<whitequark> this is what I reliably get through the analyzer:
<whitequark> OutputMessage(channel=0, timestamp=0, rtio_counter=1117856969088, address=0, data=0)
<whitequark> (that's it, a single message)
<whitequark> sb0: hm, I have an idea of what might be happening
mumptai has joined #m-labs
<whitequark> aha, finally something useful!
<whitequark> scratch that, it's not useful.
<whitequark> I give up.
<whitequark> the DMA core clearly is influenced by the incoming data in some way, and is seemingly deterministic.
<whitequark> but that's all I can say. whatever transformation it performs is not guessable.
<whitequark> it does seem to read from the correct address, so WishboneReader/DmaReader seem to work
<whitequark> the slicer seems to be the most likely culprit?
<whitequark> why does a slicer synthesize a 256x1128 (!) ROM?!
<whitequark> and it goes to LUT, of course
sandeepkr has quit [Ping timeout: 246 seconds]
AndChat|326081 has quit [Quit: Bye]
AndChat326081 has joined #m-labs
AndChat|326081 has joined #m-labs
AndChat326081 has quit [Ping timeout: 240 seconds]
mumptai has quit [Quit: Verlassend]
zumbi has quit [Ping timeout: 260 seconds]
zumbi has joined #m-labs
acathla has quit [Ping timeout: 268 seconds]
acathla has joined #m-labs
acathla has quit [Changing host]
acathla has joined #m-labs
<cr1901_modern> "and it goes to LUT, of course" <-- one of the reasons I can't wait till Xilinx is RE'd is so I can figure out why the synthesizer does stupid shit like this when I have block RAM left over
<cr1901_modern> erm, I said that wrong... I mean open source PAR for Xilinx*