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
<GitHub150>
[smoltcp] astro opened pull request #172: Send multicast to the right ethernet addresses (master...send-multicast) https://github.com/m-labs/smoltcp/pull/172
<GitHub-m-labs>
picam/master 663dfcb whitequark: Add an LD_PRELOAD interceptor to avoid the need for /var/run/pits.
<whitequark>
sb0: this camera SDK is very troublesome
<whitequark>
I still haven't found a way to give it an IP explicitly, and it looks like their proprietary kernel module (that doesn't even build on recent kernels) is mandatory
<sb0>
whitequark, yes, it is for dealing with this kind of crap that we have the controller mechanism in artiq
<whitequark>
things like "install process that places garbage all around your system and can't even place symlinks correctly" are implied
<sb0>
run a VM with just the controller and whatever kernel the crappy driver requires
<whitequark>
sb0: how about supporting it ONLY on windows?
<whitequark>
I think that will be much more realistic.
<whitequark>
I've spent two days just figuring out the dynamic linker magic required to load all of its junk on Linux
<sb0>
could be a plan, I suppose the opticlock computer can run a windows vm, rjo ?
attie has quit [Ping timeout: 252 seconds]
<whitequark>
rjo: that or I need root on vettel.ptb.quartiq.de
<sb0>
whitequark, or do they have a "recommended" linux distro?
<whitequark>
to even start
<whitequark>
sb0: not that I can see
<sb0>
what is that kernel module doing?
attie has joined #m-labs
<whitequark>
it's some undocumented monstrosity
<whitequark>
well, it's related to ethernet and udp, that's all i can say with certainty
<whitequark>
can't reverse-engineer it, the object files break my interactive disassembler
attie has quit [Ping timeout: 265 seconds]
attie has joined #m-labs
rohitksingh_work has joined #m-labs
attie has quit [Ping timeout: 248 seconds]
attie has joined #m-labs
mithro has quit [Read error: Connection reset by peer]
futarisIRCcloud has quit [Read error: Connection reset by peer]
Ishan_Bansal has quit [Read error: Connection reset by peer]
_florent_ has quit [Ping timeout: 255 seconds]
futarisIRCcloud has joined #m-labs
mithro has joined #m-labs
Ishan_Bansal has joined #m-labs
_florent_ has joined #m-labs
<davidc__>
whitequark: link to IDA-breaking-object-files? (I have another plane ride coming up to kill)
<whitequark>
IDA? nah it breaks binaryninja
<whitequark>
I think BN just doesn't handle relocatable files properly
<whitequark>
though that's weird
<whitequark>
I don't have an IDA license, where would I get one? :]
<davidc__>
dunno, some of those piles of artiq-related monies? :P
<davidc__>
whitequark: sure its not a standard GIGE vision device? there are a few RE'ed/open sourced drivers for the GIGE vision protocl
<whitequark>
davidc__: it should be a GigE vision device
attie has quit [Ping timeout: 256 seconds]
attie has joined #m-labs
<davidc__>
whitequark: eh, if you just need to grab frames on command; you might be able to avoid the driver altogether
<whitequark>
davidc__: I've considered this before and rejected it
<whitequark>
it has a rather complicated set of controls, and only the driver knows which protocol integers these map to
<whitequark>
I've also tried to reverse-engineer the driver itself and it is an absolute C++ hellscape
<whitequark>
written by one of those people who think that you can never have too many templates and constexprs
<davidc__>
yeah fair enough. I didn't know whether the controls mattered
<davidc__>
I know on my GIGE vision camera, I can write all the settings to internal flash, so it'll always come up in the mode i expect
<davidc__>
I have no idea if that camera behaves anywhere near similar.
<whitequark>
I don't actually know how many of the controls need to be exposed
<whitequark>
sb0? rjo?
<sb0>
whitequark, dunno. try to grab a frame with the default settings to begin with.
<whitequark>
sb0: what is the goal for this camera driver exactly?
<whitequark>
is there some spec?
<sb0>
whitequark, this camera will be used to track the position of the ion (and fix the shape of the electric field if required), and check if ion loading was successful with only one ion in the trap
<sb0>
rjo likely has more detailed specs.
<whitequark>
right, I guessed that much
attie has quit [Ping timeout: 268 seconds]
attie has joined #m-labs
<sb0>
rjo, why not use the same format as the runtime image (i.e. with crc) for the rtm gateware image in flash?
<rjo>
whitequark: start with getting a frame at default settings.
<sb0>
rjo, on Florent's board all the resistors near J5 are removed as per the picture. on the other two boards they are selectively removed as per Greg's screenshot
<rjo>
whitequark: the people at pco are responsive and helpful IME, i would recommend checking a viable path forward with them.
<rjo>
whitequark: getting root on vettel is not an issue. but running a vm seems excessive.
<rjo>
whitequark: i am happy to help talking to the pco people.
<sb0>
rjo, R176 is also removed on the other two boards
<rjo>
sb0: you mean the other boards have the desired configuration?
<sb0>
rjo, yes
<rjo>
ok. could you set m[2:0]=0b111 on sayma-3-rtm then (r112/r116)?
<sb0>
so as they are connected: sayma-1 is supposed to work, and sayma-3 is supposed not to
<sb0>
sayma-3 is Florent's board and has all the resistors near J5 removed
<rjo>
sb0: ah. florent's == sayma-3?
<rjo>
ok.
<sb0>
rjo, idk if the remaining resistors R200-204 are 0R, should I measure them?
<rjo>
sb0: i have tested extensively on sayma-1. it reacts adequately to PROGRAM (INIT and DONE behave correctly). i checked the bitstream, the bit sequence, the bytes, the clock speed and the "special startup conditions" stuff.
<rjo>
sb0: they are DNP in the schematic. i.e. they should have been moved from the other set of 5.
<rjo>
sb0: could you review the code?
<rjo>
sb0: i didn't go for the fbi format because the checksum is not needed and then there didn't seem an advantage left in re-implementing that code again.
<rjo>
sb0: but i'm not opposed to using that format if it helps. but the lack of a magic seems like a bad choice.
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #854: > TP-Link MC220L. Board detects a link but IIRC no packets go through. The LINK LED on the media converter is useless as it is just a SFP module detection.... https://github.com/m-labs/artiq/issues/854#issuecomment-369856123
<sb0>
rjo, according to Greg R200-R204 should be jumpers
<sb0>
it's R176-R180 that should be removed
<sb0>
rjo, we plan to encode the fbi images in artiq_flash; then the same code could be used.
<rjo>
sb0: then i'd add a name or magic field to the header as well to protect against mixup of addresses. but it's just a handful lines of code. and since whitequark also wanted to implement a more general partitioning scheme iirc that should all be done in a single sitting.
<sb0>
iirc the general partitioning scheme was dropped
<rjo>
sb0: but crc+length seems inferior to name/id/magic+length in the case of rtm_gateware. if we unify them, we should change both formats.
<sb0>
ok
<sb0>
not sure if name is useful if there's already the magic
<cjbe>
sb0: The si5326 does not seem to specify a fixed phase relation between input and output, does it? From my reading the only additional feature is a built in phase-shifter
attie has quit [Ping timeout: 245 seconds]
attie has joined #m-labs
<sb0>
cjbe, my understanding is you get a random but fixed phase shift upon power-up, and you can tune it
<sb0>
it's not too difficult to do such tuning with the FPGA: take the input clock, phase-shift it with a MMCM and use that to sample the output clock. then play with si5326 the phase shift control.
<cjbe>
sb0, that is my understanding too
<cjbe>
that sounds like a pretty reasonable plan
<sb0>
I've ordered a si5326 and will implement it
<rjo>
how will that accuracy give you deterministic phase? i don't see that.
<cjbe>
this will align RTIO clocks to much better than 1ns, but not be good enough for RF phase syncronisation
<sb0>
this is tuning the si5326 skew to match the fixed MMCM skew
<sb0>
cjbe, rjo, what is "cheap" about the current 114... MHz crystal on kasli?
<sb0>
maybe I should replace it with a better quality crystal?
<sb0>
what's the current P/N?
<cjbe>
no temperature compensation - we replaced our with a Crystec TCXO
<cjbe>
pn CS-023-114.285M
<sb0>
I'm still surprised there is so much low-frequency phase noise
<cjbe>
(is currently on the Kasli)
hartytp has joined #m-labs
<hartytp>
sb0: for this kind of flywheel oscillator you really want a high quality oscillator
<hartytp>
something OCXO quality
<hartytp>
we're using a really nice crystal XO that Weida found
<hartytp>
crystek (damn autocorrect)
<sb0>
and did the phase wander go away?
<hartytp>
substantial reduction
<hartytp>
there are several things wrong with the current design
<hartytp>
weida is working on a replacement
<hartytp>
the big question I have about this is "can we fix the rtio frequency?"
<hartytp>
If we can agree to only support a single RTIO frequency (say, 125MHz) then we can get a much better solution
<sb0>
hartytp, but do you think there is still something to be done with the si5326?
<hartytp>
that would mean agreeing to get Sayma to work at 125MHz frtio at some point, which I want to do anyway
<hartytp>
having to support 150MHz and 125MHz gives us fewer good options for how we do the clock recovery
<hartytp>
performance and flexibility are kind of conjugates
<hartytp>
and it's such a major decision that we can't really do much design work without deciding that
<sb0>
at least it'll get the current hardware to do something useful
<hartytp>
well, you might get something out of it, but from the quick tests we did, you're always going to have wander at the >ns level with few deg temperature shifts and that kind of setup
<hartytp>
in any case, the XO we used didn't fit in the pads, it was dead bugged on
<hartytp>
much larger than the xtal
<sb0>
hartytp, and that's not something that can be solved with e.g. socketed OCXOs?
<sb0>
hartytp, I'm surprised that the wander is so high
<hartytp>
why?
<hartytp>
think about how frequency v temperature changes turn into phase versus temperature when the loop doesn't have much bw
<sb0>
okay. the 5326 has higher loop bw
<sb0>
up to 8.4kHz
<hartytp>
that will help, but probably not enough for the long term
<hartytp>
and, then, it's not really doing much in any case
<hartytp>
(the HMC830 on Sayma RTM is 100kHz BW)
rohitksingh_work has quit [Ping timeout: 256 seconds]
<sb0>
okay, well it's 60Hz-8.4kHz
<sb0>
if an ocxo doesn't fit on the kasli pcb, it can be mounted externally on the SMA...
<hartytp>
sb0: dead bug is fine
<hartytp>
lots of space, easy rework
<hartytp>
(solder the screening can of the XO onto a ground pad on the pcb and run a wire to the xtal pad)
<hartytp>
my point is really that if we're going to add a dead bugged XO then why not just add a dead bugged PLL
<hartytp>
we can do up a small PCB with new PLL + XO + LF and bodge it on to Kasli
<hartytp>
seems like a better option than hacking around with the Si5xxx, which still doesn't seem like a good long-term solution
<hartytp>
once we all agree on the rtio frequencies we need to support, we'll do up a design (do simulations etc) and order some PCBs
<sb0>
well. the 5326 hack should be quick, both in code (all registers are the same as the 5324) and in hardware, and should get the hardware going to << 1ns
<sb0>
(unless I'm underestimating the crystal stability issue)
<hartytp>
well, have a look at it on a scope
<hartytp>
and see for yourself
<hartytp>
but, my guess is that you're not going to get <<ns with any reliability (e.g. lightly touch it/fan some warm air over it/breath on it) with an Si chip and Xtal as reference
<hartytp>
but, if you can make that work then great!
<hartytp>
if you look at the wr pages they did a lot of measurements on exactly this
<hartytp>
and were very careful over the choice of flywheel oscillator
<hartytp>
their "soft" PLLs are also really carefully designed, taking into account the DAC flicker noise and ensuring it doesn't degrade a high quality XO
<hartytp>
not the case with the Si5xxx, which has pretty poor performance
<sb0>
hartytp, okay.
<sb0>
so, if we have a nice PLL, do we need external clocking at all?
<sb0>
if we don't, that would make inter-card DAC synch easier on sayma
attie has quit [Remote host closed the connection]
attie has joined #m-labs
<hartytp>
ideally no, we don't
<sb0>
ah, that would be great
<hartytp>
but, we'd have to get to the point where we can prove that the recovered clock works reliably enough over a decent range of conditions
<hartytp>
but, yes, I strongly agree with the basic point: if DRTIO can distribute really high quality clocks there is a lot of cool stuff one can do
<hartytp>
anyway, like I said, first we need the specification for the supported RTIO frequencies, then we can produce a proposal
<sb0>
hartytp, what parts of the design are frequency-dependent?
<hartytp>
FWIW, I'm really not comfortable with allowing a data converter board like Sayma to fix the rtio frequency. not a scalable approach (what about the next data converter board with a funny frequency requirement)
<hartytp>
sb0: we probably want to choose a fixed-frequency OCVCXO at the rtio frequency
<hartytp>
and develop around taht
<hartytp>
that
<sb0>
right, but that XO can be socketed
<hartytp>
sb0: in principle, yes
<hartytp>
but, in practice, the really good crystals are only available at certain frequencies
<hartytp>
e.g. the best ones are at 10MHz
<hartytp>
so for 150MHz we'd probably use a 10MHz crystal as our flywheel
<hartytp>
with a 15:1 prescaler
<hartytp>
for 125MHz we need to do something different
<hartytp>
(150MHz crystals aren't as good as 10MHz or 125MHz in general)
<hartytp>
unless you want to spend a lot of money and order large batches of custom OCVCXOs you really have to live with what's commonly available and work around that
<hartytp>
so, the whole architecture you choose relies on the frequency
rohitksingh_work has joined #m-labs
<sb0>
I see
<hartytp>
tbh it's a general engineering thing: the more tightly you specify things, the better/simpler/cheaper your design ends up
<hartytp>
"we want all the frequencies with all the performance" tends not to work
<sb0>
yeah sure, that's why we reduced the list of supported sayma frequencies already
<hartytp>
if we *need* to support multiple rtio frequencies then we can work around that constraint
<hartytp>
but, let's make sure we really do need that
<hartytp>
and, as I said, I still think that the only scalable approach is to pick a rtio frequency and design all the hw to work with it
<hartytp>
otherwise, we're going to end up in a mess in the long run
<hartytp>
also, 150Mhz is obno
<hartytp>
obnoxious
<hartytp>
(can't have 1GHz on urukul, no nice rounding to ns etc)
<hartytp>
and, my feeling is still that the 125MHz RTIO/1GHz DAC clock is a much better fit to most ion trap use cases than the current 150MHz rtio/600MHz DAC clock
<hartytp>
I can think of lots of times where the improvement in carrier frequency is helpful
<hartytp>
but not really any where the baseband bandwidth is an issue (ion trappers don't tend to apply tones separated by more than about +-10s of MHz at the same time, so +-125MHz IQ BW should be more than enough for all applications I can think of)
<sb0>
cjbe, did you put a better XO on both the master and satellite, or only the satellite?
hartytp has joined #m-labs
<hartytp>
just the satellite
<sb0>
ah. so the master could also be the source of the wander.
<cjbe>
sb0, we were looking at the phase difference between the master si output and the slave si output
<cjbe>
so we are measuring how well the slave tracks the master si output
<sb0>
yes, but if the slave oscillator is stable and with a low loop bandwidth, and the master is unstable, the result is the same when viewing the phase difference
<sb0>
what I'm trying to determine is, if we put high-quality clocks both on master and satellite, and a small hw mod (change to 5326), do we get a nice system or not
<cjbe>
sb0, I also tried running the master off a nice 150 MHz clock, and did not see a change in how well the slave locked to the master
<sb0>
with the 5324 bypassed I assume
<cjbe>
sb0, I believe so, but am not confident
<hartytp>
sb0: as a short term solution to get current hw up and running, that could work if you combine it with a PLL inside the FPGA to remove the slow phase wander
<sb0>
the slow phase wander cannot be corrected by the FPGA I think
<sb0>
but the 5326 has chances of dealing with it
<hartytp>
ack
<hartytp>
well, I don't see that as the correct long-term solution but definitely sounds worth a go for getting things up and running
rohitksingh_work has quit [Ping timeout: 260 seconds]
rohitksingh_work has quit [Ping timeout: 260 seconds]
attie has quit [Ping timeout: 268 seconds]
attie has joined #m-labs
<GitHub-m-labs>
[artiq] hartytp commented on issue #854: any thoughts @gkasprow? Can you try one of those media converters on your Sayma with the Xilinx core to verify that it's not a HW/MMC problem? https://github.com/m-labs/artiq/issues/854#issuecomment-369905782
<rjo>
whitequark: s/PCO/Princeton Instruments/ in what i said above.
rohitksingh_wor1 has quit [Read error: Connection reset by peer]
<GitHub-m-labs>
[artiq] gkasprow commented on issue #854: @hartytp I know this problem because we had one in the past. It is related probably with PAUSE setting I described before. By default the PAUSE negotiation is disabled so enabling it should solve the issue. I didn't have time to investigate it. https://github.com/m-labs/artiq/issues/854#issuecomment-369917421
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #854: During autonegociation, the Ethernet core in Kasli says it wants nothing to do with PAUSE, and this seems to work fine. Also I did the test with a rather low packet rate (dozen per second) so there should be no PAUSEs. https://github.com/m-labs/artiq/issues/854#issuecomment-369918210
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #854: During autonegotiation, the Ethernet core in Kasli says it wants nothing to do with PAUSE, and this seems to work fine. Also I did the test with a rather low packet rate (dozen per second) so there should be no PAUSEs. https://github.com/m-labs/artiq/issues/854#issuecomment-369918210
<rjo>
whitequark: the camera also doesn't react to "10.32.4.1 → 255.255.255.255 GVCP 50 > DISCOVERY_CMD" from aravis
attie has quit [Ping timeout: 260 seconds]
attie has joined #m-labs
<whitequark>
rjo: yes, I also straced it and found that it wants the device
<whitequark>
and more importantly doesn't try to send anything via regular sockets
<GitHub-m-labs>
[artiq] sbourdeauducq commented on issue #941: The difficulty with this (and the other issue) is when do we consider DRTIO to be operational. When all links that are defined at compile-time are up? https://github.com/m-labs/artiq/issues/941#issuecomment-369990458
<rjo>
whitequark: if we ultimately conclude that it's going to be either the kernel module or windows, then i think i'd go for a linux kvm recipe.
<whitequark>
rjo: okay
<whitequark>
so, did you give me root on vettel?
<rjo>
whitequark: don't you just need to be in libvirt and libvirt-qemu?
<rjo>
whitequark: i am happy to give you root as well if you say you need it. but this can't be where everybody just hacks his way through and shrugs shoulders when something breaks and nobody feels responsible.
<whitequark>
rjo: I was going to run the module non-virtualized first, because the docs for pleora say that you need some obscure configuration if you're not on the same subnet
<whitequark>
it shouldn't matter if I bridge the interfaces but I'm not in the mood to guess which part of the whole stack broke when it inevitably doesn't work
<whitequark>
anyway, if you looked at the repository, you've seen that I did hack my way through--namely I worked around the need to install the drivers globally
<whitequark>
so it's not like anything can break.
<rjo>
whitequark: br01 is the bridge.
<rjo>
whitequark: right now, i can't recover from the module crashing the kernel on that machine.
<whitequark>
can't as in?
<rjo>
well i'd have to call someone.
<rjo>
whitequark: you'll have to port some of the module wrapper API anyway or use an older kernel in a vm.
<whitequark>
sure, I'll have to port it if you say we should use Linux.
<whitequark>
what about setting the kernel panic_timeout variable?
<rjo>
what's the problem with doing it in a vm again?
<whitequark>
when it doesn't work, I don't know whether the problem is the driver or the VM.
<rjo>
i don't get the downside. if it doesn't work on the host, then you don't know whether it's the driver or the kernel. and you can swap kernel easily on a vm. and once you are at a point where "you don't know whether it has to do with being in a vm" then i am happy to try the recipe you have on the host.
<rjo>
that's on top of the vm advantages here: you get readable panics, you get to try redhat if needed, you get a way to make the recipe idempotent.
<whitequark>
I doubt I'll have any panics, but okay
<rjo>
you can even run the picam installation script blindly without anyone getting annoyed by the system being messed up.
<whitequark>
why would I ever want to run their installation script? it doesn't work
<rjo>
whitequark: i'd actually consider doing that (redhat/old ubuntu+picam as shipped)
<rjo>
whitequark: does it not work at all? my impression was that it breaks a couple of other things but ends up putting its libs in places where it finds them.
<whitequark>
when I ran it on my system it didn't put the libraries in the search paths and it didn't create most of the necessary symlinks
<rjo>
and in that case we want to talk to princeton anyway. i'll do that next week, escalate the issue through the various support levels, and explain to them what we'd like to do. ok?
<whitequark>
I'm not convinced we should rely on their system-wide installation process in the first place
<whitequark>
it's pretty straightforward to use the libraries as unpacked
<rjo>
whitequark: if you go the libvirt route, take space from the vettel-vg LVM VG and just hook into br01. there is dnsmasq running on br01.
<rjo>
whitequark: i agree. if that works it would be great. then it's only about the kernel module.
<whitequark>
I'm not in the lvm group. how are you suggesting I touch LVM?
<rjo>
whitequark: i think libvirt does that for you.
<whitequark>
hm, never used it before
<whitequark>
you're using virsh for managing VMs, right?
<rjo>
whitequark: and btw, there are newer versions of that pleora sdk available if the kernel module causes problems.
<rjo>
whitequark: i can make you a vm if you want
<whitequark>
well no, I should probably understand how the entire stack works here
<whitequark>
I'm just asking what are you using so I can learn it
<rjo>
whitequark: i'm using virt-install
<whitequark>
The program 'virt-install' is currently not installed. To run 'virt-install' please ask your administrator to install the package 'virtinst'
<GitHub-m-labs>
[artiq] jbqubit commented on issue #908: @enjoy-digital Could you reproduce @hartytp's success? If this is a workable solution for the near term please add use of ddram_32 to master. https://github.com/m-labs/artiq/issues/908#issuecomment-370074249
attie has quit [Remote host closed the connection]