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>
whitequark, ping!
<sb0>
aziz, yes
rohitksingh_work has joined #m-labs
<aziz>
nice, good work dude
<aziz>
good continuation
aziz has quit [Ping timeout: 260 seconds]
cedric has quit [Ping timeout: 260 seconds]
rohitksingh_work has quit [Ping timeout: 246 seconds]
cedric has joined #m-labs
cedric has joined #m-labs
cedric has quit [Changing host]
rohitksingh_work has joined #m-labs
rohitksingh_work has quit [Ping timeout: 268 seconds]
rohitksingh_work has joined #m-labs
rohitksingh_work has quit [Ping timeout: 246 seconds]
rohitksingh_work has joined #m-labs
rohitksingh_work has quit [Read error: Connection reset by peer]
hartytp has joined #m-labs
<hartytp>
rjo: has anyone funded operating Kasli as an ARTIQ master yet? Or, is it just funded as a DRTIO slave?
<sb0>
hartytp, it is only funded as artiq master (for opticlock) without any drtio
<hartytp>
Do you mean without SFP? Or without DRTIO for the EEM IDCs?
hartytp has quit [Quit: Page closed]
<sb0>
hartytp, the IDC connections don't need DRTIO, they have the chips connected directly to the master FPGA IOs
hartytp has joined #m-labs
<hartytp>
sb0: sorry, I'd misread rjo's post
<hartytp>
to be clear, you mean that Kasli is only funded as artiq master, not as a drtio slave?
<hartytp>
and that, when run as artiq master, it's not funded to control other Kasli or Sayma DRTIO slaves
<hartytp>
?
<hartytp>
(*your* post -- no coffee yet)
<sb0>
hartytp, yes
<hartytp>
thanks
<hartytp>
Do you have a proposal for Kasli DRTIO? e.g. what needs to be done, any difficult issues, what needs to be specified/what the major design decisions are?
<hartytp>
I'm thinking of:
<hartytp>
Kasli master able to control Kasli/Sayma via DRTIO
<hartytp>
Metlino master able to control Kasli via DRTIO
<hartytp>
(TBD importance, depending on number of SFP on Kasli) daisy chaining of Kasli DRTIO
<sb0>
hartytp, there are no major design problems, it's essentially 100% xilinx transceiver yak shaving
<hartytp>
estimate of cost/lead time?
<sb0>
I would not recommend daisy chaining, because the latency goes up at every hop
<hartytp>
by a few hundred ns, right?
<sb0>
yes
<hartytp>
Well, it depends on how many SPFs +EEMs Kasli has, and how much (e.g. number of DDSs) we can do on an EEM, but we may not have a choice
<hartytp>
Plan would be to hook low latency TTLs etc to the master
<hartytp>
latency doesn't matter for things like DDSs for AOMs
<sb0>
what are your bandwidth requirements? it might also be possible to run DRTIO masters off the IDC connectors, at reduced speeds
<hartytp>
would have to think about that a bit
<hartytp>
in most cases, really not much (occasional reprogramming of DDS)
<hartytp>
but I can think of cases which might require more BW (camer link?)
<hartytp>
*camera*
<hartytp>
My guess is that using the SFPs will be the cleanest, easiest way though, given the work that has already been done
<hartytp>
IIRC at some point rjo argued that we should not cram too many SFP onto Kasli because the plan was to daisy chain them together
<hartytp>
also, what's the estimate for when support Kasli as a master will land?
<sb0>
hartytp, maybe the cameralink can be put close to the master, or do the processing near the camera...
<sb0>
there is also no efficient protocol for retrieving large amounts of data from some input device right now
<hartytp>
True
<hartytp>
Anyway, daisy chaining is definitely a low priority for the time being.
<sb0>
Kasli as single master should be relatively uncomplicated
<sb0>
without dynamic rtio reconfiguration that is (i.e. EEM functions defined at bitstream compilation time)
<hartytp>
Assumi Kasli has 4x SFP
<hartytp>
1 goes to ethernet
<hartytp>
that leaves 3 DRTIO slaves
<hartytp>
our experiments will require 1 to 2 Sayma
<hartytp>
that means that without diasy chaining we can only run 1 to 2 Kasli DRTIO slaves
<sb0>
most of the code is already there, basically it needs to be put together and then fix any bugs or vivado problems
<sb0>
hm, are we having ethernet on sfp? that complicates things.
<sb0>
rjo, ^
<hartytp>
Given that we will need 30+ DDS channels in the next 6 months, I don't see how we get away without daisy chaining or something similar
<hartytp>
re dynamic configuration: I'm hoping (expecting) that we can get away without that. But having one (or a small number) of compile-time-fixed EEM configurations as previously discussed
<sb0>
right. so the major problem then is essentially ethernet on sfp, becauses this involves a xilinx transceiver, and those things never work
<hartytp>
re ethernet over SFP: maybe I misremembered that. It's not important for the current discussion though, as 4 SPFs for DRTIO slaves still wouldn't be enough (particularly if we only get 2 DDS per EEM IDC!)
<hartytp>
Could you put down in writing (wiki/GitHub/email) what's already been funded, and when the work is expected to land.
<hartytp>
And also send me a quote for the cost + lead time of Kasli DRTIO, please?
<hartytp>
Can you include daisy chaining as an optional line on the quote -- or suggest a cheaper/better way that we can do what we need without it
<sb0>
hartytp, so you'd be OK with the latency?
<hartytp>
yes
<hartytp>
3-4SFP on Kasli gives us plenty of low latency EEMs IMO.
<sb0>
the current wiki says 3 SFPs and one would be used for Ethernet
<sb0>
on the master
<hartytp>
More would be nice, but that should still be acceptable IMO
<sb0>
the schematics too
<sb0>
well with 3 SFPs you can make a tree instead of daisy-chaining
<hartytp>
exactly
<hartytp>
sb0, rjo: I outlined the way I plan to run our experiments on Sinara #191. Do you see any issues with that plan?
<hartytp>
the DRTIO tree shouldn't need to be very deep (again, so long as we can get enough functionality per EEM). We just would need more than the 2-3SFP available on Kasli.
<sb0>
hartytp, what is the noise eater software/gateware that you are talking about?
<hartytp>
"Software" approach is using a Kernel on the core device as discussed previously
<sb0>
hmm
<sb0>
there is only one CPU right now
<sb0>
so it would not run something concurrently with noise eating
<hartytp>
ACK
<hartytp>
it would be slow and a bit of a PITA.
<hartytp>
bit, gets us going quickly with minimal complexity
<sb0>
there is also no support in kernels for concurrent execution
<hartytp>
I know
<sb0>
e.g. if you block on a RTIO input, it ends the noise eater
<hartytp>
yes
<hartytp>
it's a very limited approach
<sb0>
it might be fine for prototyping the noise eater, but not sure if you could do much more with that approach
<hartytp>
Our experiments start with a few hundred us of doppler cooling
<sb0>
why does doppler cooling need a noise eater?
<hartytp>
we would probably just run a few PI iterations on each channel one after the other during this period
<hartytp>
again, not a long term plan
<sb0>
ah you want to run a PI iteration on the other lasers while the doppler cooling is on?
<hartytp>
correct
<hartytp>
turning other lasers on during doppler cooling isn't a problem generally
<hartytp>
otherwise, one just does it at the end of the sequence before resetting the qubit for the next experiment
<hartytp>
either way, the point is that one finds a period of ~100us somewhere where the experiment can be blocked to do noise eating
<sb0>
I see
<hartytp>
the "gateware" approach means putting a servo module on Kasli
<hartytp>
Design not thought through ye
<hartytp>
yet
<sb0>
do those laser servos need to interact with artiq?
<hartytp>
Probably though, a fixed configuration for Kasli, with 2 x Novogorny in continuous sample operation
<sb0>
give the current power level, send 'unlocked' alarms?
<hartytp>
Then, rather than programming the DDS ASF directly, one programs a PI module. This only samples when the RF switch is open. It probably also has a few different set points + accumulatorsone can select (basically, a simple version of the servo module rjo described)
<hartytp>
This isn't something I've really though through yet.
<hartytp>
current power level probably accessible via DRTIO. Alarms via DRTIO aux might be nice, but getting the user to check them via DRTIO is probably fine too.
<hartytp>
Our plan is to play around with Kasli + the various EEMs for a bit, until we get a better idea of our use cases.
<sb0>
hm, so the PI module has to arbiter access to the DDS with the kernel?
<hartytp>
yes, probably need a continuous update mode for the DDS as well...
<sb0>
ack
<sb0>
I hope those 9912 are reliable...
<hartytp>
hhm, one thing we need to check:
<hartytp>
with the AD9910, we saw huge glitches on the DDS output on IO_UPDATE (IIRC, the amplitude returned to 0 for a cycle or some BS like that)
<hartytp>
this was true whether IO_UPDATE was synchronised with SYS_CLK or not
<hartytp>
not sure if that particular "feature" is on the AD9912 or not.
<sb0>
the 9914 also has a number of silicon bugs: amplitude control not working unless OSK is enabled, chip sometimes not coming out of a reset initiated by the pin, loses ticks of the input clock (and becomes desynchronized after a few hours, unless sync signals are continuously applied)
<sb0>
the 9858 has no bugs that I know of
<sb0>
hartytp, so you have rack-mounted AOMs? is it something you assemble yourself or COTS?
<hartytp>
one other point: if we want to leave open the option of running the DDS in continuous update mode, then the switches are *required* i.e. we can't easily rely on turning the DDS ASF to 0 to disable the output, as the timing for that state change gets messy
<hartytp>
designed ourselves and heavily optimised around our setup. One of our postdocs did a really nice job of the setup. Point is that we have a lot to fit in our (limited) rack space, so we do need a decent channel density for the DDSs
<sb0>
I suppose that the noise eater should be disabled with the switch is open?
<hartytp>
right.
<hartytp>
like I said, I haven't thought this through too much yet, so let me know if you can see a problem with this plan
<sb0>
I don't see any major problem; I suppose you're fine with intermittent noise eater operation (and you probably know more on this topic than I do)
<hartytp>
BW is limited by DDS SPI update rate and number of DDSs on the IDC
<hartytp>
Intermittent noise eater operation isn't a problem.
<hartytp>
BW, if DDS update over SPI is ~1us, update on all channels takes ~5us, so about the same BW as the ADCs, which seems like a good fit
<hartytp>
also, using Kasli as master, how tight will the resource constraints be for things like: Kernel CPU speed; FPU; DMA; other resources etc? Do you think this will be a major isse?
<sb0>
I think kernel cpu speed should be comparable to the kc705
<sb0>
and it should fit in the fpga with a reasonable number of rtio channels
<hartytp>
...
<hartytp>
thinking about our priorities over the coming months a bit more, we might be interested in funding you guys to develop the gateware servo for Kasli very soon
<hartytp>
at least, it would be good to flesh out what would be involved in this project and make sure that the hardware is capable of it
<sb0>
hartytp, so what is that servo supposed to do?
<sb0>
is it just a PI controller, or something more advanced with e.g. PDH
<hartytp>
sorry, break for lunch.
<hartytp>
so, to be more concrete, here is what I have in mind:
<hartytp>
Kasli connected to the following EEMs: 2 x Novogorny, 4 x Urukul, 2 x generic TTL/SPI EEMs (not important for this discussion)
<hartytp>
Novogorny samples continuously at 125kSPS on all channels
<hartytp>
Each Urukul updates the DACs continuously at the max rate. Question: what will that be? Depends on the final choice of DDS.
<hartytp>
freq, phi, amp registers DDS channel are controlled + updated by the servo firmware
<hartytp>
users program values via DRTIO. The amp is scaled by the servo before programming.
<hartytp>
Basic servo stuff like having a few accumulators (profiles) for each channel, reporting of railing etc. Nothing fancy like PDH
<hartytp>
Potential issues with this plan that I can see:
<hartytp>
- The max rate that one can update the DDS (e.g. frequency hop) is ~8us. That's a bit painful. A few us would be fine IMO (2 DDS updates per ADC read?), I'd have to check the DDS datasheet more carefully to see what is possible here
<hartytp>
- RF switches need better timing resolution than that, so switches can't share the same SPI bus as the DDSs
<hartytp>
- Requires DDS reporgramming (IO_UPDATE) to be synchronised with DDS clock (is this already funded?)
<hartytp>
- Potential for nasty DDS glitches on IO_UPDATE
<hartytp>
So, that's what I'm thinking atm. Maybe it's a daft idea, but I thought I'd float it.
<hartytp>
Comments?
<sb0>
hartytp, are switches SPI?
<sb0>
aren't just a TTL?
<hartytp>
tbd.
<hartytp>
Comes down to how many DDS channels one needs per IDC.
<sb0>
generally for anything that uses this continuous sampling technique (ADC, DDS) it would be good to have a dedicated bus
<hartytp>
Putting them on SPI with a shift register allows us to get more onto an IDC.
<sb0>
otherwise the gateware becomes hairy if it has to be some combo of dealing with chip X during time slots A and B, and chip Y during slot C
<sb0>
it can be done, but I'd rather keep things as straightforward as possible. ditto your "DDR SPI" idea...
<hartytp>
As I said, we're looking for ~30 channels per experiment. If it's 2 DDS/IDC, then a Kasli can do only 8ch (1xNovogorny,4xUrukul). That means we need 4 Kasli/Euroracks to drive our AOMs. Probably another couple for DACs + TTLs.
<hartytp>
That's not the end of the world, but means that we'll need daisy-chaining/a DRTIO tree
<hartytp>
sbo: ack. I hadn't thought this through when I suggested that. Thinking about this makes me less keen on the idea!
<hartytp>
(FWIW, I was never keen on DDR SPI)
<hartytp>
But, we do need to be able to update the DDSs in a few us for this to be useful to us.
<hartytp>
say, <5us
<hartytp>
I guess with 2xDDS per IDC, that's not such an issue.
<larsc>
the more DDS the better!
<hartytp>
;)
<hartytp>
(shame you can't do DDR to program 2xAD9912 at the same time though)
<sb0>
add some flip-flops on the pcb ;)
<hartytp>
I did consider that. Not plan A though.
rohitksingh has joined #m-labs
<sb0>
larsc, do you know anything about the 9912 silicon bugs?
<sb0>
are there any?
<hartytp>
anyway, I'll keep thinking about this.
<hartytp>
But, if this is something you'd be interested in, then let me know. It'd be the usual combination of: consulting to make sure that we have a coherent plan in advance, which will be supported by the hardware; write + test + document the gateware; provide a nice python interface
<larsc>
sb0: I know nothing about the DDS chips
<sb0>
hartytp, sure. we're just a bit busy right now with the existing contracts
<hartytp>
sb0: this isn't something we're going to need straight away (the "software" approach will do for the short term)
<hartytp>
The main thing for now is the "coherent plan supported by the hardware bit".
<sb0>
btw what is David doing these days? is he looking for a job?
<hartytp>
so, wanted to run my plans past you and check we're on the same page about where we are going with this hardware
<hartytp>
Nadlinger?
<hartytp>
He just started a PhD with us, so not that I'm aware of ;)
<sb0>
ha.
kilae has joined #m-labs
rohitksingh has quit [Quit: Leaving.]
hartytp has quit [Quit: Page closed]
kilae has quit [Quit: ChatZilla 0.9.93 [Firefox 53.0.2/20170504105526]]