ADC SPI buffer delay

[jordens]

The buffers have 4.3 ns prop delay. In roundtrip that adds up twice to the adc clk to sdo delay and the stm32 miso setup delay. This limits sample rate and transfer speed. We could play some tricks with 17 bit and cpol=1,cpha=0, dropping the first bit but it's not nice and doesn't work with all channels. Reconsider this at some suitable time.

4.3ns (SCK) + 7.4ns (ADC) + 4.3ns (MISO) + 1ns (tSUMI µC) = 17ns which would limit SCK to a 34ns period compared to the 15.6ns possible from the ADC and 20ns possible from all of the SPI channels.

[gkasprow]

you can enable some delay to other lines using CPLD :D But it is not elegant.

[jordens]

Adding more delay somewhere else doesn't solve the issue.

[gkasprow]

What can we do here? Change the CPU to something else? Or just changing the SPI assignment solves the issue? 17bit SPI can make issues with DMA.

[jordens]

We first have to decide whether those buffers are really required. If not, then remove them. If yes, then maybe there are faster ones. If not, then we can use falling edge sampling (a bit tricky, 17 bits, discard first, cpol=0, cpha=1, would work better with the 32 bit wide SPI123 buses). Or we live with it and tweak the clocking so that the ADCs run at >34ns (which would also require them to be both on SPI123 or both on SPI45 for clocking reasons and it would preclude the merging of a DAC/ADC pair on a single SPI bus). DMA (of the SPI data) may not even be useful/required for the dominant application and I don't see an issue with it for 17 bits right now.

[hartytp]

We first have to decide whether those buffers are really required. If not, then remove them.

@jordens yes.

The motivation for these buffers wast that @gkasprow had seen issues in the past where noise on the digital lines coupled into the ADC and degraded its noise floor. I assume that this effect is strongly dependent on the particular ADC, and it's not obvious to me whether or not it will be an issue in this design.

To know that, we'd need to test. If anyone has time to do that then it would be great. Otherwise, my assumption was that -- at least in the applications I have in mind -- we can live with the delay and just slow down the ADC. But, I haven't looked into the clocking options, so that may not work.

[gkasprow]

We may use faster logics, i.e. AC logic I observed such issues with FPGAs. Maybe this particular CPU won't inject so much noise.

[jordens]

Maybe the cnv buffer is the only one that we need. Or cnv and clk. @gkasprow did you see jitter/phase noise or amplitude noise? The former is not that critical for us. Iirc it was a ccd adc. That would also be mostly sensitive to amplitude noise/injection.

[gkasprow]

It was an amplitude noise. The BW was too small to observe the clock jitter influence.

[hartytp]

I'll try and have a look at this at some point in the next few days.

[hartytp]

@jordens @gkasprow I'm happy to test this, but first I'd like to clarify what the plan is: the ADC LVCMOS inputs run from a max 2V5 supply. Am I right in thinking that the microprocessor uses fixed 3V3 logic levels? If so, how would you plan to do the level conversion?

[hartytp]

The other option is to replace them with a faster buffer like http://www.ti.com/lit/ds/symlink/sn74auc2g34.pdf (@gkasprow are you aware of any faster parts that are still footprint compatible with the ones on Stabilizer?)

At that point the propagation delay doesn't affect the overall timing budget much.

unless anyone has a better idea, I'll order some of those, swap them out, re-check the noise. If that looks good I suggest we make the change for v1.1.

[hartytp]

SN74AUC2G34DCKR would be the replacement PN

[gkasprow]

the 74AUP1G125GW I used accepts 3.3V at its input and protects ADC against 3.3V signals from CPU In the other direction, 2.5V is still logic H a the STM32 input so one doesn't need a level translator

[hartytp]

@gkasprow okay, so how about we scrap the ADC output buffers and replace the input buffers with SN74AUC2G34? Any objections?

[gkasprow]

I'm fine with that.

[jordens]

Getting rid of the buffer on MISO and speeding up the buffer on CLK by a couple ns is all that's needed.

[hartytp]

I'm planning to run a quick test with the SN74AUC2G34 I have in the next couple of days. But, it probably makes sense to use a different part with better availability for the next revision (just chose that as it was footprint compatible with the current part).

[gkasprow]

you can replace them with 100r resistors

[hartytp]

@gkasprow the part I quoted above was a 2x buffer, so not a valid replacement. Do you know of any faster, pin-compatible replacements for 74AUP1G125GW?

you can replace them with 100r resistors

You mean to limit the current through the ADC protection diodes?

[gkasprow]

Yes, this resistor is to protect against latch-up event.

[gkasprow]

we can use dual buffer which has 0.5...1.2ns delay at 2.5V Alternatively we can use 241 or 126 buffer

[gkasprow]

I used SN74AUC2G34DCKR