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?
<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>
<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_>
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
<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.
<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?
<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: 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
<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
<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
<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
<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
<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