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
sb0 has joined #m-labs
<sb0>
cr1901_modern, BusSynchronizer simply guarantees that all the bits it synchronizes form a valid word
<sb0>
if you have a multi-bit MultiReg, there is an uncertainty of one cycle (independently for each bit) in the source domain, or you even get comb glitches
<sb0>
BusSynchronizer is a MultiReg with some control logic around it
<sb0>
that removes the per-bit uncertainty
<sb0>
whitequark, what is the preferred connection for a needle valve that can put helium or argon into the vacuum chamber?
<sb0>
some swagelok thing?
<whitequark>
personally I would use swagelok vcr
<sb0>
do we have the necessary hardware to hook up the current gas bottles to that?
<whitequark>
yes. including a needle valve.
<whitequark>
and I have weldable vcr stubs as well
<sb0>
you have a needle valve as well?
<whitequark>
sure
<whitequark>
and it already has VCRs on it
<sb0>
ideally it would have a VCR on one end and KF25 on the other
<whitequark>
this is because extern fn i2c_read(busno: i32, ack: bool) -> i8
<sb0>
we'll need both, helium to test the mass spectrometer and argon for venting
<sb0>
there are also cheapo KF25 to rubber hose adapters... and chinese all KF25 needle valves all for ~$70
<whitequark>
and the ARTIQ Python code exects a TInt32
<sb0>
ah, right. sorry about that. but i2c was already broken before so I didn't see that new bug
<whitequark>
I'm pretty sure it wasn't because I specifically tested it...
<whitequark>
there might have been some other change in between?
<whitequark>
whatever. let me just fix it.
<whitequark>
as for the needle valves. if you want to buy it, sure, sounds like a plan, given how exensive the VCR<>KF adater is
<sb0>
iirc i2c stopped working on the buildserver (but not when you ran that test yourself) as soon as you rewrote it in rust
<whitequark>
could it have also been related to lwip?
<sb0>
for the swagelok option, would it be all metal pipes from the gas bottle?
<whitequark>
capillary.
<whitequark>
I have about 100' of capillary for this purpose
<GitHub158>
[pythonparser] whitequark pushed 1 new commit to master: https://git.io/vMAWu
<GitHub158>
pythonparser/master a82d05d Dylan Trotter: Correct the order of elif clauses in the AST....
<GitHub38>
[pythonparser] whitequark closed pull request #8: Reverse the order of elif clauses in ast (issue #7) (master...master) https://git.io/vMAJA
<sb0>
hmm
<sb0>
fancy
<whitequark>
not really, it's a very cheap option
<whitequark>
the capillary is rated for like dozens of atm. rubber hoses not so much, and so annoying to use.
<whitequark>
you can even skip the needle valve and just squish the capillary directly.
<sb0>
we specifically don't want dozens of atm in the vacuum chamber
<whitequark>
in case of helium rubber isn't really an option if you want to run it for more than minutes afaik
<sb0>
better have the rubber hose pop than the chamber blow up
<whitequark>
uhm, no, it wouldn't work like that
<whitequark>
KF connections are rated at, iirc, 0.5atm overpressure max? and the windows aren't probably much better
<whitequark>
this is still way below where the rubber hose would go
<sb0>
KF can take something like 6 atm of overpressure iirc
<sb0>
but yes, the windows would pop easily
<whitequark>
could be worth investing in a safety valve regardless
<whitequark>
just the regular silver solder. I have a stick or two still
<sb0>
won't this outgas crap into the chamber?
<sb0>
potentially worse than the rubber does?
<whitequark>
how so?
<sb0>
what solder is it?
<sb0>
we'll have to purge the line, at which point it is at a low pressure and crap can easily boil off
<whitequark>
the solder is AgCuZn
<whitequark>
why can't you purge it with argon/helium?
<whitequark>
actually, why *would* you even purge it under vacuum?
<sb0>
how do you plan on connecting it?
<whitequark>
connecting what to what?
<sb0>
the gas pipe to the valve
<sb0>
at this point, the gas pipe will be full of air that needs to be removed
<whitequark>
capillary → FVCR nipple → valve. then open the valve for a while.
<whitequark>
(on the bottle)
<sb0>
wouldn't evacuating the gas pipe be better (less impurities), with faster turnarounds when connecting/disconnecting the bottle, and less wasteful of gas? it's just a couple extra cheap vacuum valves
<whitequark>
it will be extremely slow
<whitequark>
needle valves in particular, and thin pipes in particular, are really not designed for evacuating them to high vacuum levels
<whitequark>
like you'll have serious trouble even evacuating a 1/4" pipe
<whitequark>
but the main issue here is the needle valve, of course.
<sb0>
hmm
<whitequark>
actually, scratch high vacuum
<whitequark>
this is an issue even in my aircon systems, where I only go to like a dozen torr
<sb0>
we can have a needle valve bypass, but the plumbing begins to add up
<whitequark>
yes. I don't think people actually do this.
<whitequark>
what impurities are you thinking of ?
<sb0>
leftover air, humidity
<whitequark>
oh btw also not all gas hoses are vacuum rated. some will collapse.
<sb0>
mostly humidity
<whitequark>
imo the answer is to avoid changing the gas bottles.
<sb0__>
oh so i2c is working again, that was just the i8 bug?
<whitequark>
yes
<whitequark>
now looking into DDS
<whitequark>
I found another smol tcp/ip bug meanwhile
<whitequark>
I don't see any easy way to eliminate the remaining soft-FP from the DDS test
<sb0__>
how did it work before?
<whitequark>
uhm, it didn't. it crashed lwip.
<whitequark>
it started crashing lwip immediately after the rewrite
<whitequark>
as for "before the migration to ARTIQ Python", the compiler had a little bit more freedom to optimize the DDS code because the intrinsics were marked as nowrite
<whitequark>
this let LLVM reorder FP stuff and hoist it out of loops
<sb0__>
ffs airplane internet is blocking ssh
<sb0__>
whitequark, can you go to /opt/Xilinx/Vivado and rename crashes-2016.4 to 2016.4?
<whitequark>
done
<sb0__>
thx
<GitHub56>
[migen] sbourdeauducq pushed 1 new commit to master: https://git.io/vMAr0
<GitHub56>
migen/master 3f5a907 Sebastien Bourdeauducq: build: work around Vivado 2016.4 crash in Verific::veri_file::IncludeFileName
<sb0__>
you can cancel the build if you're using the kc705 right now
sb0__ has quit [Read error: Connection reset by peer]
<GitHub14>
[artiq] sbourdeauducq commented on issue #652: This is becoming an annoying issue now that Anaconda installs 3.6 by default. This breaks ARTIQ 2.x as well. https://git.io/vMAKY
<GitHub134>
[smoltcp] whitequark pushed 1 new commit to master: https://git.io/vMAKc
<GitHub134>
smoltcp/master 9aebbff whitequark: Fix the TCP ACK handling in FIN-WAIT-1 state with queued data.
<travis-ci>
m-labs/smoltcp#55 (master - 9aebbff : whitequark): The build passed.
<cr1901_modern>
sb0: What confuses me about BusSynchronizer, from analyzing it, is that it appears the number of (dest) clock cycles that it takes for data to appear in dest domain varies depending on BusSynchronizer's internal state (a "token" pulse that's passed between ping and pong)
<whitequark>
sb0: I might have found a way to fix the DDS slowness...
hedgeberg has joined #m-labs
<hedgeberg>
hi guys, is anyone here atm?
<hedgeberg>
im wondering how difficult it would be to port ARTIQ to a Virtex IV platform, im out of touch with python and generally confused
<hedgeberg>
i do a lot of verilog/systemverilog design, but i have no idea what is going on or how exactly python is being compiled to target FPGA's
<hedgeberg>
so i was wondering if someone would be willing to give me a quick rundown of what's going on so i can figure out what would be involved
<hedgeberg>
have some ideas of what i'd need to do but not nearly the full understanding
<hedgeberg>
if someone could respond when they get a chance, i'll stick around and make sure I log this chan on ZNC so i catch it in case you respond while im asleep
<hedgeberg>
ty all so much
kuldeep_ has quit [Remote host closed the connection]
kuldeep_ has joined #m-labs
sb0 has joined #m-labs
<whitequark>
hedgeberg: in case of migen, python isn't so much being compiled to verilog; rather i would describe this as python being used to describe what verilog code to generate
<whitequark>
migen itself isn't really specific to any FPGAs. misoc is ported to quite a few FPGAs and toolchains, and will need a port to virtex iv
<sb0>
whitequark, this is still with the old migen right? since the conda garbage is broken
<whitequark>
hedgeberg: artiq instantiates some primitives directly, so that code will have to be ported over.
<whitequark>
sb0: what "this" ?
<whitequark>
oh the crash? yeah
<sb0>
the vivado bugware crashing
<sb0>
you can rename the folder to crashes- until conda works... sigh
<whitequark>
*stare*
<hedgeberg>
this sounds...
<hedgeberg>
messy
<hedgeberg>
what happened to conda?
<whitequark>
it's broken by design. well if you ask me.
kuldeep_ has quit [Remote host closed the connection]
<hedgeberg>
thats always fun :I
<whitequark>
but right now it's broken slightly more than usual.
kuldeep_ has joined #m-labs
<hedgeberg>
although tbh your definition of broken by design and mine /might/ be a little different
<hedgeberg>
most of the stuff i do for hobby work is 3ds hacking atm and if you think what youre building is broken by design you should see some CFW's that scene builds
<whitequark>
in this particular case: all decent package managers have "lockfiles"
<sb0>
hedgeberg, recent vivado segfaults when compiling artiq, I pushed a workaround to migen, but now conda can't build it anymore since python 3.6 packages have been pushed
<whitequark>
this allows to reproduce the environment you use in development on your CI and (if desired) deploys exactly
<whitequark>
conda doesn't really have a functional equivalent to that.
<whitequark>
that said. 3ds modding is like three people hacking in a closet. the developers of conda have the nerve to charge others money for this nonsense.
<hedgeberg>
i mean vivado, like all xilinx software, is garbage, so im not exactly surprised
<sb0>
the migen package tells it to use python 3.5, but instead of respecting that it prefers to insist on installing 3.6 and crapping out
<hedgeberg>
whitequark, more like 60 people begging for scraps while hoping a few competent assholes release their work, but point taking
<hedgeberg>
*taken
<whitequark>
sb0: good news. figured out what's up with the loopback test.
<whitequark>
that's an LLVM patch going to upstream
<sb0>
great
<whitequark>
I think that slightly improved pulse_rate_dds but only slightly. so that's still open
<hedgeberg>
anyway guys, ty for help, cool if i lurk until i get time to work on porting?
<sb0>
sure
<sb0>
what do you plan on using artiq for btw?
<hedgeberg>
I may also want to work on porting to zynq-7000 SoCs as a basis instead of pure fpga, but that feels like it would be much more of a pain in the ass
<hedgeberg>
im interested in the potential for chip environment glitching
<sb0>
oh, did scanlime tell you about it?
<hedgeberg>
scanlime speculated the idea, but she's got money to get a kintex 7k board
<hedgeberg>
she posted on twitter :P
<hedgeberg>
my 3ds work is glitching to extract bootrom
<hedgeberg>
id like to get a more... robust setup before switch rolls out
<hedgeberg>
saw it, looked into it, thought it sounded great both for glitching and for actual professional work
<hedgeberg>
my professional work is electron device physics so there's a good chance having this understood could be super useful in coming years
<hedgeberg>
so, figured id dive in when i get a chance
<cr1901_modern>
sb0: How did your meetings go?
<sb0>
hedgeberg, re. zynq ports. yes, it's a pain in the ass (dealing with xilinx software and designs) but also the latency between the ARM core and the fabric seems to be quite high and would impact RTIO performance
<sb0>
I'd be curious to see how well it performs if you try. if you want to benchmark that you could simply put the RTIO core into a simple Zynq design and run a C routine that mimics what a kernel does
<hedgeberg>
hmmmm
<hedgeberg>
yeah, had forgotten about the core-fpga latency, benchmarking would be a good idea
<sb0>
idk if Altera chips also have latency issues
<hedgeberg>
could also gauge latency by having the fpga and the arm core output messages simultaneously and measure like that
<hedgeberg>
does altera have a zynq equivalent?
<sb0>
yes they do
<sb0>
how can you measure latency like that?
<hedgeberg>
i mean good chance im being stupid, its 4 AM here and my brains starting to shut down
<hedgeberg>
but the fpga element should have practically 0 latency beyond gate delay
<hedgeberg>
so latency of arm core outputs vs fpga outputs over io should be a pretty decent benchmark
sb0 has quit [Read error: Connection reset by peer]
sb0 has joined #m-labs
<hedgeberg>
sb0, did you see my response before DC?
<hedgeberg>
anyway, ty for help, see u guys around
<sb0>
hedgeberg, but you don't know the internal latency in the "arm core output" path
<sb0>
putting the RTIO core into a Zynq design and then talking to it from a C program shouldn't be particularly complicated
<sb0>
and you get actual results that are relevant for ARTIQ
<hedgeberg>
well no you dont and presumably itll be different for arm->pins than arm->fpga->pins but you can do all 3 different cases and compare results
<hedgeberg>
but yeah fair enough
<hedgeberg>
thinking too low level sorry
<hedgeberg>
anyway, meant to be going to bed
<hedgeberg>
night all, im sure ill be around to nag u all tmrw
hedgeberg is now known as hedgeberg|away
<sb0>
and what does the comparison tell you? you have the unknown "common mode" latency
<sb0>
you'll just have a minimum value for the highest of the two latencies...
<whitequark>
bb-m-labs: force build --props=package=llvm-or1k conda-all
<bb-m-labs>
build #82 forced
<bb-m-labs>
I'll give a shout when the build finishes
<rjo>
whitequark: you can add shutdown functionality to the runtime. or you can load a different bitstream. or bring it into one of the other jtag modes.
<whitequark>
ok.
<rjo>
whitequark: why did you merge the smoltcp stuff?
<whitequark>
because it works?
<rjo>
whitequark: is the ip/mac configurability there?
<whitequark>
nope
<rjo>
whitequark: then it's broken.
<whitequark>
I forgot about that part
* whitequark
shrugs
<whitequark>
I'm more concerned about the tests, that are completely useless right now because they just always fail
<whitequark>
and about being able to actually run large kernels
<rjo>
if the tests fail, why do you say, "it works"?
<whitequark>
because it's not the fault of smoltcp
<whitequark>
while the tests blanket failed, a few more bugs crept in.
<whitequark>
this is exactly what I'd like to avoid.
<rjo>
then it's the fault of the rust runtime.
<whitequark>
one of them is the fault of sb0. another is of the compiler refactoring. a third one is of the dds migration to artiq python.
<whitequark>
in any case, i don't see what are you complaining about. the tree went from very broken to much less broken. would you prefer it to stay very broken instead?
<rjo>
whitequark: let's fix those before rewriting another part of the stack.
<rjo>
whitequark: it is completely broken now.
<whitequark>
rewriting another part of the stack--which?
<rjo>
whitequark: i can't even test anything because of the ip/mac stuff.
<rjo>
whitequark: you mentioned a test runner. but i am pretty sure more items will come.
<whitequark>
i am specifically just fixing tests right now
<rjo>
whitequark: but why was the dds stuff not fixed when it was written/merged?
<rjo>
whitequark: same for the compiler refactor and for that bug from sb0?
<whitequark>
the tests were failing because of lwip brokenness, which hid all that.
<whitequark>
I've tested the DDS stuff against analyzer traces to work around that
<whitequark>
this made sure the new code is correct. but it wasn't as performant.
<whitequark>
test_pulse_rate_dds was the specific one that crashed lwip.
<rjo>
whitequark: please then put the isolated bugs (dds) low on the list and the stuff that is blocking everything else (ip/mac, etc) high.
<sb0>
i think there is just ip/mac
sb0 has quit [Quit: Leaving]
<whitequark>
rjo: well, the tests have to get green somehow
<whitequark>
sb0: I've discovered that by forceinlining DDSChannel.set I can get the test to 6.6us, or 7us in the more realistic scenario where the frequencies aren't the same for both channels
<rjo>
whitequark: i'd skip the dds test for now, and add an issue to track it.
<whitequark>
actually, the test is kind of unrealistic anyway because the frequency is constant
<whitequark>
you're making a sweep without, well, sweeping anything
<whitequark>
I don't think that forceinlining DDSChannel.set fixes anything in reality, it's rather a fix that improves a benchmark...
<whitequark>
the actual fix for this IMO would involve getting the FPU running, and then getting rid of soft-FP.
<whitequark>
right now we're twiddling with the optimizer, but fairly mundane code movement could negate all that twiddling, as some people have already discovered
<whitequark>
rjo: I'm going to cap it higher instead
<whitequark>
guards us from any other unexpected regressions
<whitequark>
alternatively we can maybe write an ARTIQ IR pass to lower soft-FP where possible
<whitequark>
but I'm not sure how viable is that yet...
<GitHub105>
[artiq] jordens commented on issue #652: Using 3.5 with Anaconda only needs a documentation update. https://git.io/vMxfQ
<rjo>
whitequark: what are the old and new values?
<rjo>
whitequark: remember that this speed is crucial. people are hitting it as a bottle neck. if it is slow, let's go back to implementing it in the runtime.
<rjo>
whitequark: but in any case. please leave it for now. there are way more pressing issues.
<whitequark>
rjo: the new value is 55us
<whitequark>
the old one is 6.2us
<rjo>
whitequark: that's frankly unacceptable.
<whitequark>
rjo: i don't agree
<whitequark>
the way the test is written, the value it returns is meaningless
<whitequark>
it doesn't accurately model the bottleneck people are getting into
<rjo>
whitequark: it does accurately measure the speed of setting dds stuff.
<whitequark>
no, it doesn't.
<rjo>
whitequark: you might want to write a different test that measure the speed at which you can calculate values.
<whitequark>
it measures the speed of performing floating-point conversion from frequency to ftw
<whitequark>
it always did!
<whitequark>
as far back as I can remember this test was dominated by softfp
<rjo>
whitequark: so soft-fp got slower by a factor of 9?
<whitequark>
no.
<whitequark>
the particular call-graph in this test caused the particular sequence of soft-fp operations to go slower by a factor of 9
<whitequark>
neither of them are representative of real-world usage
<whitequark>
for example, the test was *never* representative of soft-fp performance of real-world sweeps because it didn't actually do a sweep, it just repeatedly set the channels to 100MHz
<rjo>
whitequark: those tests are not meant to test soft-fp but the event emission speed. and when it was 6.2us it didn't test much of soft-fp.
<whitequark>
it still tested two multiplications iirc
<rjo>
whitequark: well that test should not be representative of soft-fp. write another test for that if you want.
<whitequark>
let me convert it to mu and show that this is the case then
<rjo>
whitequark: but those multiplications were not dominating the test.
<rjo>
whitequark: ok. and you can keep the other test with that 55us to test soft-fp if you want.
<rjo>
whitequark: but please let's table this and move over to the blocking issues.
<whitequark>
mh, I wish someone told me what this test is about earlier
<whitequark>
I spent a good deal of time optimizing completely wrong things...
<GitHub134>
[artiq] whitequark pushed 2 new commits to master: https://git.io/vMxTN
<GitHub134>
artiq/master 0b67396 whitequark: test: convert test_pulse_rate_dds to use mu....
<GitHub134>
artiq/master 57f54db whitequark: llvm_ir_generator: recognize inline and forceinline flags.
<whitequark>
ok, that should pass all tests.
<GitHub69>
[artiq] jordens commented on issue #570: Yep. Waiting for just one more contributor. https://git.io/vMxkO
<rjo>
whitequark: if you already have the numbers: how did the other parts that use the ip stack change? i.e. that 1M cache set/get, rpc speed, value writeback?
<whitequark>
rjo: let me see the final results and I can tell
<rjo>
whitequark: 6.2 µs -> 6.5 µs? and that wording should probably have been "when failing it was measuring soft-FP, when succeeding it was not"
<whitequark>
yes. those 300ns of increase are afaict genuine and caused by the various checks in ARTIQ Python code, e.g. overflow checks, div/0 checks, and all the other stuff that was UB in C
<whitequark>
I think there's a multiplication not hoisted out of the loop because of a possible div/0
<GitHub133>
[artiq] sbourdeauducq commented on issue #661: The current DDS test was written to measure the speed of the C routines. This is why there is no sweep or other computations. https://git.io/vMxIE
<whitequark>
1M RPC send has slowed down about 3x because smoltcp doesn't support the MSS option yet, and uses 536 as the maximum safe value defined by the spec.
<whitequark>
hm, this failure is caused by test_pulse_rate_dds again.
<GitHub96>
[artiq] sbourdeauducq commented on issue #637: Does smoltcp support gateways? NIST sometimes requires one. https://git.io/vMxtl
<GitHub166>
[artiq] whitequark commented on issue #637: @sbourdeauducq ARTIQ never initiates connections, why would it ever need explicit support for gateways? https://git.io/vMxt0
<rjo>
whitequark: that's not the tcp layer. it still needs to know the nexthop for sending a packet.
<whitequark>
rjo: nope. it just sends an ACK back from where ever the SYN came
<whitequark>
it doesn't even send ARP requests at all
<whitequark>
every IP packet is implicitly an ARP reply
<GitHub133>
[artiq] sbourdeauducq opened issue #662: smoltcp checklist https://git.io/vMxtF
<rjo>
whitequark: ok.
<GitHub196>
[artiq] whitequark commented on issue #662: smoltcp populates the ARP table from every incoming IP packet (such as the TCP SYN), so it never actually needs to resolve a MAC if all you're doing is listening. Therefore it has no special support for gateways. https://git.io/vMxqq
<rjo>
whitequark: what do you mean with "802.3 ... not supported"?
<whitequark>
rjo: there's Ethernet II framing and 802.3 framing.
<whitequark>
802.3 has an explicit length and is used in WiFi (802.11 LLC) and a bunch of other places.
<whitequark>
Ethernet II is used on wired Ethernet.
<whitequark>
and doesn't have an explicit length, that is.
<whitequark>
so the length in Ethernet II has to come from the physical layer decoder.
<rjo>
but 802.3 is much more than just framing.
<GitHub28>
[smoltcp] whitequark pushed 1 new commit to master: https://git.io/vMxmT
<GitHub28>
smoltcp/master 55be1a0 whitequark: README: clarify status of 802.3 support.
<whitequark>
rjo: fair
<travis-ci>
m-labs/smoltcp#59 (master - 55be1a0 : whitequark): The build passed.
<sb0>
it indeed doesn't set LD_LIBRARY_PATH anymore ...
<sb0>
well settings64 doesn't set it, but maybe some other xilinx script sets it for its children awk process
<sb0>
vivado doesn't in fact ship with a NIH awk, so it sounds more like it
<rjo>
sb0: got a few minutes to talk about the Yb clock project?
<sb0>
rjo, yes
<rjo>
sb0: imho we can do that here. whitequark feel free to chime in.
<sb0>
rjo, ok
<rjo>
we hat a couple meetings last week at PTB. all looking really good. timetable slipped a bit to synchronize the start with other parallel projects, submission of final proposals is first week of february, most likely project start and money flow is 2017-05-01.
<rjo>
players are PTB, FBH, Uni Siegen, Uni Bonn, VACOM, HighFinesse, Qubig, TOPTICA, Menlo Systems, and us, QUARTIQ.
<rjo>
compared to what we are doing right now with artiq in labs, this thing -- a autonmous Yb+ optical clock -- needs the following from us:
<rjo>
(1) support for the TOPTICA lasers, i.e. writing the library for that. they have a good xml description of the API and it's all ethernet, i see no huge challenges there. then we also need to hash out with them the procedures to start and stop the lasers and to sequence the frequency stabilization. that's going to be the bigger piece of work.
<rjo>
(2) support for the Menlo clock laser/cavity system. similar to the toptica lasers.
<sb0>
hopefully there are no NDAs for any of those things?
<rjo>
(3) support for highfinesse wavemeters. those require a windows-only machine which they are providing. ethernet again. and i have plenty of experience writing the api for those wavemeters.
<rjo>
sb0: there were NDAs at the meeting and there will probably be more in the contracts. but there won't be any NDA that will affect the development of those libraries.
<sb0>
meh
<sb0>
what are the NDAs about then?
<rjo>
(4) libraries/support for a bunch of smaller items: (a) lots of motors (thorlabs probably) (b) emccd camera (andor ixon) (c) shutters (from srs) (d) DACs/ADCs over SPI/I2C
<rjo>
the NDAs are about me/us hearing what they do and how they build their stuff.
<sb0>
well I'm not too happy about signing that
<rjo>
(5) develop procedures to start/stop/run/maintain the entire clock (load an ion, calibrate lots of stuff like secular frequencies, stray fields, heating rate, rabi frequencies...) including all kinds of problems that can occur (lasers drifting, ion lost, lock lost...)
<rjo>
sb0: you won't sign it. i won't tell you their secrets.
<rjo>
(6) develop with them the algorithms to run the clock probing experiment and the clok frequency stabilization loops
<rjo>
(7) lots of monitoring going on in parallel ~40 temperatures, ~100 parameters from lasers/locks/cavities, ~20 voltages, currents etc.
<rjo>
(8) a tiny GUI for the idiot user of the clock: basically a single on/off button. behind that the machinery to do all the required tasks (items 1-6)
<sb0>
rjo, so they're happy with you signing it in your own name?
<rjo>
(9) hardware: that's the bigger issue. and maybe the most interesting one.
<rjo>
yes. i signed in my name.
<rjo>
and i'll sign the funding and collaboration contracts for quartiq. but everything that we need to do our work won't be covered by ndas.
<rjo>
the hardware requirements are quite different from the ones that you have seen in our experiments at NIST or those at ARL/UMD/Oxford.
<rjo>
the clock runs rather slow. pulse lengths are many milliseconds, one experiment takes about 100 ms (c.f. ~2ms for those experiments at NIST).
<rjo>
ppulse shaping is not needed, phase control of RF signals is not needed either.
<sb0>
ok
<sb0>
so far, it sounds like a subset of what the current hardware can do?
<rjo>
right. but there is really no need for sayma.
<sb0>
yes...
<rjo>
what's needed is that VCO/PLL synthesizer extension board to Kasli (see the wiki, also proposed by david allcock).
<sb0>
no DDS?
<rjo>
and a version of that extension board with a simple wide-FTW DDS. there is only need for a single DDS.
<rjo>
the rest can and should be cheap synthesizers. some with frequency doublers/triplers since the frequencies are 2, 3, 5, and 15 GHz.
<rjo>
and it would be very convenient and fitting if we can run kasli stand-alone.
<sb0>
that's a lot of stuff
<rjo>
we have three years.
<rjo>
PTB will develop a multichannel slow (~khz) SPI/I2C DAC, a multichannel slow SPI/I2C ADC for temperature measurements, and the power amp hardware for those AOM/EOMs that are driven by the synthesizers.
<rjo>
and they will develop SPI/I2C photodetectors. then theoretically we could either (a) use one metlino, one sayma, one mini-crate for both (with RTM), one vhdci-breakout board or (b) one stand-alone kasli (coredevice), one 4xVCO synthesizer extension, one DDS synthesizer extension. both (a) and (b) would additionally need the 3U kasli-style crate, three ttl drive extension boards, and a couple more for SPI/I2C
<rjo>
busses.
<rjo>
i would prefer (b). also since this thing is supposed to be "really" compact. i.e. two smaller racks for everything including all lasers, electronics, vacuum chamber, pumps, computers.
<GitHub121>
[artiq] jbqubit commented on issue #645: I'm on master. I can build html using sphinx 1.5.1. Ubuntu 14.04, Chromium browser. When I load ```artiq/doc/manual/_build/html/index.html``` I see a search box on the left-hand side. ... https://git.io/vMpdW
<rjo>
jbqubit: they are all ok in conda. we use them on the buildserver
<GitHub5>
[artiq] jbqubit commented on issue #653: @whitequark Thoughts on this? https://git.io/vMpF0
<GitHub5>
[artiq] jbqubit commented on issue #645: $ make clean html ... https://git.io/vMpbN
<GitHub147>
[artiq] jordens commented on issue #645: Try downgrading to sphinx 1.4.6 (and `make clean html`). That fixes it here. https://git.io/vMpAt
<GitHub132>
[artiq] jordens pushed 3 new commits to master: https://git.io/vMppJ
<GitHub132>
artiq/master 591268a Robert Jordens: doc: use napoleon (for pdq2)
<GitHub132>
artiq/master 37fc7d5 Robert Jordens: doc: remove non-existent modules
<GitHub132>
artiq/master d1be2f1 Robert Jordens: doc: fix table
<GitHub88>
[artiq] jordens commented on issue #645: Your instructions on how we should solve this make me suspect you would like to get involved and do it yourself.... https://git.io/vMphq
<GitHub43>
[artiq] jbqubit commented on issue #645: I could have been more clear. It's still broken on the URL linked to by "Manual" on the m-labs.hk homepage.... https://git.io/vMpj0
<GitHub194>
[artiq] jordens commented on issue #645: I know. I just explained to you that that one and the one I just resolved for you are different bugs. https://git.io/vMpjr
<GitHub164>
artiq/master aa3af4f Robert Jordens: conda: fix sphinx pin
<GitHub119>
[artiq] jordens pushed 1 new commit to release-2: https://git.io/vMhtc
<GitHub119>
artiq/release-2 6c995e1 Robert Jordens: conda: fix sphinx pin
<GitHub190>
[artiq] jbqubit commented on issue #647: Repeat of previous test. This time with wireshark logging following reboot. ... https://git.io/vMht8
<GitHub61>
[artiq] jbqubit commented on issue #647: Repeat of previous test. This time with wireshark logging following reboot. ... https://git.io/vMht8
<GitHub39>
[artiq] jordens commented on issue #647: Could you please attach the dump data? https://git.io/vMhqG
<GitHub136>
[artiq] jbqubit commented on issue #647: Repeat of previous test. This time with wireshark logging following reboot. ... https://git.io/vMht8