[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]

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.

Great! I'd be really happy if we can get 16 or 32 channels on this.

If necessary, we could consider scrapping the CMCs to save some space/cost.

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

Yes, there is clearly enough BW to run 32 channels of DACs from 1-2 EEM connectors. The challenge will be coming up with a nice interface and thinking through the details.

I don't have time to do that right now (as I said, we won't need this board for a while). For now, I'm just jotting down some notes of the things we'll need to think through when we come back to this properly.

[gkasprow]

I did some quick estimate of the board real estate. It looks we will fit 32 channels easily including same FPGA as in Banker. The board will be quite expensive - we need to use precision resistor arrays in each channel for gain setting. And it seems that we will easily build output amplifier with just dual opamp chip per channel. More details in Stabilizer thread. Some pics:

[hartytp]

Thanks Greg! Good to see that space won't be as much of an issue as I'd feared. Cost, power consumption etc will need careful thought. Will this be a 4-layer board or a 6 layer?

Anyway, let's put this on hold until we've finalised the Stabilizer design.

[gkasprow]

It's already specified what we want so can move it to dedicated repo.

[gkasprow]

Anyway, let's wait until we debug the Stabilizer (DAC part) and Banker (FPGA part) first.

[hartytp]

Thoughts about Fastino having played around with Stabilizer:

• Generally, looks like we can reuse the analog parts from Stabilizer without major changes
• The in-band noise is basically white at ~100nV/rtHz. That agrees with a back of the envelope from the schematic; DAC is 12nV/rtHz (and there aren't really any lower noise options); AFE gain is 5 to get +-10V with 4.096Vref (can potentially use a gain of 4 with 5V ref but there is the usual issue around ensuring that the supply voltage is actually higher than the reference voltage once accuracy of all components is accounted for); the rest is largely due to the Johnson noise of the ~10k resistors we're using in the AFE. For reference, the NIST PDQ is also around 100nV/rtHz and the ETH "DEATH" boards are around 70nV/rtHz. We could get the noise down a bit by e.g. increasing the ref voltage (decrease AFE gain) and decreasing the resistors used in the dividers. Before doing that we should consider what we actually need for experiments and whether it's worth the fuss
• Still need to measure the noise at higher frequencies to check what the active filter is doing. My guess is that it doesn't do much since the final stage noise + gain is still relatively high (again due to the 10k resistors). Probably fine as we can put a passive filter near the trap, but worth having a think about this.
• The reference buffer solution on Stabilizer seems good. We may be able to get away with 1 ref buffer per 8 (or more) DACs (instead of the 4:1 ratio on Stabilizer) particularly if we switch to the LT3045 (lower output impedance), but needs simulation.
• The major piece of work is the digital section (deserializer interface) which needs to be prototyped before we can actually start on the HW

[gkasprow]

The deserializer can be easily prototyped with Humpback. I plan to reuse its digital section entirely. The sampler can be attached to it and SPI lines can be directly routed to the FPGA after removing the '125 buffers.

[hartytp]

The deserializer can be easily prototyped with Humpback. I plan to reuse its digital section entirely.

I'm not so worried about prototyping on HW itself -- you've shown that you can lay out FPGA/CPLD projects like this very reliably. What I'm thinking about is writing the code ahead of time and checking it builds, meets timing, etc. It's not a huge job, but it needs some thought to get right

[gkasprow]

the question is if we want to have independent control of all DACs? Or we can assume that they will be updated simultaneously and we can route common CLK and NSS lines. We have ~90 3.3V IO lines. Rest are in the 2.5V bank. We can route only 2 dedicated lines per DAC. If we add 2.5-> 3.3V converter we could route 3 individual lines to every DAC, but I'm not sure if that is necessary.

[hartytp]

Yes, it needs some thought. I have some ideas, but I'd prefer not to start a conversation about it until I've given it some more thought :)

[gkasprow]

Another question we need to ask is the application. Is the board going to be used for fast update of a single channel, massive streaming of data to all channels or both? And, is the latency critical?

[jordens]

@gkasprow could you give me write access? I'd like to add specification and details to the wiki.

[jordens]

@gkasprow Are you sure about that IO count? On Banker you have routed 128 IOs plus 16 direction signals on three banks that could be 3.3V (not counting the LVDS bank at 2.5V). That would map to 4 signals per DAC plus spares for LEDs and shared CLR.

[gkasprow]

@jordens I assumed that will have only two EEM connectors. Some of 2.5V can be used for 3.3V signaling as outputs.

[gkasprow]

I gave you access rights.

[jordens]

Even with three eem connectors there should be enough io to give each dac 4 lvcmos 3.3 signals. That's sufficient for completely independent control. Clr can be shared.

[gkasprow]

True. I didn't count one bank. We have enough pins.

[gkasprow]

Is there any use case for 3 EEMs?

[hartytp]

Is there any use case for 3 EEMs?

I don't think so. My assumption is that we can probably run the whole thing from a single EEM (see Robert's spec on the Wiki), but having a second one for contingency/expansion is a good idea. That would still allow us (ignoring current consumption, heat etc) to drive 192 DAC channels per Kasli.

[hartytp]

Hardware, gateware and software funded by U Oxford