I'm discussing options with Ryan.
We are purchasing one LXD31k4 board, but notice that latency is not so great for the ADC and DAC on it. For the ADC, the pipeline delay (latency) is 26 clock cycles/300 MHz = 87 nSec and for the DAC the latency is 134 clock cycles/300 MHz = 447 nSec.
He found a low-latency (better than 4 nSec) DAC board AD9740-FMC-EBZ but with only 10 bits. So we need to understand how to make that trade-off between #bits and latency.
This ADC card has 12 cycle latency at 125MHz, (96 nSec) dc-coupled, 16-bit, 4-ch + 1 DAC
https://www.vadatech.com/product.php?product=900&catid_now=0&catid_prev=0#prettyPhoto
but the DAC on that one is the DAC3171 which can run up to 500 MHz for a 26 nSec latency at 14 bits.
Ryan found a discussion board on a low latency solution for ADC => FPGA => DAC (basically what we want!) from 8 years ago - looks like this was their conclusion on which chips to use:
The ADS5400 (1GSPS, 7ns latency) and DAC5670 (2.4 GSPS, 4.42 ns latency) are the lowest latency converters currently available.
Ryan is discussing what it would take to build a custom FMC board with these chips.
So, Ryan suggests these purchases to evaluate our options:
===================================================================
From a RedPitaya discussion board on a fast PDH controller: https://forum.redpitaya.com/viewtopic.php?t=1354
by Nils Roos » Thu Mar 31, 2016 9:17 pm
From the datasheets of the ADC and DAC you can derive some estimates for the expected latency.
The ADC has a pipeline latency of 6 cycles plus some nanoseconds clock to output delay. At 125MHz this gives ~50ns latency from the moment the input is sampled to the moment the data is available at the FPGA. The FPGA's input buffers add one cycle, as do the output buffers, and then there is internal routing which typically comes to <10ns, so without any further processing, you get 26ns additional latency through the FPGA. The DAC has 2 cycles of data input to analog output latency, another 16ns. Thus, you end up with just under 100ns minimum delay from analog input to analog output.
===================================================================
For reference, RFSoC solutions claim to have about 120 nSec latency, depending on how they are configured. (The sample we tested from Leo did NOT optimize at all for latency)
Ryan adds this to the discussion:
I confirmed with Craig Drennan, in AD, that they are using this ADC in their MicroTCA solutions (but they only have AC-coupled) from Vadatech:
ADS42JB69
Then I asked:
Would we be able to have DC coupling on a custom board?
Does this leave room for DACs on the same board, or is it a total of 16 ADC+DAC channels?
Looking at the data sheet, in 10x mode the max sample rate is 250 MHz and the latency is given in two ways.
and he responded:
Yes, definitely we can do DC coupling on the custom board.
We need to find a similar DAC solution. That is next. But it could be on the custom board too. I am imagining a 2nd Artix 7 using 16 lanes for DAC channels. And then the two Artix7s communicate with each other over GPIO.
If we make it in an RTF (uTCA rear panel) form factor, it would add scaling up ability (maybe AD would even use it).
The formuta for quantization noise is
12**0.5 * 10V * 2**(-N_bits) / (F_sample)**0.5 (in V/rtHz).
the factor 12 is for the uniform distribution, 10V ADC/DAC range. N_bits is the dynamic range of the ADC and the sample rate how fast you will be sample.
I think you should shoot for the 50nV/rtHz - 500nV/rtHz range. Slow ADCs and standard osc scopes get 1uV/rtHz, so this should ideally do better than those. With a 25MHz sample rate, that is going to take 14 or 16 bits. 10 or 12 bits appears to be a bit too low for noise. We can use frontend filters to help that, but then we need to add those to the boards (which we can do!).
I would say if you have some latency of T=250ns, then the sample rate only needs to be about 4x as high as that sample rate, or 4/T ~ 16 MS/s. So a sample rate of 25MHz would be about right for controls applications. 100MHz is better for data acq applications. It can be higher, if it still helps latency, but sometimes the number of needed clock cycles goes down with the sample rate.
Having an excessive sample rate, when it does not help latency, can be a bad thing since it makes designing filters worse (filters take more bits when they are faster).