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
X-Scale has joined #m-labs
X-Scale has quit [Ping timeout: 276 seconds]
X-Scale has joined #m-labs
<GitHub-m-labs> [artiq] apatura-iris commented on issue #1082: Good point. I hope the added comment clarifies this. https://github.com/m-labs/artiq/pull/1082#issuecomment-400533515
larsc has quit [Remote host closed the connection]
wolfspraul has quit [Ping timeout: 245 seconds]
<GitHub-m-labs> [artiq] sbourdeauducq commented on issue #1065: @gkasprow Can you do the test on your board as well (confirm that the crash-kernel crashes it, fix VCCINT, then confirm that it no longer crashes)? https://github.com/m-labs/artiq/issues/1065#issuecomment-400547009
qwebirc644864 has joined #m-labs
<qwebirc644864> Hello
<qwebirc644864> How do I check which version of flash proxy bitstream I am using in my artiq installation?
<qwebirc644864> Also let's say I am using artiq version 2.5; How do I know which version of openocd and flash proxy bitstream match up with each other?
<GitHub-m-labs> [artiq] jordens pushed 2 new commits to master: https://github.com/m-labs/artiq/compare/811882943beb...e9a1e10221cb
<GitHub-m-labs> artiq/master e9a1e10 apatura-iris: Update installing.rst...
<GitHub-m-labs> artiq/master 5e5cdf0 apatura-iris: Update installing.rst...
qwebirc644864 has quit [Quit: Page closed]
omid has joined #m-labs
<omid> How do I check for compatibility between the flash proxy bitstream version and the OpenOCD version in my artiq installation?
<bb-m-labs> build #1682 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/1682
<bb-m-labs> build #2482 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2482 blamelist: apatura-iris <40609843+apatura-iris@users.noreply.github.com>
kaolpr has joined #m-labs
<GitHub72> [smoltcp] whitequark commented on issue #250: @m-labs-homu r+ https://github.com/m-labs/smoltcp/pull/250#issuecomment-400583351
<GitHub130> [smoltcp] m-labs-homu commented on issue #250: :pushpin: Commit 107cc83 has been approved by `whitequark`
<GitHub8> [smoltcp] m-labs-homu pushed 1 new commit to auto: https://github.com/m-labs/smoltcp/commit/605c5d657f21ddba3653f471901bd88739c82fc8
<GitHub168> [smoltcp] m-labs-homu commented on issue #250: :hourglass: Testing commit 107cc832cf76c9a905c3f3432b6ffd695e93aa33 with merge 605c5d657f21ddba3653f471901bd88739c82fc8... https://github.com/m-labs/smoltcp/pull/250#issuecomment-400583462
<GitHub8> smoltcp/auto 605c5d6 Dan Robertson: Fix code syle nits...
<travis-ci> m-labs/smoltcp#1083 (auto - 605c5d6 : Dan Robertson): The build passed.
<rjo> omid: conda list will tell you which versions you have
<rjo> omid: i think in 2.x we were still shipping the proxy bitstream with the binary packages. the bscan-spi-bitstreams package was not needed and ignored.
<rjo> omid: the 2.x proxies need a matching old openocd (0.10.0+git1 or even 0.10.0-1)
omid_ has joined #m-labs
<omid_> rjo: I see. Can you please tell me what I need to do given this output: https://pastecode.xyz/view/c8a74944
<omid_> All the led's on the board are lighted up even with this output.
<omid_> sure doing it now
<omid_> Also I am setting up a new system for kc705 and am getting "artiq_flash: command not found" after running artiq_flash. Do you know why my installation is missing artiq_flash?
<omid_> rjo: the previous messages were about pipistrello
<rjo> omid_: no. given that amount of context i have no idea.
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<rjo> omid_: keep in mind that 2.x is deprecated and not supported. we haven't tried it for a long time.
marmelada has joined #m-labs
<marmelada> hey
<marmelada> how is it possible that Sayma answers pings but refuses connection to artiq_run?
<omid_> rjo: Does pipistrello work with the current main branch?
<rjo> marmelada: with the ping ip matching what you have in device_db?
<marmelada> rjo: yes
<rjo> marmelada: any console output? it usually mentions that there is a connection.
<marmelada> nothing
<rjo> omid_: no.
<marmelada> this is the last step required to run crash kernel
<rjo> marmelada: no idea then.
<rjo> marmelada: you can just write it as a startup kernel.
<marmelada> I've been trying to do it since last week but sometimes ethernet didn't work, sometimes hmc didn't lock or send valid id
<omid_> rjo: What details do you need about the pipistrello output? This is a demo for new students joining artiq. So I just want to show them something simpler rather than kc705.
<marmelada> it does it via usb?
<rjo> marmelada: tshark/wireshark/tcpdump would be my approach
<rjo> marmelada: yes. artiq_compile, artiq_mkfs, artiq_flash ... -f ... storage
<marmelada> rjo: thanks
<rjo> omid_: try it. it might work.
<omid_> rjo: that's indeed what I am doing
<marmelada> rjo: is it artiq_mkfs -f KEY crash_kernel.elf crash_kernel.img
<marmelada> what is the key?
hartytp has joined #m-labs
<hartytp> marmelada: artiq_mkfs -f startup_kernel kernel.elf startup.img
<marmelada> hartytp: thanks!
<sb0> marmelada, lower priority than crashes, but can you enable net_trace and see if sayma receives your packets?
<omid> rjo: artiq_flash is not recognized. So I tried to install openocd again with conda (v0.10.0-6). And then I ran openocd in command line and gave me this output: https://pastecode.xyz/view/5a287e0a
<sb0> marmelada, there should be several TCP ports open on sayma; are they?
<omid> sb0: Any ideas?
<sb0> omid, you have to run openocd with some script/options. this output when run without any options is normal.
<sb0> or run it through artiq_flash. is the artiq conda package installed?
<sb0> omid, btw we don't support pipistrello anymore, why not get a kasli?
<rjo> omid: you didn't try what i suggested. it's not about installing the same openocd version again. install the one i pointed you to.
<GitHub-m-labs> [artiq] marmeladapk commented on issue #1065: When running idle kernel:... https://github.com/m-labs/artiq/issues/1065#issuecomment-400610625
<omid> rjo: This is about my new kc705 installation.
<rjo> omid: your first post was pipistrello with what i assume was artiq 2.5. and artiq_flash was found.
<marmelada> sb0: I'll see if it persists after we try to fix low vccint
<sb0> hartytp, ^ see? there is a PI problem.
<rjo> omid: ok. which is which?
<GitHub-m-labs> [artiq] marmeladapk commented on issue #1065: When running idle kernel (artiq 8118829):... https://github.com/m-labs/artiq/issues/1065#issuecomment-400610625
<sb0> marmelada, VCCINT should not only be higher, but also it should not drop ...
<omid> rjo: no. the artiq_flash not being recognized is with my kc705 setup. Whereas this output here for my pipistrello setup: https://pastecode.xyz/view/c8a74944
<marmelada> yeah, this kernel causes very high current consumption
<rjo> omid: (pipistrello, artiq 2.5): again, get an older openocd, the one i pointed you to.
<sb0> according to the vivado power estimator it should be something like ~5A on VCCINT
<sb0> isn't the sayma power supply rated for 10A?
<rjo> omid: (kc705, artiq verion i don't know): please give us some context. tell us what you did and what you expect, what packages are installed.
<hartytp> sb0: I didn't say that there wasn't
<hartytp> I also didn't say/don't think that there is only a single problem here
<rjo> sb0: greg's design is supposedly for > 10a.
<rjo> marmelada: nice!
<hartytp> sb0: look over the logs. I don't like the whining. I also don't duy the claims that it is *definitely* a hw issue, as I don't think we have evidence for that just yet (cf recent issues that have come out of code reviews)
<marmelada> he simulated <50mV @ 20 A
<hartytp> if I had thought it *definitely* wasn't a hw issue, I wouldn't have prodded greg to ask for an external hw review
<marmelada> 50 mV if drio
<hartytp> (anyway, sb0, very good catch on this one)
<rjo> omid: and you don't want to work with those two setups in the same conda environmen. i assume you are using different ones but i don't know.
<marmelada> *50 mV of drop
<sb0> marmelada, and how's the ripple?
<rjo> hartytp, sb0: imho it is too early to do a post-mortem of the process.
<marmelada> sb0: we measured DC for now
<omid> rjo: yes, I understand. In this case they are even on separate stations
<rjo> marmelada: isn't 50mV pretty large given the tight specs of 0.922 V recommended min?
<hartytp> rjo: agreed. there are lots of lessons to be learnt here, but let's worry about that later on...
<rjo> marmelada: can you tell whether the drop is just a symptom or the cause? i.e. is the drop there if you run a similarly stressfull kernel before it crashes?
<GitHub-m-labs> [artiq] sbourdeauducq commented on commit 0c32d07: @enjoy-digital Any thoughts about this approach? Are we using the DAC sync error counters correctly? https://github.com/m-labs/artiq/commit/0c32d07e8b59e60ee304753e732bfa0c07e0daa6#commitcomment-29513295
<marmelada> rjo: it looks like this kernel causes high current consumption, which causes drop which causes erratic behaviour
<marmelada> similarly stressfull kernel would be something without awg?
<hartytp> is the current consistent with the vivado model?
<GitHub-m-labs> [artiq] sbourdeauducq pushed 5 new commits to master: https://github.com/m-labs/artiq/compare/e9a1e10221cb...d49716dfaced
<GitHub-m-labs> artiq/master 7dfd70c Sebastien Bourdeauducq: hmc7043: make margin_{minus,plus} consistent with ad9154
<GitHub-m-labs> artiq/master 4bbdd43 Sebastien Bourdeauducq: hmc7043: do not freeze if SYSREF slip fails
<GitHub-m-labs> artiq/master a8a2ad6 Sebastien Bourdeauducq: runtime: tune Sayma SYSREF phases
<marmelada> harytp: we measured +-6,8 A
<marmelada> it's not very precise bc we were measuring on 0 Ohm resistors
<marmelada> that's at 0,9V @ VCCINT
<omid> rjo, sb0: For my new kc705 setup I am just following the normal instructions. I have latest conda with anaconda 3. Python 3.6. Then I install artiq-kc705-nist_clock in a new envoronment and then I activate it. But artiq_flash is still not recognized. Do you need more information?
<hartytp> sb0: fwi, WR PLL with the DCXO locks to the GTP clock
<hartytp> weida is updating the LF for a phase noise measurement soon
<rjo> marmelada: something that just sets f0,f1,f2,a1,a2 once and then exits. https://github.com/m-labs/artiq/blob/master/artiq/examples/sayma_standalone/repository/sines.py
<sb0> omid, install the artiq package
<sb0> not just the kc705 one
<rjo> marmelada: that should use almost as much current as the crash kernel.
<sb0> ah hm, the two si5324 output dividers aren't synchronized, and this breaks sayma inter-board sync right now
<sb0> we don't see this problem on kasli because the clock outputs to the fabric and to the GTP are from the same si5324 output with a passive fanout buffer
<sb0> I suppose I can repurpose FPGA_ADC_SYSREF and put the whole RTM clock tree into the siphaser loop
<sb0> hm, no
<sb0> oh wait I can, but then I have to clock the drtio transceiver from the rtm as well
<sb0> the si5324 won't send anything into the fpga, it's only used to drive clkout to the hmc830
<sb0> actually this is great, then the coax length from clkout to the rtm gets into the siphaser loop as well
<bb-m-labs> build #1683 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/1683
<GitHub-m-labs> [artiq] marmeladapk commented on issue #1065: I recreated this on another Sayma. https://github.com/m-labs/artiq/issues/1065#issuecomment-400633238
<GitHub-m-labs> [artiq] marmeladapk commented on issue #1065: I recreated this on another Sayma AMC. https://github.com/m-labs/artiq/issues/1065#issuecomment-400633238
<bb-m-labs> build #2483 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2483 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
<marmelada> rjo: something like this? https://hastebin.com/wezarewajo.css
<sb0> the only drawback is, this will mandate the other GTP clock on the satellite as well, which triggers this obscure PRBS Sayma-bugⓇ on some boards
<GitHub-m-labs> [artiq] marmeladapk commented on issue #1065: @jordens Running this idle kernel:... https://github.com/m-labs/artiq/issues/1065#issuecomment-400638311
kaolpr has quit [Ping timeout: 255 seconds]
kaolpr has joined #m-labs
<sb0> sigh, vivado still doesn't update constraints when it merges clock nets
kaolpr has quit [Ping timeout: 260 seconds]
<rjo> marmelada: it should be a kernel that doesn't crash. the alternative to check for cause vs symptom is to pull 10A out of the 0.95V ldo manually and see whether it drops.
<marmelada> Greg added feedback to buck
<marmelada> now the first kernel I posted runs >5 minutes without crash
<marmelada> and we measure 0,925 V on VCCINT
<rjo> marmelada: nice.
<rjo> marmelada: but it already had "feedback". do you mean feeding back using VCCINT near the fpga?
<marmelada> and it's just shorting two pads (DNPed resistor)
<marmelada> yes
<hartytp> nice!
<rjo> marmelada: good. let's make sure that it stays >0.922v (at the fpga pins) also for high load.
<marmelada> we're going to adjust output voltage after greg finishes desribing the fix
<GitHub-m-labs> [artiq] gkasprow commented on issue #1065: Let me explain why there is such strange feedback loop in the VCCINT design.... https://github.com/m-labs/artiq/issues/1065#issuecomment-400650588
<sb0> if two clock nets are connected and both have a KEEP attribute, does it impact synthesis results negatively compared to a single/automerged clock net?
<marmelada> this fix also works on another sayma
<GitHub-m-labs> [artiq] gkasprow commented on issue #1065: I installed R508 (short circuit) and it looks like it helps. The voltage at the FPGA is 0.925, the VMON show 0.91. So suggest to increase the output voltage by 25mV. https://github.com/m-labs/artiq/issues/1065#issuecomment-400651169
<rjo> sb0: good question. i think there might be an alternative to get referenceable clock nets by consistently using "get_clocks -of {net}" instead of keep.
<marmelada> sb0: on second sayma with 8118829 I also get connection refused, should I build newest version or can I track this issue with current one?
<hartytp> marmelada: do you still get JESD PRBN errors with the increased vccint?
<sb0> marmelada, there has been no network changes since 8118829 afaict
<marmelada> harytp: right now no, but this week our RTMs exhibit "Sayma behaviourⓇ" as sb0 would say
<GitHub-m-labs> [artiq] gkasprow commented on issue #1065: On two AMC boards memory errors disappeared. https://github.com/m-labs/artiq/issues/1065#issuecomment-400655430
<GitHub-m-labs> [artiq] marmeladapk commented on issue #1065: And crashes. Idle kernel I posted earlier run over 10 minutes without any hiccups. https://github.com/m-labs/artiq/issues/1065#issuecomment-400656151
<GitHub-m-labs> [artiq] marmeladapk commented on issue #1065: And crashes. Idle kernel I posted earlier is running over 10 minutes now without any hiccups. https://github.com/m-labs/artiq/issues/1065#issuecomment-400656151
<sb0> ah, of course, clocking the drtio transceiver from dac_refclk0, while it works on the master, breaks on the satellite - the transceiver simply never locks ...
<marmelada> sb0: I've got the same issue on Kasli which wasn't flashed with any new gateware or firmware in a while
<marmelada> and I'm sure it worked
<marmelada> so it's either my system or something in frontend
<sb0> marmelada, could it be the startup kernel?
<GitHub-m-labs> [artiq] jordens commented on issue #1065: Even with DCAP, isn't there enough compensation (i.e. AC feedback) happening through C293+C430 anyway? https://github.com/m-labs/artiq/issues/1065#issuecomment-400660811
<hartytp> oh ffs
<hartytp> I have a feeling I know what's wrong with zotino
<hartytp> reverse protection diode on -12V ldo is a zener
<hartytp> not schottky
<hartytp> so, it doesn't do anything until the rail reaches +0.7V
<hartytp> (which it does on one of our boards)
<hartytp> by which time the DAC is dead..
<marmelada> sb0: no idle kernel
<rjo> marmelada: startup.
<hartytp> I thought we agreed on Zener, but must have misread the schematic every time I did a review
<rjo> marmelada: could you post the console output?
<hartytp> s/zener/schottky
<rjo> hartytp: for any appreciable currents (i.e. the ones we are protecting against) a shottky is a regular diode, no?
<rjo> at least that's what i always thought.
<rjo> ah. not true for power schottky diodes.
<hartytp> rjo: not true at all
<hartytp> decent schottky didoes can sink quite a bit of current at a few hundred mV
<hartytp> when silicon diodes aren't conducting at all
<hartytp> (effectively, that's why the DACs can only take +0.3 and not +0.6V on the negative supply)
<hartytp> anyway, the current design does nothing to stop the negative supply being reverse biased beyond the abs max ratings during power on
marmelada_ has joined #m-labs
<GitHub108> [smoltcp] dlrobertson commented on issue #250: @m-labs-homu retry... https://github.com/m-labs/smoltcp/pull/250#issuecomment-400667859
<GitHub4> [smoltcp] m-labs-homu force-pushed auto from 605c5d6 to 8d2a203: https://github.com/m-labs/smoltcp/commits/auto
<GitHub4> smoltcp/auto 8d2a203 Dan Robertson: Fix code syle nits...
<GitHub196> [smoltcp] m-labs-homu commented on issue #250: :hourglass: Testing commit 107cc832cf76c9a905c3f3432b6ffd695e93aa33 with merge 8d2a20362ec230f3038639faa7cc2fd39999ab11... https://github.com/m-labs/smoltcp/pull/250#issuecomment-400667926
marmelada has quit [Ping timeout: 260 seconds]
<rjo> hartytp: "not true at all" is nonsense. this is true for signal schottkys.
<rjo> marmelada_: i'll check with kasli.
<rjo> marmelada_: log looks ok. sure there are no other devices around with that mac or with that ip?
<GitHub73> [smoltcp] m-labs-homu commented on issue #250: :sunny: Test successful - [status-travis](https://travis-ci.org/m-labs/smoltcp/builds/397347330?utm_source=github_status&utm_medium=notification)
<GitHub196> [smoltcp] m-labs-homu closed pull request #250: Fix code style nits (master...fix_ipv6option_nits) https://github.com/m-labs/smoltcp/pull/250
<GitHub56> [smoltcp] m-labs-homu merged auto into master: https://github.com/m-labs/smoltcp/compare/42d25bfe2645...8d2a20362ec2
<marmelada_> rjo: of course there are...
<marmelada_> some new device must have appeared
<marmelada_> could we use dhcp in artiq?
<rjo> marmelada_: with so many saymas and kasli working well now...
<marmelada_> it's not the first time we have this problem
<GitHub-m-labs> [migen] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/migen/commit/daf6f5d951595e4cc8af19ebdbc5e78e551804e7
<GitHub-m-labs> migen/master daf6f5d Sebastien Bourdeauducq: sayma: add adc_sysref pins
<GitHub-m-labs> [artiq] sbourdeauducq pushed 1 new commit to master: https://github.com/m-labs/artiq/commit/a65721d6497a8c604e6d2e766093aaf708cb21ac
<GitHub-m-labs> artiq/master a65721d Sebastien Bourdeauducq: sayma: put RTM clock tree into the siphaser loop...
<travis-ci> m-labs/smoltcp#1085 (master - 8d2a203 : Dan Robertson): The build passed.
<GitHub-m-labs> [artiq] gkasprow commented on issue #1065: yes, it has local compensationAC loop and DC feedback loop. https://github.com/m-labs/artiq/issues/1065#issuecomment-400678199
rooi-oog has joined #m-labs
<bb-m-labs> build #293 of migen is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/migen/builds/293
d_n|a has joined #m-labs
<d_n|a> hartytp: I have a bunch of NSR0240H and NSR02100HT1G in stock, but these are rather high in forward voltage. ("QLNPD" box, remind me to sort them away at some point…) Paralleling enough might get the rail low enough for testing.
d_n|a has quit [Remote host closed the connection]
<hartytp> d_n|a thanks in that case I'll stick with the 1PS79SB30 in the electronics lab
<bb-m-labs> build #1684 of artiq-board is complete: Success [build successful] Build details are at http://buildbot.m-labs.hk/builders/artiq-board/builds/1684
<bb-m-labs> build #2484 of artiq is complete: Failure [failed python_unittest_2] Build details are at http://buildbot.m-labs.hk/builders/artiq/builds/2484 blamelist: Sebastien Bourdeauducq <sb@m-labs.hk>
hartytp has quit [Quit: Page closed]
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale has joined #m-labs
little-dude has quit [Quit: WeeChat 2.1]
little-dude has joined #m-labs
marmelada_ has quit [Quit: Page closed]
larsc has joined #m-labs
<travis-ci> batonius/smoltcp#140 (layers - 52fa881 : Egor Karavaev): The build is still failing.
rooi-oog has left #m-labs [#m-labs]
omid_ has quit [Ping timeout: 260 seconds]
omid has quit [Ping timeout: 260 seconds]
omid_ has joined #m-labs
<omid_> rjo, sb0: On my kc705 phaser setup I can ping its ip now. Yet when I want to run a simple RTIO script (the pulses from documents) I get connectionrefused error here https://pastecode.xyz/view/f61322cc
<rjo> omid_: check your device_db, post uart output
<omid_> rjo: This is my device_db file: https://pastecode.xyz/view/d80908cc
<omid_> rjo: flterm is not recognized!
<omid_> Ok I installed misoc and now have the flterm
<omid_> rjo: I get the same error and the output of flterm /dev/ttyUSB1 is nothing!
lars_ has joined #m-labs
omid has joined #m-labs
omid_ has quit [Ping timeout: 260 seconds]
X-Scale has quit [Ping timeout: 264 seconds]
[X-Scale] has joined #m-labs
[X-Scale] is now known as X-Scale
<rjo> omid: the first line of device_db.py
omid_ has joined #m-labs
<omid_> I am now using this db file: https://pastecode.xyz/view/68809c58
<omid_> The result is exactly the same.
<omid_> rjo: Any ideas?
<omid_> I get the same refuse connection error and no output on flterm USB1
omid has quit [Ping timeout: 260 seconds]
omid_ has quit [Quit: Page closed]
omid has joined #m-labs
Gurty has quit [Ping timeout: 256 seconds]
Gurty has joined #m-labs
<GitHub-m-labs> [artiq] gkasprow commented on issue #1065: Here is R508, on bottom side under the DC/DC converter, close to these two big 0R resistors... https://github.com/m-labs/artiq/issues/1065#issuecomment-400855998
[X-Scale] has joined #m-labs
X-Scale has quit [Ping timeout: 256 seconds]
[X-Scale] is now known as X-Scale