<sb0>
the schematics image is too small for me to read the P/N of the ethernet connector (which has integrated magnetics I suppose)
<sb0>
rohitksingh_work, ^
<rohitksingh_work>
sb0: Hi! Let me ask the concerned person in embedded team. I haven't myself worked with those boards.
<sb0>
it would be nice if the power jack were isolated too. i suppose you don't have a device with that?
<rohitksingh_work>
sb0: Hi again! Can you please shoot a mail using this contact page: https://numato.com/contact-us/ It will create a ticket which Tom has said he will himself reply directly. He was in meeting when I sent him your query.
rjo has quit [Ping timeout: 240 seconds]
stekern has quit [Ping timeout: 255 seconds]
stekern has joined #m-labs
rjo has joined #m-labs
rohitksingh_wor1 has joined #m-labs
rohitksingh_work has quit [Ping timeout: 260 seconds]
rohitksingh_wor1 has quit [Ping timeout: 246 seconds]
rohitksingh_work has joined #m-labs
<_florent_>
sb0: for the drtio, I was just testing the low level part (transceivers), I spent a bit of time finding the right parameters to get rx working...
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh_work has joined #m-labs
<rjo>
hartytp: DDR SPI really worries me. it seems counterproductive to try to squeeze the last bit of speed out of a bus that was never designed to be fast. for higher data rates there are more adequate solutions (fewer chips per bus, parallel bus and others...).
<sb0>
yeah, it feels a bit like 8 channels per card on sayma
<GitHub105>
artiq/master 52625d5 Robert Jordens: sawg: explain DUC
hartytp has joined #m-labs
<hartytp>
rjo: re DDR etc ping CJB, who was particularly concerned about keeping the servo update rate as close to 1MSPS as possible
<hartytp>
rjo: I'm open to any alternative method of getting the 1MSPS update rate.
<hartytp>
With the caveat that reducing it to 1DDS/IDC seems like a bad decision (too much wiring, and not enough DDSs per Kasli)
<hartytp>
FWIW though, I don't think it's counterproductive to try to optimise the gateway to allow us to get the most out of the physical resources that Kasli provides.
<GitHub93>
ionpak/master f8cdbd6 Sebastien Bourdeauducq: add value for C100
<rjo>
hartytp: well. with the AD9912 this all becomes irrelevant since there's no amplitude scaling...
<rjo>
hartytp: it's counterproductive if the complexity outweighs the benefits compared to other solutions.
<sb0>
rjo, so #735 can be closedß
<sb0>
?
hartytp has quit [Ping timeout: 260 seconds]
<sb0>
and #707 ...
folkert has quit [Ping timeout: 240 seconds]
folkert has joined #m-labs
<GitHub71>
[artiq] sbourdeauducq commented on issue #691: @whitequark What is left now is having ``aqctl_corelog`` connect to the management socket and print the messages from there, and a clean solution in the runtime to stream the log messages to the management socket. Can you help with that, especially the latter task? https://github.com/m-labs/artiq/issues/691#issuecomment-303333279
<rjo>
sb0: if we really do the low effort with #707, then i want to keep using branches to "tag things". but we can organize them as "old/phaser" or "feature/phaser"...
<sb0>
well versioneer doesn't support non-version tags at all
<hartytp>
rjo: is the AD9912 a fixed decision then?
<hartytp>
either way though, let's assume that we have access to a DDS with amplitude scaling. either by selecting the AD9914 population option or by respinning the boards with AD9910.
<hartytp>
I could live with 3IDC for 4DDS + switches. 2SPI buses on the first 2 IDCs, IO_UPDATE, switches on the second. Fit the attenuator in there as well somehow.
<hartytp>
hmm...actually not so sure about that
<hartytp>
We want 8 DDS + 8 ADC on a Kasli. so if 8DDS takes 6 IDC then we only have 2IDC for 8 ADC.
<hartytp>
For the (hypothetical) redesigned Novogorny, which provides 1MSPS on all ADC channels.
<hartytp>
Not sure that would work.
<hartytp>
So, yes, it's about complexity of gateware versus benefits of solution.
<hartytp>
But, in this case, the gateware complexity seems to be pretty small (unless I'm missing something) and the benefits seem pretty clear (being able to use Kasli to host an 8 channel servo box)
<hartytp>
But, if you can suggest a different solution/approach then I'm all ears.
<hartytp>
Or, if the gateware required to multiplex the SPI buses is really that complex then I'd be interested to understand why. (Isn't DDR something provided by most SPI cores these days?)
rohitksingh_work has quit [Read error: Connection reset by peer]
rohitksingh has joined #m-labs
<rjo>
hartytp: as i see it: we need 48 bit FTW, >500 MHz, would like 1 GHz and ASF. you guys need 1 GHz, 32 bit FTW, ASF. there is no chip that fits both.
<rjo>
hartytp: i am confident we can do 4 DDS per EEM, but that's either on a single SDR SPI bus and one IDC (with the other one optinally used for the RF switches) or on two SPI buses with two IDC.
<hartytp>
can you use AD9914 w/ Programmable Modulus Mode?
<hartytp>
Otherwise, I agree that we'll need to use a different population option to you guys. But, that's a trivial modification...
<hartytp>
w/ 2 SPI busses on 2 IDC, what DDS update rate can you get?
<hartytp>
Something like 1/3us?
<rjo>
hartytp: DDR? not even the top-of-the line Xilinx AXI SPI core supports that.
<rjo>
hartytp: we could use the AD9914 but that's a beast.
<rjo>
hartytp: i can't tell whether the ad9910 supports address auto-increment which cuts down transfer time. but maybe it does. larsc?
<rjo>
hartytp: assuming 24 SPI bits for the ASF, the ad9910 at 62.5 MHz SPI clock (with a 125 MHz RTIO coarse frequency), plus a lead and trail SPI cycle, that's 656 ns per update, with two DDS on one bus that's 1312 ns for the double update.
<rjo>
hartytp: but has hanybody looked at ensuring that the ADC sample rate is matched to or throttled by the update rate?
<rjo>
IIRC the ADC max sample rate depends on a very specific pattern of sampling and that sequencer driving it.
<hartytp>
re AD914: ack
<hartytp>
can we ask greg to include AD9910 as a population option?
<hartytp>
(remove the AD9914 population option?)
<hartytp>
otherwise, we'll produce an AD9910 version of Urukul
<hartytp>
re SPI config: okay, that's better than I remembered. IMO, 1.5us cycle time is fine. So I'd be happy with that option (ping cjbe)
<hartytp>
re ADC: no, no one has looked into anything yet ;)
<hartytp>
Let's agree on a rough plan for Urukul and then revisit the ADC design (that seems like the easy part...)
<hartytp>
rjo: looking more carefully at your proposal, the 1.3us cycle time comes from only updating the ASF, and never touching the FTW/POW
<rjo>
hartytp: yes. what do you want to feed back onto?
<hartytp>
A use case we need to support is frequency hopping AOMs (e.g. for EIT cooling on several modes)
<hartytp>
so, we don't need to feedback onto the FTW
<hartytp>
but we do need to be able to update it.
<hartytp>
for some of our experiments, we need FTW updates to occur in ~1us
<hartytp>
this is part of the push for a 1MSPS cycle speed
<hartytp>
with AD9910 a full ASF/POW/FTW update is ~1.5us
<hartytp>
so, the question is how to combine the amplitude feedback with frequency hopping etc.
<hartytp>
If we reprogram FTW/POW/ASF on each update cycle then this is easier IMO
<hartytp>
but needs more BW
<rjo>
hartytp: correct.
<rjo>
... if it supports address auto increment
<hartytp>
auto increment? You mean programming all three registers in a single transaction?
<rjo>
hartytp: yes. all ten registers.
<hartytp>
that's fine on AD9910
<hartytp>
wait. 10 registers?
<rjo>
well. the FTW is split across 4, POW across 2 and ASF/ARR across 4.
<hartytp>
okay, I see what you mean.
<hartytp>
Yes, that's fine. IIRC, it's something like 72bits total
<rjo>
80 data plus 8 instruction plus 1 SPI lead/trail
<hartytp>
Another option you won't like, double SPI? Something like
<hartytp>
CS is override for controlling attenuators via SPI
<hartytp>
Double/quad SPI seem pretty standard to me.
<hartytp>
That works with AD9910 to give a full FTW/POW/ASF cycle time of something like 1.3us, which would be fine for us
<hartytp>
and, seems nice because there is no bus sharing on the DDSs other than a global IO_UPDATE
<hartytp>
which makes life easier for the user
<rjo>
hartytp: multiplying the number of possible "SPI configurations on EEM IDC" will correspondingly multiply the number of bitstreams leading to much more work making them, inability to maintain and CI-HITL them etc etc. That's a maintenance nightmare.
<hartytp>
I fully appreciate that.
<hartytp>
But, what else would you suggest?
<hartytp>
Design a fully custom board with FPGA, DDS, ADC on it? And maintain that separately as a DRTIO slave?
<rjo>
as a sidenote for the numbers game: with one kasli you might get as many as 12 EEM-IDC connectors, not just 8
<hartytp>
Or, make some of our experiments a complete pain to run because the hardware is so slow?
<rjo>
the latter is obviously not the goal here.
<hartytp>
The former seems like a bad plan too, as the maintenance burden seems much higher than supporting a new Kasli SPI configuration
<hartytp>
Which is why I'm keen to find a Kasli/Urukul-based solution
<hartytp>
With 12 IDCs, we could make this work. 2DDS/ADC per IDC * 8 chanels = 8 IDC
<hartytp>
plus a few extra for switches etc
<hartytp>
it's a wiring mess
<hartytp>
but it'd work
<hartytp>
if we can fit that on Kasli
<hartytp>
I'd go along with that solution
<hartytp>
Also, it would probably rule out a back plane, as there aren't enough pins. But, that's a separate matter
<rjo>
the additional four IDC connectors could be on the (passive and narrow/stub) backplane.
<rjo>
could you elaborate on your numbers? 8 channels is one Novogorny and two Urukul, right?
<hartytp>
"the additional four IDC connectors could be on the (passive and narrow/stub) backplane" if that's true then great! But, I didn't think there was room for that on a 91 pin connector.
<hartytp>
"8 channels is one Novogorny and two Urukul, right?" correct
<hartytp>
Hopefully, we can fit 16 channels in a 4U EuroRack
<hartytp>
On the many IDC approach, we'd still need an IDC configuration that supports 2 SPI buses (muxed with TTL phys?) on an IDC.
<hartytp>
"the additional four IDC connectors could be on the (passive and narrow/stub) backplane." Sorry, misread that, thought you meant that they could be on the BP _as well_ (i.e. all 12 on the BP)
<hartytp>
Well, I do think it's important to support operation without a BP. So, it'd be great if all 12 IDCs were directly on Kasli as well.
<rjo>
have a look at the current kasli pdf from greg. 8 on kasli, 4 on the BP.
<hartytp>
TBH though, If the BP only supports 4 IDCs then I'm not sure it's worth the hassle of designing/buying/installing it
<hartytp>
4 IDCs is 1 Urukul + some BNCs
<rjo>
it's zero effort. the BP is only an adapter from that 96 pin DIN to 4x IDC.
<hartytp>
aah, that's what you mean
<hartytp>
so, everything still uses ribbon cable in the end
<rjo>
it can. or you can build a fancy backplane for just 4 EEM without having to use IDC connectors.
<rjo>
but for your config there's 12 IDC ribbons.
<hartytp>
Still seems less convenient than having the IDCs directly on Kasli. But, if they won't fit then it's an option
<hartytp>
So long as it works out mechanically (ie all fits together sensibly in a standard rack)
<rjo>
for your 60 channels you should really consider doing something special purpose. just the 2*60 RF + clocks + DRTIO + misc cables will be fun.
<hartytp>
60 is for 2 experiments in the same lab. Each is 30
<hartytp>
30 ribbon cables is a tedious couple of hours. But, it's install-and-forget type work
<hartytp>
In practice, that's _much_ less work that designing and maintaining custom hardware for the job IMO.
<hartytp>
IME modular, cheap, simple and reusable wins out over beautiful, elegant and special purpose in most cases
<hartytp>
Plus, we should be able to get this approach off the ground pretty quickly compared with designing something custom
<hartytp>
which is important for our current experimental time scales (hence my spending so much time here and on GitHub recently)
<hartytp>
Anyway, back to topic: you know what we need to achieve and I think we've discussed basically all the sane options. Let me know what you think the best path forwards is.
<rjo>
one thing about the DDS SPI bus usage: i think you are envisioning a double buffered scheme where there are registers for FTW/POW/ASF in the FPGA gateware which are then updated continuously to the DDSs, leading to the aforementioned rate. the other approach would be time division muxing. there'd be e.g. 75% of the bandwidth (time slots) for continuous ASF updates from the PIDs and the remaining 25% for other
<rjo>
things. then you could handle the FTW/POW things elsewhere. just need to figure out the allocation.
<hartytp>
I did think about something like that. But, rejected it because:
<rjo>
and you will want to have integrator hold (a.k.a. PID "stop") per channel anyway. then you can just stop the channel and do FTW/POW updates in those slots.
<hartytp>
1. We need to have the option of updating the FTW at about the same rate as the ASF for some of our experiments (fast cooling of multiple modes)
<hartytp>
2. It gets to be a bit of a mess from the user's perspective.
<rjo>
spell out your operation mode for me again. do you expect to be doing FTW updates with the PID running? or can you stop it (or have it automatically "held" for a time slice if there is an ftw/pow update instead).
<hartytp>
"then you can just stop the channel and do FTW/POW updates in those slots." True, that works for us.
<hartytp>
In practice, the user never want's to change the fequency/phase with the switch open
<hartytp>
But, when one has multiple DDSs on the same SPI bus. With a continuous update mode on 1 DDS being overridden by a switch on another channel, it can get confusing for the user
<rjo>
could you elaborate "Synchronous reset via DRTIO allow synchronisation of DDS update cycle with global RTIO clock."? do you mean fully deterministic absolute phase across reboots?
<hartytp>
Two separate points:
<hartytp>
- Bus sharing is a pain for users (have to remember which AOM drivers share an IDC to avoid conflicts). DDR/double SPI/number of IDCs come into play here
<rjo>
yes. the double buffering with continuous updates is a classic solution to that.
<hartytp>
- Separate issue is whether the FTW needs updating during the servo loop. In practice one would never want to update the FTW with the switch open. But, I figured it was easier to constantly update it than to implement logic that only updates the FTW when the switch is closed (arbitration between servo and user-programmed registers).
<rjo>
i'd strictly share the bandwidth among the dds on the bus in any case. but for a given dds, a ftw/pow update (and/or profile switch in your parlance) can suppress one (or up to three) asf updates.
<rjo>
s/share/split/
<hartytp>
re synchronous reset: no I'm not worrying about deterministic phase here. More that the user wants to know exactly what RTIO timestamp the FTW update will occur in the sequence (avoids opening a switch too soon).
<hartytp>
You might be right about that
<hartytp>
So, how are you sharing the BW?
<hartytp>
FTW + POW updates take longer than ASF updates
<rjo>
let's say one ASF update (2 registers, 2*8 + 8 + 1 SPI cycles) is one slot. the sequencer would (with 4 DDS on a bus) write 1A,2A,3A,4A|1A,2A,3A,4A|... and if there is an POW+FTW (P,F,G) update on 2 pending, do: 1A,2P,3A,4A|1A,2F,3A,4A|1A,2G,3A,4A|1A,2A,3A,4A|...
<hartytp>
True, I'm assuming that we can aligh IO_UPDATE properly to get all the timing deterministic. Otherwise, the reset doesn't work.
<rjo>
for the deterministic timing you (might) need to consider the non-determinism of the RF switch update vs. the actual FTW update in the DDS. you do accumulate different phases if they are not deterministic w.r.t. each other.
<rjo>
hartytp: not just IO_UPDATE, but the (internal in the case of the AD9912) SYNC clock.
<hartytp>
yes
<hartytp>
true
<rjo>
another point: multiplicative IIRC filters might be too costly. can you live with additive effects?
<rjo>
that is generally better for your harrdware since otherwise you'd have to change your PI gain as well.
<hartytp>
Re phases: none of our use cases are phase sensitive. We just want to make sure that the frequency updates before the switch opens without having to add excessive padding everywhere
<rjo>
ok. then the relaxed determinism is fine.
<hartytp>
yes
<hartytp>
"multiplicative IIRC filters might be too costly. can you live with additive effects?" -- can you spell this out a bit, please? My control theory knowledge is basically analogue only ;)
<rjo>
ah. do you just mean ASF_register = PID(ADC - ASF_setpoint)?
<hartytp>
yes. that's what I meant
<rjo>
then that's fine. if you mean ASF_register = ASF_offset * PID(ADC - ASF_setpoint) that would be more troubles.
<rjo>
ASF_register = ASF_offset + PID(ADC - ASF_setpoint) would also be easy.
<hartytp>
sorry, I did write the latter, but was thinking of the former.
<hartytp>
No, ASF_register = PID(ADC - ASF_setpoint) is what we want
<hartytp>
will correct that later
<rjo>
i am also editing currently. hold off a bit.
<hartytp>
will do
<hartytp>
re your multiplexing suggestion: We need the ability to do two pulses from the same DDS, with a dealy between pulses of ~1us.
<rjo>
so you don't need ASF_offset at all (usually you don't).
<hartytp>
your suggestion looks like it will be quite a bit slower than that
<hartytp>
no, not at all
<rjo>
then you even have to monopolize the entire bus for one DDS, right?
<rjo>
is "pulse" two frequency and two amplitude updates for you? or just one of each?
<rjo>
do you need individual integrators (accumulators) for each profile as well?
<rjo>
for frequency hopping on AOMs you may want that.
<hartytp>
"do you need individual integrators (accumulators) for each profile as well?"
<hartytp>
yes. This is a big help for frequency hopping
<hartytp>
I mean: start with SW on. Shut SW. Reprogram FTW. Open Sw. Gap between SW shut and SW open should be ~1us
<hartytp>
"then you even have to monopolize the entire bus for one DDS, right?" AFAICT, yes unless we do something like DDR.
<rjo>
quad SPI would be much easier there.
<rjo>
i don't even see how DDR SPI is supposed to work since there is now state (slow clock phase) at the other end...
<rjo>
ok. done editing. have a look at the diff and check/amend/edit/reply.
<hartytp>
sure, QSPI is probably better
<hartytp>
thanks for doing that
<hartytp>
"Individual integrators per profile as well?" yes
<hartytp>
"**?** Precise functionality of that "railed" indicator." anything that alerts the user + adds something to the log in a sensible way. Whatever is easiest to implement
<hartytp>
"**?** Synchronized IO_UPDATE across DDS" The DDS updates don't all need to occur at the same time IMO. So long as the timing is deterministic in the weak sense
<rjo>
nothing realtime, just a message/flag that eventually ends up somewhere?
<hartytp>
yes
<rjo>
hartytp: you can just re-integrate the questions into the the spec.
<hartytp>
done. Appart from the ADC stuff. I'd need to think more about that
<hartytp>
apart
hartytp has quit [Quit: Page closed]
<rjo>
hartytp: good. i added two options for the IDC connector layout. i think we will want to do two different boards (AD9910 + QSPI, AD9956/AD9912 + simple) if Greg can't squeeze that in as options.
<rjo>
hartytp: does that second pinout represent your QSPI idea adequately?
<sb0>
having lots of bitstreams isn't necessarily a nightmare if we have more staff, but it is expensive
<rjo>
yes.
<rjo>
;)
rohitksingh has quit [Quit: Leaving.]
hartytp has joined #m-labs
<hartytp>
rjo: thanks for doing that! LGTM
<hartytp>
I wonder if Greg can fit both options in using suitable population options without creating too much of a mess
<hartytp>
are you happy with the QSPI option from a gateware perspective? I don't want to ram something through if you think it's a terrible idea. If it would make life much easier, and if Kasli has sufficient IDCs, then we can go for an option that uses more IDCs
<hartytp>
Also, would you be interested (/do you have time) to support this + write the servo?
hartytp has quit [Ping timeout: 260 seconds]
cr1901_modern1 has joined #m-labs
cr1901_modern has quit [Ping timeout: 240 seconds]
<hartytp>
The thing I don't like about the QSPI approach is that it breaks the multiplexed IO model of Kasli, which aims to support a wide range of hardware with a small number of bitstreams.
<hartytp>
This could make it less useful as a general purpose device.
<hartytp>
It's particularly bad since we implement a non-standard QSPI with a shared MISO.
<hartytp>
For a high-bandwidth Urukul, we'd probably need QSPI with 1 MOSI and 4 MISO.
<hartytp>
All doable, but not in a nice way that allows flexible reconfiguration of hardware.
<hartytp>
Maybe we are better off using 1 IDC per DDS/ADC after all... That would still just allow an 8ch noise eater on a single Kasli.
<hartytp>
And, we might be able to use a jumper + some gates or component placement to allow users to switch between high-bandwidth (4 IDC) and compact (1 IDC) options
<hartytp>
QSIP advantages: 2 DDS/ADC per IDC, allows Kasli to drive 16 channels and reduces wiring complexity
<hartytp>
QSPI
<hartytp>
QSPI disadvantages: more complex, less generic gateware
<hartytp>
correction: previous comment should have been "for a high-bandwidth Novogorny we'd probably need QSPI with 1 MOSI and 4 MISO)
<hartytp>
I could live with either approach so long as Kasli is cheap, low power consumption and easy to get hold of
<hartytp>
oops ignore the obvious errors in IDC/channel count -- a month without more than 2 hours of uninterrupted sleep does not help basic arithmetic