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
<GitHub156> [artiq] r-srinivas opened issue #631: Communication with core device fails https://git.io/v1tPI
<GitHub178> [artiq] whitequark commented on issue #631: When such an error message fails, please run `artiq_corelog` and post the output also. (@jordens, do we have a "writing bug reports" doc page somewhere?) https://git.io/v1tP4
<GitHub175> [artiq] r-srinivas commented on issue #631: I managed to reproduce this by running... https://git.io/v1t1W
<GitHub162> [artiq] whitequark commented on issue #631: Can you connect to the serial port and post the output? https://git.io/v1t1g
<GitHub31> [artiq] r-srinivas commented on issue #631: By serial port do you mean the UART? That is connected, as is the JTAG. Should it produce the output automatically? https://git.io/v1t1d
<GitHub175> [artiq] whitequark commented on issue #631: Yes. In case where the core device crashes, there will almost certainly be some useful output. https://git.io/v1t1A
<GitHub69> [artiq] r-srinivas commented on issue #631: While the core device is working, I get the following output... https://git.io/v1tMB
<GitHub90> [artiq] r-srinivas commented on issue #631: While the core device is working, I get the following output... https://git.io/v1tMB
<GitHub137> [artiq] r-srinivas commented on issue #631: I tried flterm just to check the UART connection, it connects but the output is different to what it is usually,... https://git.io/v1tSy
<GitHub197> [artiq] whitequark commented on issue #631: @r-srinivas This is normal output from the new (Rust) runtime. It does not have the test mode anymore. If you crash the core device now, the flterm output should contain useful information. https://git.io/v1tSh
<GitHub99> [artiq] r-srinivas commented on issue #631: I tried that but it produces the same output. I need to reset the core device after initialising flterm which I guess destroys any of the useful information? https://git.io/v1t9R
sb0 has joined #m-labs
<GitHub141> [artiq] whitequark commented on issue #631: @r-srinivas You can just leave flterm running.... https://git.io/v1t5H
<GitHub16> [artiq] sbourdeauducq closed issue #629: Selecting new group on applet dock in artiq 3.0 crashes dashboard https://git.io/v1tlF
<GitHub90> [artiq] sbourdeauducq pushed 1 new commit to master: https://git.io/v1t5A
<GitHub90> artiq/master c5b55c1 Sebastien Bourdeauducq: applets: compatibility with older Qt. Closes #629
<GitHub32> [artiq] sbourdeauducq commented on issue #630: ``disable_applet`` does work correctly here. Did you modify the ARTIQ code at all to try to fix #629? Have you tried on Linux? https://git.io/v1tdJ
<GitHub132> [artiq] sbourdeauducq commented on issue #630: And is the first problem also on 2.0? https://git.io/v1td4
<bb-m-labs> build #237 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/237
<GitHub0> [artiq] sbourdeauducq commented on issue #631: > do we have a "writing bug reports" doc page somewhere... https://git.io/v1td5
<bb-m-labs> build #1134 of artiq is complete: Failure [failed python_unittest_1] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1134 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
rohitksingh has joined #m-labs
rohitksingh has quit [Client Quit]
rohitksingh has joined #m-labs
rohitksingh has quit [Client Quit]
rohitksingh_work has joined #m-labs
_whitelogger has joined #m-labs
<GitHub124> [artiq] r-srinivas commented on issue #631: So it's fine to leave flterm on while the master is running? Then if I can reproduce the problem, the console with flterm should hopefully have the useful information? https://git.io/v1txb
<GitHub14> [artiq] sbourdeauducq commented on issue #631: Yes. https://git.io/v1txN
<GitHub177> [artiq] r-srinivas commented on issue #630: I didn't modify the code to try and fix the other issue. I'll try and fix it on linux. This problem has been on 2.0 but I didn't look into it in detail because I thought it was maybe from the custom applets we have, and aside from producing an error message on the log doesn't really do anything terrible. https://git.io/v1txj
_whitelogger has joined #m-labs
<sb0> rjo, what's the exact plan to clock the two FMC DAC cards on separate kc705?
<sb0> cr1901_modern, what's the status of the SPI bug?
<sb0> maybe I'll look into it myself so we can get 2.1 out soonish
<whitequark> looking into the crash now
rohitksingh_work has quit [Read error: Connection reset by peer]
<rjo> sb0: 1) get drtio working, replicate clock and TSC. 2) align the slave's sysref/fpga_deviceclock to rtio_clk using the phase registers of the clock distribution chip.
rohitksingh has joined #m-labs
<sb0> rjo, on the master, the 150MHz is generated by the FMC?
<sb0> and is it connected to a GTX clock pin?
<rjo> sb0: yes and yes.
<cr1901_modern> sb0: Looking at my VCD, I cannot duplicate the bug exactly as described with a stub SPI slave. However, the core itself indeed ends up losing a bit, and I'm trying to figure out why.
<cr1901_modern> E.g. After 32 samples and 31 shifts, I end up with 0xFFFFFFFE in the register when I wanted 0xFFFFFFFF
<sb0> cr1901_modern, why do you even need a SPI slave?
<sb0> is it just checking the data?
<cr1901_modern> sb0: Yes. I added a few debugging registers
<cr1901_modern> sb0: And I added a slave b/c loopback testing didn't catch this problem.
<sb0> loopback?
<cr1901_modern> All the testing directly attaches MOSI to MISO
<cr1901_modern> I mean, I guess I don't strictly need a slave, but I found it easier to examine the flow of data with one
<whitequark> sb0: I'm using the kc705 now
<sb0> whitequark, ok
<whitequark> it would be really helpful if he posted the crash report from the UART...
<cr1901_modern> sb0: My testbench: http://hastebin.com/xejuxakuro.py
<sb0> it's 5.30am in Boulder right now, I guess it won't happen before a while
<cr1901_modern> (Of course it's just a slightly modified version of the existing TB ;)...)
<cr1901_modern> sb0: Wait, ignore that TB for now please, there's an error
rohitksingh has quit [Quit: Leaving.]
<whitequark> sb0: did the UART chnge?..
<whitequark> ah no, seems some stuck flterm
<whitequark> or both?
<cr1901_modern> sb0: Looking at my TB more closely, which is the model here: https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus#/media/File:SPI_8-bit_circular_transfer.svg I don't see how this design works.
<cr1901_modern> It takes 8 samples, and 7 shifts to move the data from master to slave and vice versa, but SPI mandates 8 samples and 8 shifts. Am I missing something obvious?
<cr1901_modern> sb0: Even if I disconnect the slaves output from MISO on the master, I end up with the same problem- it only takes 32 samples, 31 shifts to fully get the data into the destination register.
<whitequark> oky, it's not tty*
<whitequark> tty8*
<GitHub31> [artiq] whitequark commented on issue #631: I've reproduced the bug. Here is the relevant core log section:... https://git.io/v1qPg
rohitksingh has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
<GitHub146> [artiq] jordens pushed 3 new commits to phaser2: https://git.io/v1qDm
<GitHub146> artiq/phaser2 d5d17ac Robert Jordens: Merge remote-tracking branch 'm-labs/master' into phaser2...
<GitHub146> artiq/phaser2 7657cf1 Robert Jordens: phaser: bump misoc/migen
<GitHub146> artiq/phaser2 23fd225 Robert Jordens: sawg: spline knot packing/conversion, unittest
<whitequark> fixed
<GitHub26> [artiq] whitequark pushed 2 new commits to master: https://git.io/v1qDV
<GitHub26> artiq/master 5b7e068 whitequark: runtime: clear async RPC queue when kernel stops (fixes #631).
<GitHub26> artiq/master 852598c whitequark: artiq_devtool: fix incorrect use of nargs in argparse.
<GitHub42> [artiq] whitequark closed issue #631: Communication with core device fails https://git.io/v1tPI
<bb-m-labs> build #238 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/238
sandeepkr has joined #m-labs
<bb-m-labs> build #1135 of artiq is complete: Failure [failed python_unittest_1] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/1135 blamelist: whitequark <whitequark@whitequark.org>
<rjo> whitequark: what ist that trying to tell me: http://hastebin.com/zuvuyakara.py
<whitequark> hrm, good q
<whitequark> rjo: ah, is this a @kernel?
<whitequark> type annotations are only valid for RPCs
<rjo> houh?
<rjo> whitequark: "valid"?
<rjo> whitequark: we had some time ago discussed using them to prevent some pathological cases of type inferrence for kernels. wasn't that done?
<rjo> whitequark: iirc we were using default values for arguments to effectively force-monomorphize methods.
<whitequark> yeah, that was never implemented i think?
<whitequark> oh wait hm, it was
<whitequark> ... hm, weird, please file a bug
<GitHub26> [artiq] jordens opened issue #632: TList() type annotations for kernels broken https://git.io/v1qbe
<cr1901_modern> rjo: https://irclog.whitequark.org/m-labs/2016-11-29#1480424546-1480424546; Do you see anything wrong with the highlighted? Right now, I conclude that the proper behavior of the SPI core is to shift 31 times, sample 32 times before sending cs_n high. But according to the SPI "spec", that's not right. There should be equal number of shifts and samples
<rjo> that depends on the implementation.
<rjo> if MOSI is hard-wired to the first bit of the register, loading the register is one "output shift".
<rjo> if MISO is hard-wired to the last bit of the register, reading the shift register is one "input shift"
<cr1901_modern> The register is only loaded/read at the opposite clock polarity of the shift though
<cr1901_modern> In my testbench, both your above statements wrt hardwiring apply, btw
<cr1901_modern> erm, scrap that. Hardwiring doesn't apply in either of my cases
mumptai has joined #m-labs
rohitksingh has joined #m-labs
FabM has quit [Quit: ChatZilla 0.9.93 [Firefox 45.5.0/20161115214506]]
rohitksingh has quit [Quit: Leaving.]
<GitHub153> [artiq] r-srinivas commented on issue #630: Happens on 2.0 as well... https://git.io/v1mzd
<GitHub76> [artiq] r-srinivas commented on issue #631: Thanks for fixing it. I tried again on flterm to see if I could get the log but it seems to get stuck when the core device fails.... https://git.io/v1mg1
<GitHub98> [artiq] r-srinivas commented on issue #631: Thanks for fixing it. I tried again on flterm to see if I could get the log but it seems to get stuck when the core device fails.... https://git.io/v1mg1
<GitHub139> [artiq] r-srinivas commented on issue #631: Thanks for fixing it. I tried again on flterm to see if I could get the log but it seems to get stuck when the core device fails.... https://git.io/v1mg1
<GitHub73> [artiq] danielkienzlerNIST commented on issue #627: I'm not sure, but I wouldn't know if not.... https://git.io/v1mwg
raghu_ has joined #m-labs
<raghu_> bb-m-labs: force build --props=package=artiq-kc705-nist_qc2 artiq-board
<bb-m-labs> build forced [ETA 12m42s]
<bb-m-labs> I'll give a shout when the build finishes
<raghu_> thanks for setting up the build bot, it's really quite handy
raghu_ has left #m-labs [#m-labs]
argweababtab has joined #m-labs
argweababtab has left #m-labs [#m-labs]
<bb-m-labs> build #239 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/239
<GitHub63> [artiq] whitequark commented on issue #631: > Is the output on the UART. Did that work for you to get the core log?... https://git.io/v1mPC
<GitHub126> [artiq] r-srinivas commented on issue #631: Okay, thanks. Has flterm's test mode been replaced in someway? We found it pretty useful for debugging, dds' especially. https://git.io/v1mXq
<cr1901_modern> sb0: https://www.crowdsupply.com/sifive/hifive1 This company might be closer to the ideal open source microcontroller that you want? I can't find indications that this particular board is open source, but looks like the company is open to creating silicon on someone else's behalf.
<cr1901_modern> s/board/IC/
<GitHub122> [artiq] r-srinivas commented on issue #631: Seems like this problem still happens even with the latest commit. It doesn't happen as easily as before: instead of deleting the experiment 1 or 2 times I had to try maybe 4-5 times but the symptoms seem the same.... https://git.io/v1mh8
<GitHub137> [artiq] r-srinivas commented on issue #631: Seems like this problem still happens even with the latest commit. It doesn't happen as easily as before: instead of deleting the experiment 1 or 2 times I had to try maybe 4-5 times but the symptoms seem the same.... https://git.io/v1mh8
<GitHub52> [artiq] r-srinivas commented on issue #631: It seems to matter when you delete the experiment. What reproduces it quite reliably is when you delete the experiment such that it still prints test. If test is printed and the experiment was deleted it results in not being able to communicate with the core device anymore. https://git.io/v1YeF
<GitHub106> [artiq] r-srinivas commented on issue #631: It seems to matter when you delete the experiment. What reproduces it quite reliably is when you delete the experiment such that it still prints test. If test is printed and the experiment was deleted it results in not being able to communicate with the core device anymore.... https://git.io/v1YeF
<GitHub16> [artiq] r-srinivas commented on issue #631: It seems to matter when you delete the experiment. What reproduces it quite reliably is when you delete the experiment such that it still prints test. If test is printed and the experiment was deleted it results in not being able to communicate with the core device anymore.... https://git.io/v1YeF
<GitHub58> [artiq] whitequark reopened issue #631: Communication with core device fails https://git.io/v1tPI
<GitHub123> [artiq] r-srinivas commented on issue #631: Strangely if I try running this from the virtual machine, the experiment never works and always triggers this problem. ... https://git.io/v1YTt
<cr1901_modern> sb0: I'm not comfortable making the change that I want to make to the SPI core. While I'm pretty sure it will work for the AD9912, I have a feeling it will break other SPI devices. The bottom line is that the core is transferring AND shifting one extra bit than it should.
<GitHub28> [artiq] r-srinivas commented on issue #630: >disable_applet does work correctly here. Did you modify the ARTIQ code at all to try to fix #629? Have you tried on Linux?... https://git.io/v1YOJ
Gurty has quit [Ping timeout: 256 seconds]
Gurty has joined #m-labs
mumptai has quit [Remote host closed the connection]