[RFC] new EEM: Fastino (faster version of Zotino)

[dtcallcock]

A faster DAC than Zotino.

Roughly order of magnitude performance improvement by most metrics at the cost ob being only 4 channels.

Use cases

Voltage output version of SU servo

SU servo is an 8ch servo for Artiq based on Kasli. It uses the 8ch Sampler ADC as the input and changes the phase/amplitude/frequency of a pair of Urukul 4ch DDS cards as its output. It is capable of a ~2us latency. An obvious extension of SU servo would be to have a voltage output instead. This would reuse the Sampler, Kasli, and much of the gateware. The current EEM DAC, Zotino is not well suited for this application for various reasons though.

General fast DAC

There is a bit of a gap between Zotino (update rate of 1MSPS divided between all 32 channels) and the super high spec Shuttler. Are there any specific use cases to be found in this gap?

Implementation

Channel Count

4 channels and 4 SMAs on a 4HP front panel

DACs

4x 16-bit single channel DACs AD5542a or similar

3 MSPS (all channels simultaneously) 1 LSB INL (4x) 11.8 nV/√Hz noise spectral density (23x) 1 μs settling time (20x) 0.05 ppm/°C temperature drift (100x)

Numbers in brackets refer to improvement over the AD5372 on Zotino.

EEM

1x SCLK 4x SDI 1x LDAC 1x CLR 1x spare

I2C readout of termination and polarity settings.

Output Ranges

Output impedance of 450Ohm

Bipolar

• -1 to 1V into 50 Ohm load
• -10 to +10V into high-Z load

Unipolar

• 0 to 1V into 50 Ohm load
• 0 to 10V into high-Z load

DIP switch to select between bipolar/unipolar. DIP switch to connect on-board 50 termination.

[hartytp]

This is also something I’d been thinking about.

For the feedback use case it might be best to make a humpback mezzanine with, say, 2 dac and 2 adc. With minimal to no afe (in amps limit bw). Could also go for faster adcs (5mhz version of same adc in the quad package).

[hartytp]

The fast dac seems like a very useful idea. My feeling is that the rule should be: if it can be done with an eem then use an eem not amc. For something with the requirements of shuttler amc is the only option but it’s going to be hellishly expensive. But that design is over specified for many use cases so I think there is room for an intermediate speed eem dac.

Nb if that’s the use case we’re targeting then we have to be very careful to keep the cost/complexity/power consumption down. If the cost ends up anywhere near shuttler then there is no point imo.

Target dnl probably 2 (16 bit) as much more gives noise issues and there are almost no options if we target less than 2.

Maybe aim for 5msps+

[hartytp]

Almost all the options are for parallel dacs which eat up too much io to be viable for an eem. Ideal would be a compact lvds interface like the sampler adc but I can’t find a dac like that.

Maybe the best option would be to use a fast sr or even a cpld for an 8 channel board to convert a parallel dac to a compact few wire lvds interface...

[hartytp]

For output range one trick I've used before is fixed +-10V output with 450R impedance. High z load for +-10v range, 50r load for +-1V range. Software limit for 0 to 1v range.

[gkasprow]

We can make switchable range. With software limit we loose >3 bits of resolution. With quad current output DAC we can setup 1/10V range by selecting 2 reference voltages. SPI works up to 50MHz so with single EEM we can have 16 channels easily using quad SPI mode.

[dtcallcock]

Ideal would be a compact lvds interface like the sampler adc but I can’t find a dac like that.

Yes it seems like there isn't a DAC with the kind of interface that would be convenient here. They seem to jump from <3MSPS SPI DACs to much faster parallel/JESD parts.

Maybe aim for 5msps+

Given the above it seems like that's the main decision to be made here. Either we stick with 3MSPS SPI DACs or go to parallel DACs and use some kind of deserialiser. For the 'Voltage SU Servo' use case, 3MSPS sounds adequate.

SPI works up to 50MHz so with single EEM we can have 16 channels easily using quad SPI mode.

I see how we can easily run 4 SPI data lines down the EEM to 4 DAC chips. Then I imagine you could run this DDR to feed 8 DAC chips. How to you get to 16 though?

very careful to keep the cost/complexity/power consumption down Target dnl probably 2

As an example the AD5542a has:

16-bit resolution 1 LSB DNL 11.8 nV/√Hz noise spectral density (23x better than AD5372 in Zotino) 1 μs settling time 0.05ppm/C offset and 0.1ppm/C gain error 3MSPS over 50MHz SPI ~1mW power dissipation $10 at prototype quantities (note 1 ch per chip)

So this would seem to meet those requirements if you can live with 3MSPS.

[dtcallcock]

For output range one trick I've used before is fixed +-10V output with 450R impedance. High z load for +-10v range, 50r load for +-1V range.

If we did this it would be good to have DIP-switchable (and LED indicated) 50R on the board like on Sampler.

Software limit for 0 to 1v range. With software limit we loose >3 bits of resolution.

If the limit is just to make the output unipolar, that's only 1-bit you are losing.

That said, the DAC I mentioned above has both unipolar and bipolar modes (with an external op-amp). It seems like it would be fairly easy to switch between the two modes using a DIP switch (DPDT would work).

[hartytp]

@gkasprow To elaborate a litltle...

There are a lot of ion trapping use cases that require a multi-channel DAC with decent noise/stability and a minimum sample rate of about 5MSPS. Shuttler is over specified for many of these use cases (though it’s about right for some of the fancy things @dhslichter outlined before) and extremely expensive ($500+ per channel). So it seems worth considering whether we can make this design suitable for those use cases.

Obviously we could do that with a separate design, but my feeling is that we’re best off trying to have a small number of really well supported, widely used boards, rather than lots of very specialised boards. So, I’d like to see if we can make this board work for both the feedback and fast DAC use cases (as @dtcallcock described in his original post).

If we can find a simple/cheap way of interfacing parallel DACs to EEM connectors along the lines of the Sampler ADC interface, then I think that would be ideal for both the feedback and fast DAC uses. Is there any issue using fast SRs to do this?

[gkasprow]

@dtcallcock

SPI works up to 50MHz so with single EEM we can have 16 channels easily using quad SPI mode.

I see how we can easily run 4 SPI data lines down the EEM to 4 DAC chips. Then I imagine you could run this DDR to feed 8 DAC chips. How to you get to 16 though?

the DACs I mentioned are 4-channel. So 4 data lines are enough to make 16 channels.

[gkasprow]

If we have to go for parallel DACs, then CPLD similar to used in Urukul or tiny 5$ ICE40 FPGA does the job as deserialiser.

[gkasprow]

Maybe MAX5875 + ICE40 FPGA would do the job? ICE40 is low cost and has already LVDS so this would make the board simple. Some DACs can share same 16bit LVDS. 20ppm tempco can be mitigated by using TEC.

[hartytp]

@gkasprow without looking into the details (can’t do that this week): yes, that’s roughly what I had in mind. EEM actually provides a lot of BW (I’ve run 125MHz DDR down a 10M cable + 2 x 30cm IDC and 2xVHDCI_CARRIER cards without any issue during testing) so there should be no bandwidth problem providing 8 DACs at >=5MSPS. Just need to check that the power consumption, cost and complexity of the scheme is okay, and that the noise isn’t too bad. If that all checks, this would be a very useful design IMO.

Someone would need to write some simple gateware for that CPLD/FPGA (AFAICT, just needs some fast SRs with reset and set lines). FWIW though, I was really happy with both the quality and cost of the code @jordens wrote for Urukul, so I don’t see that as being a major issue.

[dtcallcock]

SPI works up to 50MHz so with single EEM we can have 16 channels easily using quad SPI mode.

I see how we can easily run 4 SPI data lines down the EEM to 4 DAC chips. Then I imagine you could run this DDR to feed 8 DAC chips. How to you get to 16 though?

the DACs I mentioned are 4-channel. So 4 data lines are enough to make 16 channels.

But with only one SDI line, a 50MHz SPI speed and 18 bit shift register the update rate would be limited to 694 kSPS per channel.

[dtcallcock]

I’ve run 125MHz DDR down a 10M cable + 2 x 30cm IDC and 2xVHDCI_CARRIER cards without any issue during testing) so there should be no bandwidth problem providing 8 DACs at >=5MSPS

For 4 data lines and 8 channels this gives a limit of 7.8MSPS, so a factor of 2.6 in speed over the SPI solution.

What are the use cases where that 2.6 factor would be critical? For all but the fastest ion transport experiments (where Shuttler would be used anyway) we are aggressively low pass filtering voltages at ~100kHz. It is nice to keep the clock away from any secular frequencies, but for lighter ions 7.8 MHz doesn't even really do that.

What are the costs? It looks like the silicon cost will be similar. However:

• DAC power dissipation would be ~1W instead of few mWs (note that this is at 200MHz clk so probably be less)
• Have to write CPLD code
• DC performance of DACs looks much worse and may require a TEC to keep temperature drifts sensible.

I'm not sure if it would make things easier/harder/similar on the Kasli/servo gateware side of things. @jordens ?

[gkasprow]

The cost would be mainly DACs - roughly 100$ per 8 channels. So it is cheaper than Zotino DAC. The dissipation is function of clock but don't expect big savings. Below is a plot from datasheet.

[gkasprow]

Extrapolating the plot to 10MHz it would give us roughly 180mW/ 2 channels which gives 720mW. That's doable with small TEC and heatsink.

[dhslichter]

I agree that Shuttler has probably become over-spec'ed and should be revisited. However, I think that the aim there would always be to have something with at least ~50 MSPS, and where one can run a larger trap with 50-100 electrodes in a reasonable space, so I think that "Fastino" is still non-overlapping and interesting to pursue in its own right.

[dnadlinger]

It is nice to keep the clock away from any secular frequencies, but for lighter ions 7.8 MHz doesn't even really do that.

Using 2x interpolation on something like the MAX5898 would give >15 MHz, which is probably enough to keep clock spurs out of the motional range for most "boring" Paul trap setups.

From experience in Zurich, DC performance on most of these DACs is woefully underspecified, though, and temperature stability needs close attention. It might (or might not) be easier to carefully design around the spurs than going the wild oversampling route.

The MAX5875 seems to exhibit 50 ppm/K gain drift, by the way, not 20 ppm / K.

[dtcallcock]

Using 2x interpolation on something like the MAX5898 would give >15 MHz

Sure, but this DAC has serious drawbacks

• A minimum clock frequency of 10MHz
• Burns nearly half a Watt per 2ch chip
• Needs an SPI interface as well as data lines to program the control interface
• Has 110ppm/C gain drift

As the noise for these chips isn't specified in nV/rt(Hz), it's hard to make an immediate comparison with the AD5542A. Did you ever look into this at Zurich @klickverbot?

All of this can of course be dealt with if it meets a need that neither a 3MSPS Fastino or Shuttler will. Are you thinking about use cases other than just fast-ish ion transport?

[sbourdeauducq]

ICE40 FPGAs, if they can be used, are preferable to Xilinx CPLDs as we can use IceStorm instead of ISE.

[gkasprow]

Some potentially interesting DACs: LTC1668 but 8 bit INL DAC3282 seems overkill but power consumption is linear function of speed. And is low cost. But DNL i +/-2bit

[jordens]

or the well known AD9726...

A couple notes:

• In the case of a CPLD or FPGA as a streaming IO mux/router, or even with a common clock+cs, that would imply the same kind of "global" operation as SUServo. I.e. all DACs behave the same and are constantly streamed. There is no sub-sample granularity in the timing.
• At some point the sampling clock jitter becomes relevant as it mixes onto output amplitude of changing signals. And given that we are explicitly designing this for >>f_Zotino, that clock noise should received some analysis and design attention. CPLD/ICE40/Kasli/LVDS transciever digital jitter might be a problem.
• I don't think a small FPGA or CPLD for either wide SPI to parallel conversion or IO routing is a bad idea here. A FPGA might even do 2x or 4x interpolation when cleverly designed. Or it could do full spline interpolation pending some redesign of that concept.

[gkasprow]

For higher speed ADCs we should use Kasli clock. Driving 10MHz16bit DAC clock from FPGA will degrade SNR significantly. Low grade FPGAs have hundreds ps of jitter on regular IOs. Such clock from either Kasli or onboard XO should feed both DACs via chock splitter chip as well as FPGA.

[dtcallcock]

It sounds like once we add a clock network and a reasonably sized FPGA we are basically making the 'PDQ on a Eurocard' that @dhslichter suggested for Shuttler.

Is it possible to make a card that has a high enough spec to replace Shuttler (or at least kick the can down the road) but not so expensive or complicated that it's unsuitable for the Servo and general EEM applications I proposed? If not then I suggest we dial it back to the 3MSPS SPI solution and continue to develop Shuttler.

[dhslichter]

The issue with all of the faster DACs that people are talking about in these posts is that they are no longer ~few mW per channel, they are ~100-300 mW per channel. Now you're talking about a lot more dissipation for Fastino, and so you have much more hassle with getting the EEM cooling to work properly. We are rediscovering some of the pain with the Shuttler discussion, and some of the reasons why it has ended up being as over-spec'ed as it is in some regards. I think trying to make Fastino go for more than a few MSPS by trying to add an FPGA for spline interpolation/DUC to boost the sample rate, is just going to end up looking like a lot of hacks to get something going that would be more properly engineered in Shuttler. I am totally sure it can be done, eventually.

Something like the DAC8831 runs with 16 bits at 2 MSPS, has an output settling time to 1/2 LSB of 1 us, is programmable over SPI at 50 MHz clock speed, has superb nonlinearity and gain/offset tempcos, can be run to make unipolar or bipolar outputs depending on the op-amp chosen, is dirt cheap (~$10/channel), and dissipates 100 uW (!!). You pair that with an appropriate op-amp (or op-amps) in front to buffer, perhaps with a DIP switch to allow extra gain if you want, and things look pretty good. This is quite similar performance and design to what @dtcallcock has mentioned above with the AD5542A, except that one runs at up to 3 MSPS (but has about 1.5-2x slower slew rate, all other parameters about the same). Crucially, as has been pointed out, the noise of these DACs is more in the 10-20 nV/rtHz range, so one can be much less aggressive with the filtering afterwards than is required for Zotino.

[dhslichter]

@dtcallcock took the words out of my mouth -- I think Fastino should just be a 3 MSPS dumb SPI DAC board, it'll take very little time to design and lay out because the stuff is pretty simple. You can think about ways to cleverly increase the bandwidth of the data being sent through to get more DACs per card, but if we are going to put these out on SMA connectors then we don't want to go overboard with the number of channels per board. @gkasprow made the suggestion of this quad DAC with a single SPI, which gives more channels but cuts the sample rate accordingly.

A eurocard with 4 channels of 3 MSPS DAC with ~1 MHz analog bandwidth, DIP-switch-selectable (or heck, solder jumper selectable) output of 0 to 10V, +/- 10V or 0 to 1 V into 50 ohms, output on SMA, that uses a single EEM connector, in 4 HP, would be a very useful thing in the lab. It doesn't need to do more than that. Put them in a rack with Kasli and Samplers and you can do fast laser amplitude servo, or digital servo for a piezo, or make trap voltages suitable for fast ion shuttling...

[dhslichter]

The question for Shuttler is, how "fast" does one need to be, if fast transport is the application? A lot of what we're talking about is going to happen in ~10s of us. It seems that one can envision doing this sort of thing with a 2-3 MSPS DAC, which would give several tens of voltage points which could be chosen to approximate the desired predistorted waveform. Certainly a lot of the applications for Shuttler are far enough in the future that it doesn't need to happen right away. The main use case for us, at least, is replacing the PDQs for making trap voltages (and the existing digital servo boxes, for less-demanding applications like doubler locking) with something else that will be more robust, dissipate less heat, have lower noise, and will scale readily in terms of cost, space, and power consumption. So for those reasons, something like Fastino would probably tide us over for quite a while.

[gkasprow]

@dhslichter Exactly. Let's make it simple, 4 -channel with quad SPI. If somebody wants 8 channels, will use another board without sacrificing ADC chip bandwidth. With this approach we get rid of CPLD/FPGA, HDL code and its maintenance. 8-channel version would need 8 HP anyway so it's easier to split to 2x 4 HP. Packing 8 SMAs on 4 HP is problematic - panel isolation, no space for SMA tool. There are many single channel DACs with 50MHz SPI interface with decent specification. I.e. DAC8832, LTC2642, AD5541, LTC2641, DAC8811, This one - DAC8580 could be interesting cause it has 16MS/s update rate. Unfortunately it is EOL.

[dhslichter]

This one - DAC8580 could be interesting cause it has 16MS/s update rate. Unfortunately it is EOL. Really this chip does digital upsampling internally, so it outputs at 16 MS/s but really you are only feeding it data at ~2 MSPS. So don't worry too much that it is EOL :)

Any one of the DACs that you mention above would probably do the trick, and we can argue the merits back and forth. A very important aspect of this all, though, is to get very low noise, low tempco +/-10V references with low-noise buffers for driving the DAC reference inputs (as they draw ~1 mA each).

[gkasprow]

I know it makes up-converting but this makes output filtering easier. I'm not sure if it is essential in our case. It looks like the DAC8811 has all we need.

[dtcallcock]

It looks like the DAC8811 has all we need.

Is there a reason to choose a current output DAC like this over the voltage output DACs discussed above?

I made a table of the contenders. It's a little hard to quickly include the DAC8811 as its performance is intrinsically linked to what external transimpedence stage you build around it.

They are all pretty similarly specced. I would choose the AD5542A because it has 50% less noise than the DAC8832 and doesn't have that big major carry glitch. It's also slightly nicer across the board than the LTC2642. The AD5781 is a 18-bit part I included for reference. The specs are pretty impressive but it's expensive and only has a 35MHz SPI interface (limits to 1.9MSPS).

	DAC8832	LTC2642	AD5542A	DAC8811	AD5781 (18-bit, 0-5V ref)
INL (LSB)	0.5/1	0.5/1	0.5/1		0.25/0.5
DNL (LSB	0.5/1	0.5/1	0.5/1	0.5/1	0.25/0.5
Gain error (LSB)	1/5	2/5	0.5/2		0.2/1.5
Gain drift (ppm/C)	0.1	0.1	0.1		0.02
Zero error (LSB)	0.25/1	2	0.3/0.7		0.19/1.5
Zero drift (ppm/C)	0.05	0.1	0.05		0.04
Settling time to 0.5LSB (us)	1	1	1	0.5	1
Slew Rate (V/us)	25	15	17		50
Glitch (nV.s)	35	0.5	1.1	2	1.4
Digital feedthrough (nV.s)	0.2	0.2	0.2	2	0.4
Output noise (nV/rtHz)	18	10	11.8	12	7.5
Output resistance (kOhms)	6.25	6.2	6.25		3.4
Bipolar resistor ratio error (%)	0.0015/0.0076	0.015	0.0015/0.0076
Bipolar zero offset error (LSB)	0.25/5	2/5	1/5
Bipolar zero tempco (ppm/C)	0.2	0.1	0.1
PSRR, VDD+/-10% (LSB)	1	1	1
Power dissipation (mW)	0.025	0.6	0.625
Price at qty 100	9.5	7.5	10.5	10.5	36.8

[dtcallcock]

+/-10V references

The DAC8832/LTC2642/AD5542A only need a positive reference as they have matched scaling resistors for bipolar operation. They can run off a 5V ref if we're happy to have an output gain stage gain of 2.

[gkasprow]

We need to add output stage anyway, so it could be current output one as well. AD5542A is also good choice.

[dtcallcock]

it's easier to split to 2x 4 HP

I think this is fine, and sticking to vanilla SPI makes this easier to 'humpback'. The only real issue I can see is with total channels you can run off a singe Kasli - 48 instead of 96 for an 8ch card. That said, you wouldn't fit 12 8HP cards in a 19" rack anyway.

[hartytp]

For all but the fastest ion transport experiments (where Shuttler would be used anyway) we are aggressively low pass filtering voltages at ~100kHz. It is nice to keep the clock away from any secular frequencies, but for lighter ions 7.8 MHz doesn't even really do that.

For ion shuttling-type experiments, I would argue that (although, I'd welcome feedback from people who have thought more about this issue than I have):

• assume all secular frequencies (f_z) are <= 10MHz
• the maximum analog bandwidth (ABW) requirement is something like f_z/10 to enable some room for filtering out noise at f_z, so something like 1MHz. That determines both the bandwidth requirement for the AFE (OpAmps etc) and the minimum DAC sample rate, say f_DAC is 2MSPS so that f_nyquist >= f_z/10
• if all you're doing is shuttling, that's fine. But, in practice any non-trivial shuttling means splitting ion crystals, which involves slackening off the trapping potential. A requirement here is that as f_z is swept, it must not pass through any major DAC spurs. In practice, that means the DAC clock frequency must not lie between min(f_z) and max(f_z). This is easiest to achieve if f_DAC >= max(f_z) = 10MHz.
• that's why the extra factor of a few can make a huge difference, even if we don't put a really fast AFE after the DAC

[hartytp]

I see a clear distinction between a DAC board that's designed for adiabatic shuttling/splitting and one that's designed for diabatic shuttling/splitting.

• For the diabatic case, the AFE needs to have ABW >=f_z, which is not true for the adiabatic case. This means the AFE will have to be much faster (BW and slew rate), much higher power consumption and more expensive (particularly since it needs to be both high-speed and DC-precise).
• For the diabatic case, the ABW is > f_z, so we can't rely on filtering to remove DAC noise at f_z. Assuming, say, a 3rd order filter, that means the adiabatic dac can be 60dB noisier than the daibatic DAC. That means there is much more choice in terms of DACs for the adiabatic case, allowing one to use cheaper, lower power consumption models
• For the adiabatic use case, f_DAC only needs to be slightly above f_z. For the diabatic case, f_nyquist needs to be above f_z. So, the diabatic case needs several times the sample rate of the adiabatic case. This means that the diabatic case needs more power/cooling and much more IO -- more IO than an EEM can provide even with a SR-type serdes (it would need a full DRTIO-slave FPGA, which is much more complex than a SR)
• for the diabatic card, @dhslichter wanted CORDICS/SAWG with multiple tones per DAC channel. That pushes to using an expensive high-end FPGA. For the adiabatic case, all we need is a few SRs, which can be implemented using a dirt cheap CPLD or even discrete chips (although, that's not cheaper or easier IIRC).

As a result, the DAC card for diabatic shuttling will need to be much more expensive than the adiabatic DAC card. It will also need to consume more power and IO than an EEM is able to handle, so it has to be an AMC (optionally, +RTM). On top of that, the only real objection i have to AMCs for this is cost. But, once you start splashing out huge amounts of money on ultra-fancy DACs + AFE amps, that's no longer a strong objection.

In comparison, I'm not currently convinced that the DAC card for adiabatic shuttling/splitting couldn't be implemented satisfactorily as an EEM. This is why I still think that shuttler (designed for diabatic shuttling) makes sense as an AMC with expensive DAC chips, but I'm not convinced that we can't build a drastically cheaper EEM for the adiabatic case.

[hartytp]

Then the question becomes "how many different DAC cards do we want to offer in Sinara?" Currently the proposal is something like:

1. Zotino -- 1MSPS shared between 32 channels, low-ish power consumption, low noise and drift, compact (1 EEM) digital interface.
2. Fastino - 1MSPS simultaneous updates on each of 4 (?) channels, ABW of a few hundred kHz probably. Similar noise and drift to Zotino (?). Probably about the same cost. @dtcallcock what's the proposed EEM connector interface here? "Vanilla SPI" with 2 DACs per EEM connector (would that work for "humpback servo", since the number of EEMs offered there is relatively low)? Or, some kind of QSPI to get 4 DACs per EEM connector?
3. DAC3 - 10MSPS simultaneous updates on each of 8 (?) channels. ABW simillar to Fastino. Similar noise and drift to Zotino after appropriate filtering? Compact serial LVDS interface using 4 data wires running up to 125MHz DDR (7.8MSPS), maybe with a dual-EEM mode to allow up to 15MSPS operation.
4. Shuttler - 50MSPS simultaneously on 16 (?) channels, ABW > 10MHz. CORDICS, similar noise to Zotino in filter pass band.

1-3 would be EEMs, costing something like 1.5k EUR each. 4 would be a much more expensive AMC.

FWIW, my feeling is that there is too much overlap between these designs, particularly w.r.t. Fastino and "DAC3", so it would make sense to try to combine those designs as possible.

The fewer designs in our ecosystem, the better supported, better tested and cheaper they will all be. IME, the cost of sillicon is far less of a factor in determining cost of ownership than production volume, so it's generally best to try to make some compromises to make boards as useful if possible.

[hartytp]

Is it possible to make a card that has a high enough spec to replace Shuttler (or at least kick the can down the road) but not so expensive or complicated that it's unsuitable for the Servo and general EEM applications I proposed? If not then I suggest we dial it back to the 3MSPS SPI solution and continue to develop Shuttler.

I think that's really the key question, which I haven't got my head around yet: can the fast-ish DAC for shuttling/splitting be implemented as an EEM with a reasonable cost/power consumption/noise + drift/complexity level/etc?

To answer that properly we'd need a table like the one @dtcallcock produced above, including things like power consumption in mW/MSPS, etc for the faster (>=10MSPs) DAC options.

With this approach we get rid of CPLD/FPGA, HDL code and its maintenance

Note that, based on our experience with Urukul, I expect the cost of developing and maintaining some simple CPLD code to be small compared with the cost of buying this hardware in any reasonable quantity (e.g. enough for a large surface trap like an HOA2).

The main use case for us, at least, is replacing the PDQs for making trap

@dhslichter if we go for 50MHz SPI shared between 4 channels then we're talking about a max update rate of 700kSPS/channel. Is that really enough for anyone whose thinking of doing serious experiments with ion transport (beyond moving an ion from a loading zone to a trapping zone)? Also, is that really a high enough sample rate that that it's worth designing a new board rather than just using Zotino?

[gkasprow]

@hartytp 2MS/s is simple and doable with EEM + LVDS -> LVCMOS converter. 10MS/s requires small 10$ FPGA + serializer development to be able to push such amount of data via EEM and faster DACs which have much worse performance in terms of thermal stability which would require some form of temperature stabilization. It looks like 2 separate designs would be simpler

[dnadlinger]

@dtcallcock: Oh yes, sure; I'm not particularly fond of the MAX5898 for this, either, for exactly the reasons you mentioned (the minimum clock frequency wouldn't necessary be an issue if clocking data more slowly). I mainly wanted to highlight interpolating DACs as one more option in the design space as there might be more appropriate silicon – I haven't had a look in a long time.

As for MAX5898 noise, Ludwig De Clercq has some measurements of the complete system in his ETH PhD thesis (p. 75f.), although the temperature stability measurements weren't very well-controlled at all (and neither were those in a follow-up term project thesis).

---

Either way, no, I don't currently have anything on my shopping list not covered by Zotino or a faster, high-channel-count system.

Shuttler looks nice; possibly a bit over-spec'd for what we are up to. For our use case (current plans in Oxford lab one), we certainly don't need to design around multi-tone CORDICs. I'm not sure why one would want that in the first place, actually; spline-interpolated AWG playback from deep memory (RAM) seems sufficient and is cheap to implement. We definitely want >= 10 MHz sample rate for whatever is our final bid for a flexible transport DAC system, though, both to be able to avoid clock spurs and to be able to apply pre-emphasis before going into the passive filters. (The latter still seems to be the way to go to avoid excess motional heating.)

At this point, I'm not sure whether there is much benefit to be had from an extra board between a ~2 MS/s Fastino and a single Shuttler card. Any "serious" segmented trap experiment will need pulse shaping for coherent control anyway, i.e. use at least one Sayma. In other words, there will already be some µTCA hardware, making the extra support hardware complexity less of an issue (though one could use a single Sayma in a stand-alone enclosure, I suppose).

Yes, for what I'm hoping to get done in the next year or two, Zotino is a bit too slow for that not to be a slight annoyance and a ~2 MS/s Fastino would require careful filtering/clock frequency selection. It seems like expending extra effort on a go-between DAC and thus also further lowering unit counts for the other boards is not the best use of our resources, though. Plus, having the flexibility to play around with transport far in the diabatic regime would be nice in terms of interesting physics.

---

Anyway, back to the topic on hand. A few random remarks on Fastino, without having thought too carefully about this:

• As others have remarked, it would indeed be useful for building a ~MHz general-purpose PID controller. I'm obviously biased by the relative success of the thing we built in Zurich for this, but I would definitely implement that on an FPGA or fast real-time core to keep the latency minimal, as getting close to MHz bandwidths makes a controller quite a bit more useful for laser things. Flexible real-time monitoring (Ethernet streaming) is also very useful for a Swiss-army-knife lab tool.

• We don't actually need excellent DC stability on the DACs on for this; not anywhere near the level we want for trap DACs.

• 16 bit might be a bit more than we need for most applications with sensible gain staging/static trims in the right places (obviously only makes sense if there are e.g. attractive 14 bit DACs available).

• For a standalone voltage-output servo thing to use with a small "humpback" FPGA board, a single EEM with 2xADC and 2xDAC would probably be a more convenient unit, possibly also allowing us to slightly bump the analog in bandwidth.

[hartytp]

10MS/s requires small 10$ FPGA + serializer development to be able to push such amount of data via EEM

Right, so the issue isn't with production costs ($10 on an FPGA is tiny compared with volume pricing differences on silicon/production), only NRE/development costs. Based on my experience with Urukrul, I'm not too worried about that, as I expect the extra NRE involved in designing the serdes to be small compared to the cost of buying enough hardware for, say, an HOA2 (200+ DAC channels).

and faster DACs which have much worse performance in terms of thermal stability which would require some form of temperature stabilization.

Not necessarily. It's true that there is far less choice of fast 16-bit DACs, but there are some good ones. e.g. the AD9726. (NB this is not recommended for new designs, but ADI have confirmed that they currently have no plans for obsoleting it).

In other words, there will already be some µTCA hardware, making the extra support hardware complexity less of an issue (though one could use a single Sayma in a stand-alone enclosure, I suppose).

@klickverbot If we can get the cost per channel of shuttler down to something more reasonable than the current ~$500 then I have no objection to making the fast DAC for transport experiments an AMC instead of an EEM. My motivation for suggesting having an EEM for adiabetic transport is purely cost.

On this topic, I wonder if we can get away with driving an HOA2 from a combination of Zotino and Shuttler. Use Shuttler for anywhere where ion crystals need to be split/etc and Zotino for electrodes which are just used for shuttling ions more slowly. That would get the costs way down.

16 bit might be a bit more than we need for most applications with sensible gain staging/static trims in the right places (obviously only makes sense if there are e.g. attractive 14 bit DACs available).

Do you mean you would be happy with 14-bits for the transport card? Or, just for feedback (where, I agree, the requirements are generally much less demanding).

[hartytp]

@dtcallcock @gkasprow if the intention is for this is to be designed primarily as a feedback card, and not for fast ion transport/splitting experiments (the proposed channel density and bandwidth more or less rule that out IMHO):

• make it 2 DAC + 2 ADC on a card
• NB if you use Sampler as "plain SPI" then, IIRC, the sample rate is <1MSPS split between all 8 channels (i.e. <125kSPS per channel), so it's actually too slow for many use cases. IIRC there are dual ADCs in the same family that work with plain SPI at >= 1MSPs
• for feedback, why not make the ADC AFE simpler and a bit faster. e.g. use the lower gain, higher bandwidth InAmp in the same family, or even scrap the InAmp
• do you need 14-bit DACs for this?
• DAC temp co is a non-issue if this is only going to be used closed-loop, so you have some better, cheaper options if you don't have to worry about that
• this then becomes something very close to the "Stabilizer" design I posted on the Wiki a while back

[dtcallcock]

I agree that if a Stabilizer and a Shuttler (at the low-cost end of what's been discussed) both existed then Fastino might not be worth it. There wouldn't be much point developing a voltage output SU-servo, people would be unlikely to run trap voltages off it, and a compelling use case hasn't been given for a general-purpose DAC that's about 10x better than Zotino (but at 10x lower channel count).

However Stabilizer and Shuttler are complex, unfunded projects, whereas this card is something that could be done very quickly.

[dtcallcock]

I updated the spec at the top of the thread as I think there is a reasonable consensus on what this board would be if it was to exist. Stabiliser and 'EEM/Cheapo Shuttler' should have their own threads.

[jordens]

It looks possible and not too tricky to do ddr quad spi and 8 ad5542a. With two or one cs. That would match sampler and the board space is probably fine.

[hartytp]

However Stabilizer and Shuttler are complex, unfunded projects, whereas this card is something that could be done very quickly.

FWIW, my vision for Stabilizer these days is essentially as an AFE card for Humbpack; just 2xADC and 2xDAC running at about 1MSPS with minimal to no AFE. That's not really any more complex that what's outline here, but is a better match to the feedback use-case AFAICT.

Anyway, it looks like the direction for this project is now somewhat fixed and doesn't overlap well with any of the use-cases I have in mind, so I'll but out and let you get on with it :)

[gkasprow]

@jordens we were discussing about such DDR mode for Urukul. One additional flip-flop would do the job, but tiny (4..5$) FPGA with LVDS would be simpler - it would replace costly (6 EUR each) LVDS buffers and discrete logic.

[hartytp]

That said, the DAC I mentioned above has both unipolar and bipolar modes (with an external op-amp). It seems like it would be fairly easy to switch between the two modes using a DIP switch (DPDT would work).

Not sure how well that would work.

• hooking up a dip switch to a summing junction (inverting input) is likely to make the OpAmp oscillate due to capacitive loading. At the very least, it's likely to kill the bandwidth
• NB the DAC inv/fb outputs are high impedance so you have to be really careful about how you load them
• an analog switch might do the job better than a dip switch. But, still, you have to really watch the capacitance, leakage current, etc. I don't think this will be totally straightforward
• Maybe compromise and have some 0R resistors that can be populated/depopulated to switch to unipolar mode?

[hartytp]

While this is fresh on my mind, some comments on this board:

• let's use the same DAC + AFE as stabilizer
• go for either 16 channels (my preference) or 8 (if we can't easily fit 16)
• watch power sequencing and reference buffering
• Zotino header to allow multiple boards to be hooked up to a VHDCI via IDC->VHDCI (then this becomes a drop in replacement for Zotino in a lot of places)
• Some sensible FP connector (don't really care too much what that is, depends on channel count)
• EEM interface needs some thought. Do we want independent LDAC lines for each DAC? Probably yes. We will need something like 100channels of Fastino in one experiment so we want the option of having a reasonably dense EEM interface. Probably worth putting a cheap FPGA on board to allow some flexibility in the EEM interfaec (e.g. can do 125MHz DDR QSPI with some SRs implemented in the FPGA).

[gkasprow]

Providing that we build the filter with dual opamp, the board size consumed by DAC + filter would be similar as in Zotino. DACs are tiny. So we could even try to fit 32 channels. Small FPGA is a must. DDR QSPI running at 125MHz would give us 1Gbit/s data rate which gives us nearly 2MS/s at 32 channels. WIth DDR QSPI we need to provide a way to tune the clock phase. We can use one EEM line as a feedback where latched input data could be sent back to Kasli. In this way Kasli could tune delay of the clock signal and observe feedback signal to find optimal clock phase. In this way we would use 6 LVDS lines. What about the other two? Maybe one line for status readout, this would let us keep same directions for all QSPI lines