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-m-labs> [artiq] sbourdeauducq commented on issue #1065: > I'll look at the power rails on Tuesday and also try to reproduce the problem.... https://github.com/m-labs/artiq/issues/1065#issuecomment-398596222
<sb0> _florent_, shouldn't the divider for analog/digital delays be 17 and not 16? https://gist.github.com/sbourdeauducq/be1421ff3c972e6c73cfe78127ad054b
kaolpr has quit [Ping timeout: 265 seconds]
kaolpr has joined #m-labs
<sb0> hartytp, with the synchronization scheme I have in mind, sysref will have to meet s/h at the FPGA RTIO clock domain (same as JESD core). and the FPGA will confirm its s/h margin (like it does currently for sysref at the DAC since my last commit). does this qualify as "proper"?
kaolpr has quit [Ping timeout: 264 seconds]
<sb0> if we want to be paranoid, we can add a MultiReg anyway, but under normal conditions, all it will do is prevent metastability during the s/h scan
kaolpr has joined #m-labs
<cr1901_modern> Hmmm, the person asking for cygwin support kinda vanished after January. Still prob wouldn't hurt to clean up the patch as an example of how to add cygwin support to other backends.
<cr1901_modern> rjo: Apologies in advance, but... I have a "todo" bullet for Migen that says "add toolchain tests". Are the platform tests (test_platform.py) we have now sufficient or were you looking for something more substantial?
<cr1901_modern> And here I make a PR for "better platform tests" and say "I'll add toolchain tests later": https://irclog.whitequark.org/m-labs/2017-11-16#1510864205-1510864205;
<cr1901_modern> Spoiler alert: If I had an idea of how to structure toolchain tests, I've since forgotten it (and feel like iterating over all platforms is sufficient: https://github.com/m-labs/migen/blob/master/migen/test/test_platform.py) :/
<cr1901_modern> (I do still owe you subtest refactoring and namer tests for https://github.com/m-labs/migen/pull/98, however)
<cr1901_modern> rjo: Disregard, found the relevant IRC message: https://irclog.whitequark.org/m-labs/2017-11-13#20533552;
_florent_ has quit [Ping timeout: 256 seconds]
Ishan_Bansal has quit [Ping timeout: 256 seconds]
rohitksingh_work has joined #m-labs
mithro has quit [Ping timeout: 256 seconds]
sb0 has quit [Quit: Leaving]
_florent_ has joined #m-labs
Ishan_Bansal has joined #m-labs
_florent_ has quit [Ping timeout: 256 seconds]
Ishan_Bansal has quit [Ping timeout: 256 seconds]
sb0 has joined #m-labs
<sb0> okay, sawg-over-drtio (without board sync) is working!
_florent_ has joined #m-labs
<GitHub-m-labs> [artiq] sbourdeauducq opened issue #1075: exceptions from startup kernel are not properly formatted https://github.com/m-labs/artiq/issues/1075
Ishan_Bansal has joined #m-labs
mithro has joined #m-labs
_florent_ has joined #m-labs
_florent_ has quit [Changing host]
mithro has quit [Max SendQ exceeded]
mithro has joined #m-labs
<sb0> oh, that's hilarious, the crash-kernel runs just fine on the DRTIO master when driving a remote SAWG on the satellite, and the DAC output looks fine
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1075: That's not Sayma, the code clearly doesn't format the exception message.... https://github.com/m-labs/artiq/issues/1075#issuecomment-398638435
<GitHub171> [smoltcp] birkenfeld commented on issue #16: This seems to have resurfaced, since `Ipv4Packet::new_checked()` is now used there, which *does* check the total_len field.... https://github.com/m-labs/smoltcp/issues/16#issuecomment-398648424
<sb0> does the DAC require some reinitialization after sysref slips, or does it simply take the new sysref phase without complaining?
hartytp has joined #m-labs
<hartytp> sb0: yes, that sounds good
<hartytp> (assuming you're happy that metastability during the sysref scan can't cause any nasty issues)
<hartytp> sb0: how easy would it be to add a mem test after DAC init?
<sb0> normal CPU memtest isn't hard, eye scan is problematic
<sb0> the memtest function in the bootloader is just regular code, it can be copy-pasted into the runtime for testing
<hartytp> okay, I might try that
<hartytp> thanks
<sb0> replace the MEMORY const with a regular stack-allocated array
<GitHub-m-labs> [artiq] hartytp commented on issue #1065: @gkasprow @marmeladapk might also be worth double checking that we really have followed all Xilinx user guides on power supplies, decoupling, etc and that that decoupling capacitors have the correct voltage rating etc. https://github.com/m-labs/artiq/issues/1065#issuecomment-398666175
<sb0> and remove unsafe {}
<GitHub-m-labs> [artiq] hartytp commented on issue #813: Summarising: rework for this is... https://github.com/m-labs/artiq/issues/813#issuecomment-398671409
<rjo> cr1901_modern: ack
<rjo> sb0: nice!
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1065: One workaround is to run the SAWG kernels over DRTIO. Both the Sayma DRTIO master and satellite seem surprisingly unaffected by the crashes, so far. If the master crashes it can in theory be replaced by Kasli. https://github.com/m-labs/artiq/issues/1065#issuecomment-398672104
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1065: One workaround is to run the SAWG kernels over DRTIO. Both the Sayma DRTIO master and satellite seem surprisingly unaffected by the crashes, so far. If the master crashes it can in theory be replaced by Kasli.... https://github.com/m-labs/artiq/issues/1065#issuecomment-398672104
sb0 has quit [Quit: Leaving]
rohitksingh_work has quit [Read error: Connection reset by peer]
<GitHub62> [smoltcp] dlrobertson commented on issue #16: I *think* ensuring the packet is larger than 8 + the end of the destination address should be good enough for now. I don't see anything that should panic in [icmpv4.rs:415-434](https://github.com/m-labs/smoltcp/blob/master/src/wire/icmpv4.rs#L415-L434) or [icmpv6.rs:483-498](https://github.com/m-labs/smoltcp/blob/master/src/wire/icmpv6.rs#L483-L498).... https://github.
<GitHub-m-labs> [artiq] marmeladapk commented on issue #1065: With boot::jump(0) Sayma goes through one full init sequence, reboots and then hangs after `enabling hmc7043` is printed. Reproduced across many manual restarts and power cycling. Nothing out of the ordinary happens in memtests. [Log](https://hastebin.com/ebumesoxuc.php) https://github.com/m-labs/artiq/issues/1065#issuecomment-398736109
<GitHub-m-labs> [artiq] hartytp commented on issue #1065: @marmeladapk can you look at the HMC7043 outputs on the UFL connectors and see what the signal there looks like during this test?... https://github.com/m-labs/artiq/issues/1065#issuecomment-398742688
<GitHub-m-labs> [artiq] gkasprow commented on issue #1065: I will test it in a moment. https://github.com/m-labs/artiq/issues/1065#issuecomment-398744106
<GitHub-m-labs> [artiq] hartytp commented on issue #1065: Note to self: one potentially significant difference between the DRIO and standalone Sayma builds is how the RTIO is clocked/reset. In standalone, the RTIO logic is clocked from the HMC7043 output and reset by the same signal that enables the clock input buffers: ... https://github.com/m-labs/artiq/issues/1065#issuecomment-398746747
<GitHub-m-labs> [artiq] hartytp commented on issue #1065: Note to self: one potentially significant difference between the DRIO and standalone Sayma builds is how the RTIO is clocked/reset. In standalone, the RTIO logic is clocked from the HMC7043 output and reset by the same signal that enables the clock input buffers: ... https://github.com/m-labs/artiq/issues/1065#issuecomment-398746747
<GitHub-m-labs> [artiq] hartytp commented on issue #1065: Note to self: one potentially significant difference between the DRIO and standalone Sayma builds is how the RTIO is clocked/reset. In standalone, the RTIO logic is clocked from the HMC7043 output and reset by the same signal that enables the clock input buffers: ... https://github.com/m-labs/artiq/issues/1065#issuecomment-398746747
<GitHub-m-labs> [artiq] gkasprow commented on issue #1065: I removed caps that connect HMC7043 with AMC FPGA:... https://github.com/m-labs/artiq/issues/1065#issuecomment-398751605
<GitHub-m-labs> [artiq] marmeladapk commented on issue #1065: @hartytp It made it worse, now sayma always locks up on hmc830. https://github.com/m-labs/artiq/issues/1065#issuecomment-398764349
sb0 has joined #m-labs
<GitHub-m-labs> [artiq] gkasprow commented on issue #1065: I don't see any link between removing the caps and hmc830 locking https://github.com/m-labs/artiq/issues/1065#issuecomment-398768327
<GitHub-m-labs> [artiq] hartytp commented on issue #1065: Can you post logs?... https://github.com/m-labs/artiq/issues/1065#issuecomment-398770108
<GitHub-m-labs> [artiq] marmeladapk commented on issue #1065: @hartytp With boot:jump(0) sayma would do one full cycle from memtest to dac init, then reboot and hang on hmc7043 init. Now it always hangs on hmc830 lock.... https://github.com/m-labs/artiq/issues/1065#issuecomment-398772505
<GitHub-m-labs> [artiq] marmeladapk commented on issue #1065: @hartytp With boot:jump(0) sayma would do one full cycle from memtest to dac init, then reboot and hang on hmc7043 init. Now it always hangs on hmc830 lock.... https://github.com/m-labs/artiq/issues/1065#issuecomment-398772505
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1065: That's not hanging, that's the HMC830 not locking. https://github.com/m-labs/artiq/issues/1065#issuecomment-398772941
<GitHub-m-labs> [artiq] marmeladapk commented on issue #1065: @sbourdeauducq True, sorry for confusion. https://github.com/m-labs/artiq/issues/1065#issuecomment-398773289
<GitHub-m-labs> [artiq] sbourdeauducq pushed 6 new commits to master: https://github.com/m-labs/artiq/compare/0c32d07e8b59...5a91f820fd96
<GitHub-m-labs> artiq/master 814d058 Sebastien Bourdeauducq: hmc7043: improve smoothness of sysref phase control
<GitHub-m-labs> artiq/master 9142a5a Sebastien Bourdeauducq: rtio: expose coarse timestamp in RTIO and DRTIO satellite cores
<GitHub-m-labs> artiq/master 5272c11 Sebastien Bourdeauducq: typo
<GitHub-m-labs> [artiq] sbourdeauducq commented on commit 814d058: @enjoy-digital Does this look good? I don't understand why you used 16 before. https://github.com/m-labs/artiq/commit/814d0583dbbea3cffa1f1f6f16b29b5ada0858d4#commitcomment-29434551
<GitHub-m-labs> [artiq] marmeladapk commented on issue #1065: @hartytp It may be a red herring - now it fails to identify... https://github.com/m-labs/artiq/issues/1065#issuecomment-398781286
<GitHub-m-labs> [artiq] gkasprow commented on issue #1065: the HMC has ID: 0xA7975 so it looks that A character is missing. https://github.com/m-labs/artiq/issues/1065#issuecomment-398783425
<GitHub-m-labs> [artiq] enjoy-digital commented on commit 814d058: Yes that's fine, sorry. We have 17 steps to have the 16*25ps delay, not 16. https://github.com/m-labs/artiq/commit/814d0583dbbea3cffa1f1f6f16b29b5ada0858d4#commitcomment-29434959
<GitHub-m-labs> [artiq] marmeladapk commented on issue #1065: On forth code id is read correctly. But chip fails to lock. https://github.com/m-labs/artiq/issues/1065#issuecomment-398787823
<GitHub-m-labs> [artiq] marmeladapk commented on issue #1065: Since it only happens on one RTM it seems to be hardware bug/failure. We'll continue discussion in https://github.com/sinara-hw/sinara/issues/472 .... https://github.com/m-labs/artiq/issues/1065#issuecomment-398793559
<bb-m-labs> build #1661 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/1661
<GitHub142> [smoltcp] birkenfeld opened issue #245: strange behavior with packet buffer enqueue? https://github.com/m-labs/smoltcp/issues/245
<bb-m-labs> build #2465 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2465 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
<GitHub-m-labs> [artiq] hartytp commented on issue #1065: Did the DACs fail to init before you removed those resistors? https://github.com/m-labs/artiq/issues/1065#issuecomment-398796679
<GitHub-m-labs> [artiq] marmeladapk commented on issue #1065: @hartytp yes. https://github.com/m-labs/artiq/issues/1065#issuecomment-398797086
<GitHub-m-labs> [artiq] gkasprow commented on issue #1065: @sbourdeauducq do you use FPGA_DAC_SYSREF from HMC7043 to AMC FPGA? It has very low amplitude, roughly 200mV while other signals are 1V or more.... https://github.com/m-labs/artiq/issues/1065#issuecomment-398800516
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1065: > do you use FPGA_DAC_SYSREF from HMC7043 to AMC FPGA?... https://github.com/m-labs/artiq/issues/1065#issuecomment-398801497
<GitHub-m-labs> [artiq] hartytp commented on issue #1065: Sysref is lvds others are lvpecl. https://github.com/m-labs/artiq/issues/1065#issuecomment-398802370
<GitHub-m-labs> [artiq] hartytp commented on issue #1065: @gkasprow HMC7043 reset seems to help. Connect to FPGA and pull HIGH. https://github.com/m-labs/artiq/issues/1065#issuecomment-398802641
<GitHub-m-labs> [artiq] gkasprow commented on issue #1065: Can we set output of HMC7043 FPGA SYSREF to LVPECL? it is AC-terminated so it does not mater. At the moment it has two 200R to GND so the amplitude gets attenuated seriously. I'm worried about low amplitude. https://github.com/m-labs/artiq/issues/1065#issuecomment-398803751
<GitHub-m-labs> [artiq] hartytp commented on issue #1065: @gkasprow two options: ... https://github.com/m-labs/artiq/issues/1065#issuecomment-398804712
<GitHub-m-labs> [artiq] hartytp commented on issue #1065: Still I don't think that the crashes are related to a low sysref signal https://github.com/m-labs/artiq/issues/1065#issuecomment-398804907
<GitHub-m-labs> [artiq] gkasprow commented on issue #1065: I'm not worried about crashes but errors on JESD links. I observe them on two boards. @marmeladapk just modified registers. https://github.com/m-labs/artiq/issues/1065#issuecomment-398805149
<GitHub-m-labs> [artiq] hartytp commented on issue #1065: I guess the load is quite high because we also use HMC7043 internal 100R termination which explains the small signal.... https://github.com/m-labs/artiq/issues/1065#issuecomment-398806025
<GitHub-m-labs> [artiq] gkasprow commented on issue #1065: with LVPECL I observe 0.8Vpp on each output. so we won't break the LVDS input. But it did not help and I still get PRBS errors. https://github.com/m-labs/artiq/issues/1065#issuecomment-398807808
<GitHub-m-labs> [artiq] gkasprow commented on issue #1065: I reverted original HMC7043 reset, added 4k7pullup but this did not help. https://github.com/m-labs/artiq/issues/1065#issuecomment-398808079
<GitHub-m-labs> [artiq] hartytp commented on issue #1065: Do you have the resistors connecting the AMC to the HMC7043 depopulated? https://github.com/m-labs/artiq/issues/1065#issuecomment-398808889
<GitHub-m-labs> [artiq] hartytp commented on issue #1065: Do you have the capacitors connecting the AMC to the HMC7043 depopulated? https://github.com/m-labs/artiq/issues/1065#issuecomment-398808889
<GitHub-m-labs> [artiq] hartytp commented on issue #1065: Otherwise I'm not sure, haven't had that error. https://github.com/m-labs/artiq/issues/1065#issuecomment-398809492
sb0 has quit [Ping timeout: 248 seconds]
sb0 has joined #m-labs
<GitHub-m-labs> [artiq] hartytp commented on issue #1065: @gkasprow Have you ever seen PRBS checks working with this board? Have you tested it with other versions of ARTIQ? Do you have another RTM you can try?... https://github.com/m-labs/artiq/issues/1065#issuecomment-398867930
<GitHub-m-labs> [artiq] gkasprow commented on issue #1065: One of the board was perfectly working yesterday generating sinewave. The other board was tested and was working with PRBS some time ago. I tested all 10 boards with PRBS after I discovered issue with JESD termination. Now two of them has similar problems with PRBS and I'd love to understand why. https://github.com/m-labs/artiq/issues/1065#issuecomment-398909563
<GitHub-m-labs> [artiq] jonaskeller opened issue #1076: RPC returning TList(TBytes) corrupts unrelated variables https://github.com/m-labs/artiq/issues/1076
<GitHub-m-labs> [artiq] whitequark commented on issue #1076: > This might be a separate issue, but just in case:... https://github.com/m-labs/artiq/issues/1076#issuecomment-398917259
<GitHub33> [smoltcp] whitequark commented on issue #245: Which version of smoltcp? https://github.com/m-labs/smoltcp/issues/245#issuecomment-398918601
<GitHub177> [smoltcp] whitequark commented on issue #245: Which version of smoltcp? https://github.com/m-labs/smoltcp/issues/245#issuecomment-398918601
<GitHub70> [smoltcp] whitequark commented on issue #245: @dlrobertson Can you please take a look? Something's screwy with that condition. https://github.com/m-labs/smoltcp/issues/245#issuecomment-398918876
<GitHub77> [smoltcp] dlrobertson commented on issue #245: Yup, that logic seems off... https://github.com/m-labs/smoltcp/issues/245#issuecomment-398921986
ohsix has quit [Ping timeout: 255 seconds]