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
mumptai has quit [Quit: Verlassend]
Krue1 has left #m-labs [#m-labs]
<GitHub> [artiq] StanleyEDavidsdavid30 opened issue #683: Problems connecting logic analyzer to Pipistrello https://github.com/m-labs/artiq/issues/683
<GitHub> [artiq] sbourdeauducq commented on issue #683: You are not providing the relevant details. Is the PPP connection successful and are you running the kernel correctly? https://github.com/m-labs/artiq/issues/683#issuecomment-286307098
<GitHub> [artiq] StanleyEDavidsdavid30 commented on issue #683: Yes, I was able to run the led dot py successfully and can control the state of the LED by entering inputs to the artiq command line https://github.com/m-labs/artiq/issues/683#issuecomment-286307402
<GitHub> [artiq] StanleyEDavidsdavid30 commented on issue #683: So I guess this means the PPP connection is successful and I am running the kernel correctly https://github.com/m-labs/artiq/issues/683#issuecomment-286307670
<GitHub> [artiq] sbourdeauducq commented on issue #683: Yes. Which TTL pin are you using? If it's a bidirectional pin, you need to put it into output mode by calling ``output()`` followed by ``delay()``. Other than that, it's certainly an electrical or logic analyzer problem, check that you are connected to the right pin and try with a different measurement device (e.g. oscilloscope or even digital multimeter if you make the waveform slow enough). https://g
<GitHub> [artiq] StanleyEDavidsdavid30 commented on issue #683: I am connecting to TTL0 ... https://github.com/m-labs/artiq/issues/683#issuecomment-286308521
<GitHub> [artiq] StanleyEDavidsdavid30 commented on issue #683: TTL0 maps the the physical pin 2 on the Pipistrello right? https://github.com/m-labs/artiq/issues/683#issuecomment-286308764
hedgeberg|away is now known as hedgeberg
<GitHub> [artiq] sbourdeauducq commented on issue #683: There are multiple rows of pins on the Pipistrello (A/B/C) and you also need to connect the ground.... https://github.com/m-labs/artiq/issues/683#issuecomment-286323265
<GitHub> [artiq] sbourdeauducq pushed 4 new commits to master: https://github.com/m-labs/artiq/compare/95ede18809e3...a7de58b6044d
<GitHub> artiq/master 13ae1d1 Sebastien Bourdeauducq: drtio: input unittest
<GitHub> artiq/master 56fd9b3 Sebastien Bourdeauducq: drtio: input fixes
<GitHub> artiq/master 856a64f Sebastien Bourdeauducq: drtio: use TTLInOut in device_db
sb0 has quit [Quit: Leaving]
<bb-m-labs> build #464 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/464
<bb-m-labs> build #440 of artiq-win64-test is complete: Failure [failed python_unittest] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/440 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
<bb-m-labs> build #1394 of artiq is complete: Failure [failed] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1394 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
sb0 has joined #m-labs
AndChat326081 has quit [Ping timeout: 240 seconds]
<GitHub> [artiq] whitequark pushed 2 new commits to master: https://github.com/m-labs/artiq/compare/a7de58b6044d...618942bda659
<GitHub> artiq/master 618942b whitequark: conda: bump misoc.
<GitHub> artiq/master 4beda73 whitequark: firmware: don't build libdyld through misoc.
AndChat326081 has joined #m-labs
<bb-m-labs> build #465 of artiq-board is complete: Failure [failed conda_build] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/465 blamelist: whitequark <whitequark@whitequark.org>
<bb-m-labs> build #1395 of artiq is complete: Failure [failed] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1395 blamelist: whitequark <whitequark@whitequark.org>
<whitequark> uhhh what
<whitequark> sb0: amazing
<whitequark> I got the analyzer to work
<whitequark> there are two bugs, the first is that, as you've correctly guessed, the SDRAM words are reversed
<whitequark> the second is the length calculation is fucked somehow, I'm not yet sure how exactly
<whitequark> but if I remove trailing zeroes from data, it works
<whitequark> OutputMessage(channel=1, timestamp=0, rtio_counter=234918822064, address=0, data=1)
<whitequark> OutputMessage(channel=1, timestamp=999, rtio_counter=234918822088, address=0, data=0)
<whitequark> ExceptionMessage(channel=1, rtio_counter=234918822104, exception_type=<ExceptionType.o_underflow_reset: 16>)
<bb-m-labs> build #466 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/466
<bb-m-labs> build #1396 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1396 blamelist: whitequark <whitequark@whitequark.org>
<bb-m-labs> build #467 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/467
<bb-m-labs> build #1397 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1397 blamelist: whitequark <whitequark@whitequark.org>
<ysionnea1> hah
<sb0> mithro, it is what is says it is. a tdc core. what exactly is your question?
<mithro> What is a tdc core and what is it useful for?
<sb0> whitequark, are you able to reproduce this in the gateware test bench?
<sb0> mithro, something to timestamp digital signal. the popular application is laser range finders.
<whitequark> sb0: reproduce what? the length issue? I couldn't reproduce it before
<whitequark> but I'll try again
<sb0> whitequark, so if you cannot reproduce it, things are (usually) working correctly after fixing the sdram word direction issue?
<whitequark> sb0: no, I mean, it is an issue on FPGA
<whitequark> but in the past, when I experimented with the testbench, both data length 1 and data length 4 worked
<sb0> whitequark, what is the issue exactly?
<whitequark> sb0: if I emit records with 4 data bytes (the rtio_output signature has an u32 in it), and correspondingly the total record size of 18, it seems that the core detects an end marker prematurely and stops
<whitequark> if I emit records with 1 data byte and the total record size of 15, everything works as expected
<sb0> ok
<sb0> and when loading the problematic sdram words into the test bench, what happens?
<whitequark> the testbench actually never emits records with leading 0's
<sb0> yes, so make it do that
<whitequark> the tests pass
<whitequark> ah, hang on
<whitequark> yes, I made the testbench emit the exact same sequence as I form on the FPGA, and tests pass
<whitequark> hmm
<whitequark> yes, there's definitely some problem with length calculation
<whitequark> if I replace the data with 0x01020304, the core hangs
<whitequark> so it reads the next record from less than 18 bytes after
<sb0> can you reproduce the problem in simulation?
<whitequark> no
<sb0> well, this bug has to be fixed somehow
<sb0> the core only uses the length field for determining the length, not the data
<sb0> are you saying the behavior depends on the data? this sounds like another encoder bug
<whitequark> not quite
<whitequark> afaict the core behaves 'as if' the length was fixed at 15
<whitequark> so if the 16th byte is 0, great. if it's not, the core is off to wherever.
<sb0> that sounds suspicious, there is nothing in the gateware that could tell it to consume 15 bytes
<whitequark> it does to me, too
<sb0> or it's an integer overflow, that happens at this boundary because 16 needs one more bit than 15
<whitequark> ok, I'll experiment a bit more with it next morning
<sb0> try fiddling with the test bench too (e.g. increase sdram access time)
sb0 has quit [Quit: Leaving]
sb0 has joined #m-labs
<sb0> why does it seem there are few flybacks with RCD snubbers on the secondary? they all seem to use RC, when they have a secondary snubber at all
<GitHub> [artiq] jbqubit commented on issue #681: > By "asynchronous RTIO error" mean those errors that are not the immediate result of a command... https://github.com/m-labs/artiq/issues/681#issuecomment-286501783
<GitHub> [artiq] r-srinivas opened issue #684: Documentation of analyze function https://github.com/m-labs/artiq/issues/684
<whitequark> sb0: this is interesting
<whitequark> if I set length to 16, then the DMA core actually loops onto itself
<whitequark> OutputMessage(channel=1, timestamp=157370612512, rtio_counter=157370610280, address=0, data=1)
<whitequark> OutputMessage(channel=1, timestamp=157370612512, rtio_counter=157370610432, address=0, data=1)
<whitequark> ad infinitum
<whitequark> so this is interesting
<whitequark> if I set the length to 17, this is the output:
<whitequark> 17, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 0, 0,
<whitequark> OutputMessage(channel=1, timestamp=0, rtio_counter=104437994768, address=0, data=1)
<whitequark> 17, 1, 0, 0, 231, 3, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
<whitequark> OutputMessage(channel=0, timestamp=0, rtio_counter=104437994792, address=256, data=0)
<whitequark> it hallucinated 256 out of thin air!