rohitksingh_work has quit [Ping timeout: 248 seconds]
attie has quit [Ping timeout: 240 seconds]
attie has joined #m-labs
rohitksingh_wor1 has quit [Ping timeout: 240 seconds]
rohitksingh_work has joined #m-labs
<GitHub-m-labs>
[artiq] whitequark commented on issue #945: You'd need to "just" rewrite Vec to support specifying allocators explicitly. It seems more straightforward to wait a few days for the RFC to be implemented. https://github.com/m-labs/artiq/issues/945#issuecomment-370666477
<sb0>
_florent_, do you want to look into the sayma sdram issues?
<sb0>
I don't remember what the status is, is the problem still there on those boards that have the exar settings fixed?
hartytp has joined #m-labs
<hartytp>
rjo: agreed, let's get the SDRAM sorted
attie has quit [Remote host closed the connection]
<hartytp>
sb0: all the info is on the issue
attie has joined #m-labs
<hartytp>
I know there is a lot going on, but please do try to keep on top of this
<hartytp>
We agreed that Greg would try to finish hardware tests today to establish if this is a HW issue or a firmware/gateware/vivado/etc issue
<hartytp>
I need you to closely follow Greg's testing to check that you're happy he's done all the right tests
<hartytp>
and that you are generally satisfied with the level of testing
<marmelada>
rjo: v1.1 #19 has I grade
<hartytp>
sb0: if you want more tests done then you need to speak up now
<sb0>
_florent_, ^
<marmelada>
v1.0 we have has heatsink so I can't check
<hartytp>
otherwise, I'll assume that you agree this is a gateware/etc issue and that you (M-Labs) will take full responsibility for fixing it in a timely fashion
<GitHub-m-labs>
[artiq] jordens commented on issue #938: I can reproduce this with the current opticlock variant (right now, in that variant, `external_clock=True` means using the si5324 in free_run mode). https://github.com/m-labs/artiq/issues/938#issuecomment-370748575
<marmelada>
rjo, sb0, hartytp, technosystem asked me how many bp adapters do we want
<sb0>
bp adapters?
<marmelada>
I'll answer them to produce one for each Kasli
<hartytp>
what kind? (what to what)?
<hartytp>
aah
<hartytp>
I want 5 please
<hartytp>
(assuming they're fairly cheap)
<marmelada>
from bp connector to idc
<marmelada>
is it right for to assume that everyone wants one with Kasli v1.1? that'll
<rjo>
marmelada: thanks for checking!
<hartytp>
marmelada: how much do they cost
<hartytp>
?
<marmelada>
hartytp: I'll ask, it'll probably depend on volume
<rjo>
marmelada: that gives me 22 K headroom instead of 7 K.
<rjo>
marmelada: assuming they are ~100 €, I'll buy 5
<rjo>
marmelada: i don't think every kasli needs one.
<hartytp>
we will always want one. Others may or may not, not sure. Probably depends a bit on price (if v.cheap we might as well include one IMHO)
<hartytp>
what I would like to do is supply Kasli with a PSU (eg wall wart with proper connector)
<hartytp>
that should avoid issues where users hook up a cheap/low power PSU and then ask for support!
<marmelada>
it should be cheap, small board, 4 layers, large tracks, few components and vias
<marmelada>
and everything is on one side
<sb0>
why does this bp adapter reduce temperature?
<marmelada>
once I receive an answer I'll write ob issure
<sb0>
or did I misunderstand something?
<marmelada>
sb0: :D
<marmelada>
robert asked me earlier on temperature grade of fpgas
<hartytp>
IIUC a chunk of the cost is testing, so maybe we can ship the BP adapter without full tests as it's trivial? Or, build a quick electronic test rig using a Kasli?
<sb0>
hartytp, we're having so many difficult bugs right now... do we really need less testing anywhere?
<hartytp>
true
<hartytp>
:)
<hartytp>
well, making a simple test setup with Kasli should be very easy
<rjo>
marmelada: btw. i found my old pcf8574a driver i had written a couple of weeks ago. will push that shortly.
<hartytp>
well, if that passes then it's just by luck
<hartytp>
that looks about as bad as anything I've seen
<marmelada>
ok
<hartytp>
but yes, I'll get on that gatware for you now
<rjo>
hartytp: i have received one sampler. the timeline in the contract is four months after hardware availability but i can imagine being done in a month if all goes well.
<hartytp>
rjo: ack. That's not a contract enforcement type question
<hartytp>
just asking so I know for planning
<hartytp>
sounds good
<rjo>
sb0: re SED. example code from #938. the rtio slack does a sawtooth between 13 and 25 ms corresponding to ~128 and ~256 events in the RTIO output FIFOs. is that expected? why does it sawtooth? (this is all independent of external_clock or not).
<rjo>
sb0: any chancce could you spend an hour spraying that sed code with comments? i estimate that would save me or someone else at least two hours doing that.
<sb0>
rjo, what area in particular needs comments?
<rjo>
LaneDistributor.
rohitksingh_work has quit [Read error: Connection reset by peer]
<GitHub-m-labs>
[artiq] hartytp commented on issue #908: I'm already building with 2017.4 and don't have 2016.4 installed. Is there a reason for me to stop and rebuild with 2016.4? AFIACT, all that matters is that you take my binaries and verify that there are no SI or PI issues, but that ARTIQ still gives bad eyes. That should show that this is not a HW problem, but actually a gateware/vivado/firmware/etc problem.... http
<GitHub-m-labs>
[artiq] hartytp commented on issue #908: So, unless @sbourdeauducq objects, I think that all you need to do @gkasprow @marmeladapk is to take the ARTIQ build that gives those bad eyes and:... https://github.com/m-labs/artiq/issues/908#issuecomment-370776252
<marmelada>
sb0: I connected urukul with ad9910 to ext6 and 7 (eem0->ext7 and eem1->ext6) and while running sysu variant I get Urukul proto_rev mismatch (I get 0 while 8 is expected) - which cpld code did you use?
<bb-m-labs>
build #748 of artiq-win64-test is complete: Warnings [warnings python_unittest] Build details are at http://buildbot.m-labs.hk/builders/artiq-win64-test/builds/748 blamelist: Robert Jordens <rj@m-labs.hk>, Robert Jordens <jordens@gmail.com>, Sebastien Bourdeauducq <sb@m-labs.hk>
<newartiq>
I have successfully run phaser on KC705 and get RF output by direct compiling. To set up phaser I used phaser bit file from Anaconda. However I am still not able to ping the board.
<newartiq>
hwid: USB VID:PID=0403:6010 SER=210203A01FA7 LOCATION=1-4.2:1.0
<newartiq>
desc: Digilent Adept USB Device
<newartiq>
/dev/ttyUSB0
<newartiq>
desc: Digilent Adept USB Device
<newartiq>
hwid: USB VID:PID=0403:6010 SER=210203A01FA7 LOCATION=1-4.2:1.1
<newartiq>
/dev/ttyUSB2
<newartiq>
desc: CP2103 USB to UART Bridge Controller
<newartiq>
hwid: USB VID:PID=10C4:EA60 SER=0001 LOCATION=1-4.3
<newartiq>
3 ports found
<newartiq>
I have checked all these ports
<sb0>
the one you should be using is ttyUSB2
<sb0>
note that this number will change when you replug the board or even reboot the computer
<sb0>
how did you get RF out?
<sb0>
startup kernel?
<newartiq>
It was the idle_kernel
<sb0>
ok
<sb0>
then you definitely have some serial output on ttyUSB2
<sb0>
while the board is booting, that is
<sb0>
also: is the ethernet link led on? did you configure the ip address? if not, have you tried pinging the default IP, while making sure that your network will route it?
<sb0>
newartiq, add yourself to the plugdev or dialout group
<newartiq>
File "/home/newartiq/anaconda3/envs/artiq-main/lib/python3.5/site-packages/asyncserial-0.1-py3.6.egg/asyncserial/asyncserial.py", line 43, in __init__
<newartiq>
File "/home/newartiq/anaconda3/envs/artiq-main/lib/python3.5/site-packages/asyncserial-0.1-py3.6.egg/asyncserial/asyncserial.py", line 16, in __init__
<newartiq>
File "/home/newartiq/anaconda3/envs/artiq-main/lib/python3.5/site-packages/serial/__init__.py", line 88, in serial_for_url
<sb0>
newartiq, yea yea I get it
<newartiq>
instance.open()
<newartiq>
File "/home/newartiq/anaconda3/envs/artiq-main/lib/python3.5/site-packages/serial/serialposix.py", line 268, in open
<newartiq>
raise SerialException(msg.errno, "could not open port {}: {}".format(self._port, msg))
<newartiq>
serial.serialutil.SerialException: [Errno 13] could not open port /dev/ttyUSB0: [Errno 13] Permission denied: '/dev/ttyUSB0'
<GitHub-m-labs>
[artiq] whitequark commented on issue #948: Exceptions are for exceptional control flow, not for arbitrary nonlocal jumps. As implemented, that is using the C++ zero-cost exception handling, the common case (normal control flow) is zero overhead, and more importantly, LLVM can optimize normal control flow without any regard to the exceptional control flow.... https://github.com/m-labs/artiq/issues/948#issue
<GitHub-m-labs>
[artiq] jordens commented on issue #948: Ack. It makes the usecase of reacting to exceptions with the usual speed (µs) impossible. I think it also means that any cleanup or rescue action (be it within the experiment or the idle kernel) is already 11 ms late before e.g. it can even start to try saving the ion by turning on cooling lasers. That's probably my biggest worry. https://github.com/m-labs/artiq/iss
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #949: Yes, that's pretty harmless - during link initialization the master keeps pinging the satellite on the aux channel until it is able to answer packets correctly, after which the link is declared up. What is happening is the satellite gateware receives a ping packet while the firmware is busy-waiting on the Si5324 lock, then another that causes an error as the buffer
<GitHub-m-labs>
[artiq] whitequark commented on issue #948: > I think it also means that any cleanup or rescue action (be it within the experiment or the idle kernel) is already 11 ms late before e.g. it can even start to try saving the ion by turning on cooling lasers. That's probably my biggest worry.... https://github.com/m-labs/artiq/issues/948#issuecomment-370814373
<GitHub-m-labs>
[artiq] whitequark commented on issue #948: I think the right thing to do if you really need µs-scale exception handling is to go the CPS route, since it can be seen as the generalization of the callback technique I just proposed. But I'm very worried about the impact on backtraces. It's also a rather substantial change to the compiler. https://github.com/m-labs/artiq/issues/948#issuecomment-370815594
<marmelada>
sb0 or rjo: is urukul cpld 1.1 and artiq compatible with urukul v.1.1?
<sb0>
fwiw the urukul 1.1 worked fine when I tried it
<GitHub-m-labs>
[artiq] klickverbot commented on issue #948: 11 ms is still almost one and a half million cycles – DWARF does take some time to parse, variable-length integers and all, but that still seems like a lot? https://github.com/m-labs/artiq/issues/948#issuecomment-370818675
<sb0>
how do I relock the si5324 after switching the clock using an external mux? enter and leave digital hold?
<sb0>
it would relock by itself I guess, but I want to monitor the lock without race condition
<GitHub45>
[smoltcp] dlrobertson commented on pull request #177 0967bfc: nit: seems strange to me to have the module named `igmpv2` but the exported structures and enums named `Igmp<Something>`. Would it make sense to just leave the module named `igmp` since we're not going to allow `Igmpv1Packet`, `Igmpv2Packet`, etc? https://github.com/m-labs/smoltcp/pull/177#discussion_r172553826
<GitHub-m-labs>
artiq/siphaser 8763733 Sebastien Bourdeauducq: drtio: implement Si5324 phaser gateware and partial firmware support
<_florent_>
rjo: i want to do some test on sayma3 for jesd sc1 but get "cannot load RTM FPGA gateware: "Did not assert INIT in reaction to PROGRAM", what should i do?
<sb0>
_florent_, comment out the part that attempts to load the rtm fpga
<_florent_>
sb0: ok thanks
<sb0>
_florent_, that being said the ddr3 issue has much more impact at the moment
<_florent_>
sb0: i know
<_florent_>
sb0: i'll try to investigate this week
<_florent_>
sb0, rjo: in case any of you get a bistream where ddr3 fails on our boards, can you keep it and send it to me? (with all the files generated by vivado if possible)
<marmelada>
_florent_: can I just enclose this if..else in loop{ }?
newartiq has quit [Ping timeout: 260 seconds]
<travis-ci>
[rust-managed] astro opened pull request #7: Catch insert() on ManagedMap with zero-sized backing store (master...catch-zero-sized-managedmap) https://github.com/m-labs/rust-managed/pull/7
<_florent_>
marmelada: yes
<_florent_>
sb0: is there the 1.2Ghz clock input on sayma3?
<sb0>
_florent_, no, it's 100MHz and going through the hmc830, I can reconnect it tomorrow
<_florent_>
sb0: is the hmc830 working sometimes (ie is it worth i do some tests with it?)
<rjo>
marmelada: clk_sel?
<sb0>
very rarely, and it's unclear whether it produces a valid clock when it declares lock
dlrobertson has quit [Read error: Connection reset by peer]
dlrobertson has joined #m-labs
dlrobertson has quit [Ping timeout: 248 seconds]
dlrobertson has joined #m-labs
dlrobertson has quit [Read error: Connection reset by peer]
dlrobertson has joined #m-labs
<GitHub-m-labs>
[artiq] hartytp commented on issue #908: @gkasprow okay, good, so the 1v5 rail isn't the cause of the bad eyes with artiq. Are there any other rails we need to check? 1v8 for the fpga? https://github.com/m-labs/artiq/issues/908#issuecomment-370933693
dlrobertson has quit [Read error: Connection reset by peer]
dlrobertson has joined #m-labs
RexOrCine has quit [Ping timeout: 240 seconds]
Rex0r has joined #m-labs
dlrobertson has quit [Ping timeout: 260 seconds]
dlrobertson has joined #m-labs
cr1901_modern has quit [Read error: Connection reset by peer]