filter design

[hartytp]

Noise plot for the stabilizer filter with OPAx197:

• reduce gain to 2x since we'll use a 5Vref and re-simulate
• look into reducing the peaking

This looks rather noisy all-told. Worth at least considering reducing resistor values.

@gkasprow how did you calculate the filer components?

[hartytp]

Scale all impedances down an OOM to reduce the noise and look again at the FT

The noise does decrease, but so does the filter response, suggesting that the non-idealities for the OpAmp are a real limitation here. Probably less of an issue with a lower gain, but strongly suggests we need to do some work on filter design

[gkasprow]

That's why I added 7.5pF cap to compensate for opamp Cin. You should not change it.

[hartytp]

That's why I added 7.5pF cap to compensate for opamp Cin. You should not change it.

Okay, but for this filter/OpAmp 7p5 isn't enough. Anyway, requires some tuning. Where did you get the other component values from though?

[gkasprow]

I selected value to create a compensated divider. It may need tweaking.

[gkasprow]

The other values were proposed by ADI filter wizard.

[hartytp]

The other values were proposed by ADI filter wizard.

Thanks!

[hartytp]

@gkasprow what filter did you design? Butterworth? What cut-off and Q?

Note to self one of many references on filter design http://www.ti.com/lit/an/sloa049b/sloa049b.pdf (p7 for MFB) on-line tool http://sim.okawa-denshi.jp/en/OPtazyuLowkeisan.htm

[gkasprow]

I don't remember. It should be in the design files I gave you access to.

[hartytp]

@dnadlinger MFB is indeed significantly better in terms of attenuation. Needs a bit of tuning to trade off noise peaking v attenuation and also a Monte-Carlo sim to look at gain tolerance.

[dnadlinger]

@gkasprow: Do you have any experience with MFB (vs. Sallen-Key) low-pass filters in precision circuits? I'm basically waiting someone to tell me that MFB is a silly idea for a reason I didn't consider.

[hartytp]

@dnadlinger the biggest reason I'm aware of is that the AC gain becomes sensitive to component values in a way it's not for SK.

[hartytp]

First thing to fix is the resistor network values. 1k would be great for noise, but then you're looking at the OpAmp sourcing/sinking up to 10mA. Which seems to much if we want any appreciable channel density. So, I guess we need to set the minimum resitance that we source/sink the full 10V through to be something like 10k, which is a bit painful from a noise perspective, but not much choice.

[gkasprow]

I never tried MFB

[hartytp]

I think if you do the spice sim and monte-carol to check the tolerances then you'll get all the info you need. Maybe also just check the step response for good measure.

[dnadlinger]

Re MFB, I'm more worried about non-obvious gotchas (op-amp GBW changes, etc.), which I can't easily Monte-Carlo-simulate in LTSpice. From what I've seen, many people seem to prefer Sallen-Key, but I'm unsure as to why.

Slight changes in step response with component tolerances wouldn't be too big of an issue – if you really care (for accurate transport/pre-emphasis), you'd measure the transfer function of all your filters up to the trap per-channel anyway. Weird drifts, on the other hand, would screw us (although I don't have a good sensitivity estimate for that).

I guess the issue with power dissipation re channel density would mostly be potential drifts induced by the DAC code-dependent heat load? 100 mW * 32 = 3.2 W doesn't seem to be an insurmountable problem.

[hartytp]

I guess the issue with power dissipation re channel density would mostly be potential drifts induced by the DAC code-dependent heat load? 100 mW * 32 = 3.2 W doesn't seem to be an insurmountable problem.

Not insurmountable, but still quite a lot of power! (And actually worse than your calculation since one OpAmp sources while the other sinks, 12V rails not 10V etc). Add to the quiescent current and the the board is drawing quite a lot of current.

As you say, my worries are mainly thermal heat load, and particular dynamic thermal heat load making things unstable.

10k shouldn't be too bad since the in-band noise is still dominated by the DAC, while the high-frequency stuff (a) can be removed by a later passive filter (b) for the MFB topology, I think it's capacitively shunted away in any case, so not a problem.

[hartytp]

@dnadlinger http://www.ti.com/lit/an/sbfa001c/sbfa001c.pdf p10-11

[dnadlinger]

@hartytp: Thanks – yep, those were the points I was aware of (without gain, the op-amp in Sallen–Key is just a follower, so no stable DC gain setting resistor pair needed), but people just seems to use it by default even in situations where the lack of high-frequency attenuation hurts… I'll (LT)Spice up a design in a bit once I got that two-qubit Gate Set Tomography working.

[gkasprow]

I want to finish the Stabilizer. What is the conclusion about the filter?

[hartytp]

This shouldn’t be a release blocker for stabilizer. We can always change in a future release

[dnadlinger]

Observation: The DAC-internal matched resistors for bipolar shifting are 28kΩ each. Thus, each resistor contributes a bit more to the total noise than the 6.2 kΩ DAC resistors (noise gain 1 instead of 2, but four times the resistance). On Stabilizer, those resistors raise the total noise from ~90 nV / rtHz to ~120 nV / rtHz in the filter pass band.

Thus, what about using an external, say, 4.99kΩ matched resistor quad instead of the DAC-internal one, which would also allow us to put all the gain in the first stage? Here is a sketch (LTspice file attached):

(R4 is two resistors of the quad paralleled.)

With the maximum reference voltage of 5.5 V, we'd get ±11 V output, and roughly the following performance:

The second stage is a Sallen–Key filter to avoid having to use a second matched resistor network for gain accuracy (drift), but as it is in unity gain, the high-frequency behaviour is a bit better.

All in all, the above simulates as 50 nV / rtHz at 10 kHz, or a bit less than half the Stabilizer output stage.

(Component values are not optimized yet; I started from a third-order Butterworth response made from a single-pole and a Q = 1 two-pole stage, and reduced C3 from 404pF to 360 pF to reduce the peaking a bit. I can run a sensitivity MC analysis if this look sensible. C1 is probably not necessary, as the OPA197 is quite tame.)

Fastino output stage LTSpice.zip

[dnadlinger]

@hartytp: What do you think about going for ±11 V as we can support that without degrading noise performance? (Vref on the AD5542A is specified up to 5.5V.)

[hartytp]

I did think about that, but doesn't seem worth it IMHO. e.g. where will that ref come from?

[dnadlinger]

We could use a single 10k/1k matched pair to produce 5.5V from a 5V LTC6655.

[hartytp]

Yes, I'm not really against it. Just not sure I can be bothered to go for a less common range for such a small win in S/N. If you want to go for this I don't object...

IIRC the SMPS can be trimmed to >13V so there isn't really an issue with the supplies.

[dnadlinger]

The win would be more a bit of extra headroom for people who are pressed for trap frequency, at the cost of slightly higher op-amp rails. This is mostly a diversion here anyway; the filter design would be the same for 5 V and 5.5 V.

[hartytp]

@dnadlinger good work on that!

Observation: The DAC-internal matched resistors for bipolar shifting are 28kΩ each. Thus, each resistor contributes a bit more to the total noise than the 6.2 kΩ DAC resistors (noise gain 1 instead of 2, but four times the resistance). On Stabilizer, those resistors raise the total noise from ~90 nV / rtHz to ~120 nV / rtHz in the filter pass band.

Yes, it's a pain. FWIW LTC has a range of similar DACs, also with 28k shifting resistors.

Thus, what about using an external, say, 4.99kΩ matched resistor quad instead of the DAC-internal one, which would allows us to put all the gain in the first stage? Here is a sketch (LTspice file attached):

I think that's a very good idea. Nice design.

How much does the noise change by if those 5k resistors go to 10k?

e.g. the max reference current is 1mA / channel which isn't totally negligible.

[hartytp]

@dnadlinger other than thinking about how high we can push the divider resistors without degrading the noise significantly and performing a final component value optimization, I'm very happy with that design.

Also, worth checking the cost/availability of different values of resistor ladders. Is 5k easily available and cheap?

[dnadlinger]

How much does the noise change by if those 5k resistors go to 10k?

Not much, 50 nV / rtHz to 55 nV / rtHz at 10 kHz in the LTspice universe; the DAC Johnson noise dominates. Going to 10 kΩ is probably a good idea; even then, the reference node still needs to source 1 mA at DAC zero for the op-amp (plus the current draw from the DAC itself).

@gkasprow @hartytp: To summarise, I don't think I'll be able to significantly improve on the above design (save for tweaking some component values to fine-tune the filter response or for BOM optimisation). It looks like it should deliver half the noise and power dissipation compared to Stabilizer, at a tenth the op-amp cost. Thus, I'd suggest going with this topology for now, at least until we have some evidence to the contrary.

It would be nice to validate the design on a Stabilizer before producing a whole batch of Fastinos, though – does anyone have time to hack up a board in the next few days? I'm a bit low on bandwidth at the moment since we are working against a deadline (Raman laser replacement).

[dnadlinger]

Also, worth checking the cost/availability of different values of resistor ladders. Is 5k easily available and cheap?

10kΩ is fine too; and I'm sure Vishay/… make that.

[gkasprow]

we have 2 matched, not used 5k resistors for free inside of RN5 package

[hartytp]

@dnadlinger okay, if 10k is fine let's go for that.

[dnadlinger]

@gkasprow: The design moves RN5 to the first op-amp, and uses the second in unity gain.

[dnadlinger]

Here's a version with a 10 kΩ quad and set up for Monte-Carlo analysis:

Fastino output stage monte-carlo.zip

The OPA197 model is included, so the file should work out of the box on any recent LTspice install. Just uncomment one of the analysis commands for transient/AC response/noise analysis.

R6 is currently at 0Ω – since the DAC resistance is only specified as ±20%, we could add e.g. 5 kΩ there to reduce the variations in response. It seems like the only reason to do that in a typical ion-trap application would be temperature drifts, rather than absolute variations, as usually one would prefer the lower noise even if one has to measure the transfer functions per-channel for pre-emphasis.

[dnadlinger]

FWIW LTC has a range of similar DACs, also with 28k shifting resistors.

Aside: I don't quite understand that either – I'd have expected roughly twice the DAC output impedance for bias current cancellation, not four times.

[gkasprow]

With 2 precise resistors, we can replace the divider with lower cost and also much smaller one

[hartytp]

But you need three resistors (gain feedback and reference)

[gkasprow]

OK, there is one extra to GND to have the gain higher than 2.

[dnadlinger]

OK, there is one extra to GND to have the gain higher than 2.

One extra to V_ref actually to keep mid-scale input at zero output. If a 2:2:1 network was available in a four-pin package, we could of course also use that.

[hartytp]

@gkasprow let's use the topology that @dnadlinger posted above. I think he wants to double check RC values at some point, but that's a quick change for later on. The topology and OpAmp choice won't change.

[hartytp]

(In particular, double checking whether the DAC output resistance tolerance is too bad to have the first filter capacitor)

[gkasprow]

This the reason I added 10k at the DAC output to lower overall tolerance. Of course, this adds noise. We could make the first stage at a slightly higher frequency than the rest of the filter poles to make sure it won't dominate the filter response.

[hartytp]

We could make the first stage at a slightly higher frequency than the rest of the filter poles to make sure it won't dominate the filter response.

Exactly, I suspect we'll do something like that. But, that's an easy change to make later on since it's just an RC BOM change.

[jordens]

The filter corner looks ok. But it has that bump between 2 and 10 MHz where it attenuates only between 60 and 70dB (eyeballing the plots). This is not what one would typically want from a 16 bit reconstruction filter for 2MS/s and it deviates a lot from the expected rolloff for a filter of that order.
There are always the trap rf rc filters which will provide more attenuation and I know that the stopband and rolloff are typically a problem for active filters. But still, this is the critical window.
If we decide to generally rely on the downstream trap filters to provide proper stopband attenuation at >1 MHz then maybe this filter should be tuned to serve another purpose, e.g. notching clock leakage.

[dnadlinger]

This is not what one would typically want from a 16 bit reconstruction filter for 2MS/s […]

The filter actually dips below the ideal response at ~3 MHz, so for more attenuation at 2 MHz, we'd need to go to a higher-order design. A bit can of course be gained by accepting some passband ripple.

In any case, using an MFB filter instead for smoother roll-off is an option, at the cost of an extra matched resistor pair and somewhat increased noise/current consumption, see https://github.com/sinara-hw/Fastino/tree/master/SIM_CALC/Output%20stage.

maybe this filter should be tuned to serve another purpose

I did bring up the possibility for more complex designs a while ago (e.g. notch at target clock frequency) but in the end, it seemed like our best bet for the first revision of Fastino would just be a boring design with conservative, generic choices.

Unless you are planning to mount Fastino directly at the trap can, you'll always want significant passive filtering close to the electrodes anyway, as reaching sub-nV/rtHz on something dangling off a long cable is hard. Assuming some 30–35 dB attenuation at 2 MHz, the total gain at 2 MHz would be around -80 dB, and significantly better at harmonics. This seems good enough to be a workable starting point.

In any case, I don't really want to get involved in choosing the filter response, as I don't currently have the bandwidth for what seems to me to be the most principled approach: Simulate some transport waveforms for my experiment, and choose filter topologies and locations based on target speed and heating.

[gkasprow]

Can we stay with such filter design and continue routing?

[hartytp]

@gkasprow yes

My reasoning here is that this filter is pretty cheap to implement -- we need an OpAmp here anyway for gain and ref subtraction, and going to an SOIC8 dual AOP2197 adds very little to the cost/power consumption -- and it does make a useful contribution to the filtering, easing the requirements on subsequent passive stages. e.g. it does a decent job of killing image frequencies above 1MHz.

[hartytp]

Thanks again @dnadlinger for doing this!

[gkasprow]

@hartytp the most critical routing is already done
Look here

[hartytp]

Nice! I'm still a little worried about digital-analog cross-talk. Particularly for the channels near the FPGA. We'll have to put some thought into grounding and routing to minimize that.

Otherwise, looks really nice!! Really glad to see it so close. Should be fairly quick to finalize once we pick the FPGA.

[jordens]

@gkasprow don't put too much time into the final FPGA routing yet. I'll have a bunch of change requests.

[gkasprow]

The FPGA routing is the quickest part of the job thanks to automation - pin swapping tool.
The reference tracks have ground plane below and analog supply plane (not poured yet) above so don't worry about the crosstalks and they are well separated from digital lines.

[hartytp]

Cool!

[jordens]

Another note: the filter needs to be really good to kill the ~20mV pk-pk 50MHz digital feedthrough. The -120 dBFS attenuation simulated look good if the opamp models are accurate at those high frequencies and if there is no unexpected coupling (the layout is very tight).