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
hedgeberg|away is now known as hedgeberg
<whitequark> sb0: oooooh, I think I know how to potentially speed up RPCs even more
<GitHub> [artiq] whitequark pushed 3 new commits to master: https://github.com/m-labs/artiq/compare/2a81819eb0d3...5d3b00cf1261
<GitHub> artiq/master 5d3b00c whitequark: Implement recording of DMA traces on the core device.
<GitHub> artiq/master 3a1f14c whitequark: compiler: fix overly strict constness analysis....
<GitHub> artiq/master a07bd91 whitequark: firmware: use Rust naming conventions for enum variants.
<whitequark> sb0: [ 46845955us] INFO(runtime::rtio_dma): recorded DMA data: [18, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 100, 0, 0, 0, 0, 0, 1, 18, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 200, 0, 0, 0, 0, 0, 0]
<whitequark> now some questioons about the replay.
<whitequark> it's clear there should be a coredevice attribute per DMA engine (and maybe a separate arbiter but I'm not sure)
<whitequark> hm
<bb-m-labs> build #424 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/424
<bb-m-labs> build #1341 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1341 blamelist: whitequark <whitequark@whitequark.org>
<sb0> there is only one DMA engine for now
<whitequark> okay, so that makes things easier.
<whitequark> what's wait() ?
<whitequark> isn't it just setting now to the end of DDS sequence?
<whitequark> ah ok I see
<whitequark> so it's basically waiting until the DMA engine is actually done
<whitequark> and then presumably checking the error flags
<whitequark> sb0: ok two questions
<whitequark> 1. exactly how do I stop a DMA transfer?
<whitequark> I need this when terminating a kernel, because next kernel may want to overwrite the DMA trace with something else
<whitequark> should I just reset RTIO in this case?
<whitequark> well, no, I can't easily do that because I can't check if DMA is running from the comms CPU
<whitequark> 2. what happens to error statuses if no code ever waits on a DMA transfer?
<whitequark> oh also the API is tentatively as follows:
<whitequark> with self.core_dma.record("foo"): ...
<whitequark> records a trace
<whitequark> self.core_dma.replay("foo")
<whitequark> replays a trace
<whitequark> self.core_dma.erase("foo")
<whitequark> erases a trac
<whitequark> self.core_dma.wait()
<whitequark> waits until whatever trace is currently running finishes
<whitequark> it's not obvious to me how to extend this to multiple engines though.
<whitequark> also. right now, every rtio_output in record mode results in a switch to comms CPU, since that's what manages memory
<whitequark> I assume it's fine
<whitequark> self.core_dma.replay would result in a switch to comms CPU too.
<whitequark> that doens't seem too bad, but if it's bad then the following API can be used:
<whitequark> foo = self.core_dma.trace("foo"); self.core_dma.replay(trace)
<whitequark> the problem with the indirect API is that with it, you can't re-record or erase the trace until the kernel finishes, since the kernel captures a pointer
<whitequark> indirect being trace/replay
<whitequark> with just replay taking a name, this isn't an issue
<whitequark> ah, two more questions
<whitequark> 3. did you eventually connect the DMA core such that analyzer records DMA transactions?
<whitequark> 4. are the records big or little endian?
_florent__ has joined #m-labs
froggyto1d has joined #m-labs
_florent_ has quit [Ping timeout: 252 seconds]
froggytoad has quit [Ping timeout: 252 seconds]
_florent__ is now known as _florent_
cyrozap has quit [Read error: Connection reset by peer]
cyrozap has joined #m-labs
cyrozap has quit [Remote host closed the connection]
cyrozap has joined #m-labs
<whitequark> sb0: ok so I'm going to start implementing playback once you can answer this
rohitksingh has joined #m-labs
Guest42326 has joined #m-labs
Guest42326 has left #m-labs [#m-labs]
hedgeberg is now known as hedgeberg|away
kilae has joined #m-labs
<sb0> whitequark, I think the code should always wait on DMA transfers
<sb0> 3. no, I'm busy with moninj right now
<sb0> I didn't implement stopping DMA (and this is somewhat annoying to implement)
<sb0> whitequark, you should have the DMA driver always wait on the end of the transfer, I don't like this wait() API
<sb0> as for the record format, it's somewhat tricky and it's been a while since I wrote that, you should read the source
<sb0> look at the encode_record() function in the test bench
<sb0> (gateware/test/rtio/test_dma.py)
<sb0> whitequark, for stopping DMA, a sensible CPU interface would be to write 0 to the enable register, and wait until it reads back 0
<sb0> right now the core will ignore the second write and continue until it has written the whole sequence, but then the gateware can be modified later to interrupt the transfer asap when that happens
<sb0> whitequark, patch line 353 of dma.py "If(self.enable.re," -> "If(self.enable.re & self.enable.r," to fix the race condition when doing that
<sb0> otherwise writing 0 to enable may restart the core if it finishes at the wrong moment
felix_ has quit [Ping timeout: 260 seconds]
felix_ has joined #m-labs
rjo has joined #m-labs
<GitHub> [artiq] sbourdeauducq commented on issue #674: Did you establish the PPP link? https://github.com/m-labs/artiq/issues/674#issuecomment-282555654
rohitksingh has quit [Ping timeout: 260 seconds]
<whitequark> sb0: ok, so it's little endian...
<whitequark> sb0: I improved the RPC timings by almost 2x
<whitequark> it went from 15-19ms to 11-12ms
<GitHub> [artiq] sbourdeauducq pushed 10 new commits to master: https://github.com/m-labs/artiq/compare/5d3b00cf1261...dff23293c7a5
<GitHub> artiq/master 1486a94 Sebastien Bourdeauducq: manual: update moninj network info
<GitHub> artiq/master 7d568b4 Sebastien Bourdeauducq: style
<GitHub> artiq/master 360be00 Sebastien Bourdeauducq: drtio: map local RTIO core on lower channels
<whitequark> sb0: do you really need a 65k buffer for moninj?
<sb0> 65k?
<sb0> ah the tcp thing
<sb0> analyzer also has a 65k buffer
<sb0> probably not
<GitHub> [artiq] sbourdeauducq closed issue #607: support for more than 64 channels in moninj https://github.com/m-labs/artiq/issues/607
kuldeep has quit [Remote host closed the connection]
kuldeep has joined #m-labs
<bb-m-labs> build #425 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/425
<whitequark> sb0: but analyzer sends very large packets
<whitequark> I guess it doesn't have to send them at once
<bb-m-labs> build #1342 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1342 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
rohitksingh has joined #m-labs
rohitksingh has quit [Read error: Connection reset by peer]
<GitHub> [artiq] whitequark pushed 2 new commits to master: https://github.com/m-labs/artiq/compare/dff23293c7a5...88bf7d22337c
<GitHub> artiq/master 88bf7d2 whitequark: firmware: specialize protocol read/write functions....
<GitHub> artiq/master de015b9 whitequark: compiler: allow dumping the object file with ARTIQ_DUMP_OBJ.
<whitequark> sb0: Ive also addressed the byteorder issue in 88bf7d2
<bb-m-labs> build #426 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/426
<bb-m-labs> build #1343 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1343 blamelist: whitequark <whitequark@whitequark.org>
mumptai has joined #m-labs
hedgeberg|away is now known as hedgeberg
bentley` has quit [Remote host closed the connection]
kilae has quit [Quit: ChatZilla 0.9.93 [Firefox 51.0.1/20170125094131]]
mumptai has quit [Quit: Verlassend]