Multiple High Speed ADCs via serial LVDS

Nobody to comment on this?

Too sad :-(

--- Quote Start ---

Nobody to comment on this?

Too sad :-(

--- Quote End ---

I don't recall seeing this post.

One thing your analysis/description has missed is what needs to happen to the data once you receive it.

Sure you could get all of the data onto one FPGA, but if that data needs to "go somewhere", then you need enough bandwidth to get it off the device too.

What about signal processing? What needs to be done?

Why have you selected 12-bits at 80MHz? What is the bandwidth you are interested in, and what is the dynamic range of the input signals?

Cheers,

Dave

One point of relief: THE LTc2173-12 delivers a 90° shifted serial bit-clock so you don't need any PLL's to capture the incoming data.

You can drive all ADC clocks with a single PLL driving multiple outputs (using ALTDDIO_OUT). If you lay-out your board carefully you can achieve simultaneous sampling of your input data over all ADC-channels. I used that to sample 128 channels using 16 octal ADCs (by TI) delivering 12 bit at 50 MS/s. Unfortunately I don't have any nice documentation (as Dave makes) on this, and have to look deep in the design notes (paper) file.

You don't need to use ALTLVDS_RX to capture a 560 MBit/s DDR stream. You choose the DCO as the input clock and treat the FR as an input signal like the OUT channels, and use this FR signal to qualify the serial to parallel conversion. This technique also works for Texas Instruments and Analog Devices ADCs (and presumably other manufacturers).

--- Quote Start ---

Hi everybody,

for a new system there is the need to digitize data with 12 Bit/80Msps from up to 20 channels.

To date the idea would be using multiple Quad ADCs with serial LVDS links source synchronous to e.g. a Cyclone V FPGA.

The ADCs could be LT2173-12 (8 data links @ 560 MBit/s each, data frame and clock output available).

All devices are running at the same speed.

I would be very happy to get some insight and comments on the idea, especially the following aspects:

I would use one altlvds_rx instanciation for data reception from each of the ADCs.

Therefore I'd route the data, frame and clock links of each device to a seperate altlvds_rx.

The problem I now see is that when I instanciate one megacore function for each ADC interface, I run out of PLLs (each altlvds_rx consumes 3 generic_pll blocks). Right?

There is the option to share PLLs between multiple receivers. But in this case I think the timing of all devices must be very closely matched as I can not compensate each receiver individually. Am I right?

One solution I was thinking about is driving the input clock to each ADC from a seperate FPGA internal PLL output and use the shared pll approach provided by altpll_rx for data capture.

I could then at least compensate general routing delays between different devices, right?

There may be other solutions by using external PLL devices, perhaps somebody has some good ideas on that.

If I share the plls, are the clock / data outputs on the altpll_rx outputs in sync?

Or do I have to resync them to an additional 80 MHz internal clock?

Is anybody here in this forum who has done such things (maybe with less but also multiple ADC devices :rolleyes:) in the past?

Is the idea completely non sense and simply impossible to get all that data into a single device?

Using multiple single channel ADCs with parallel or DDR interface is no option due to the amount of user IO necessary (there will be other things connected to the FPGA in addition).

Of course I could use several FPGAs but this will blow up board space, power requirements and simply COGS.

Thanks a lot in advance for any comments,

Volker

--- Quote End ---

Becuase you used LT chips, why not use LTM9009 (embedded 8 channels) or LTM9012(embedded 4 channels with amplifier circuits)?

For multi-channels or multi-ADC chips, is it possible that the DCO do not need inside FPGA? Can we use internal same frequency clock as ADC data reference clock? So we can save one lvds channel.

--- Quote Start ---

For multi-channels or multi-ADC chips, is it possible that the DCO do not need inside FPGA? Can we use internal same frequency clock as ADC data reference clock? So we can save one lvds channel.

--- Quote End ---

The shift between the supplied ADC clock and the resulting output DCO clock is not well specified making it (IMHO) impossible to set the exact capture point. So you need to use the DCO clock itself to sample the data streams.

Referring to the original post, I don't understand the bitrate calculation. 80 MSPS*12 Bit means 960 Mbit/s, feasible only with Stratix or Arria FPGA families. But these devices could use the SERDES DPA feature and won't need individual PLLs per ADC.

With Cyclone FPGAs, you have preferably a PLL per ADC, clocked by the frame clock output. Using no PLL and both FCO/DCO should work too, but misses an option to fine tune the phase for operation near the FPGA speed limit. Finally, you can generate the receive timing by the PLL driving the ADC, but due to the large propagation delay skew, it won't work a highest speed, as mentioned by josyb.

Or you implement automatic phase calibration (similar to the DPA feature of the hardware LVDS blocks) based on PLL dynamic phase shift and ADC test modes.

Hi all,

thanks for the big attention :-)

i try to summarize and answer the questions:

@dwh

You're right.

The full bandwidth isn't transmitted from the FPGA.

I can not go into exact details of the project, but the data rate leaving the FPGA is far less then the incoming data rate (averaging of sample trains is performed and a selection / mixture of channels).

In the end 160 MByte/s max. will leave the FPGA which seems to be feasible for current bus technology to handle (e.g. USB 3).

@josyb

thanks for the interesting comments! Bypassing the altlvds_rx function was not an option to me before. Very welcome. This would mean I have my deserializer with the DCO clock which is 560 MHz. Am I right? This looks challenging for a Cyclone on first sight...

@Jerry:

A quad ADCs is used due to system granularity (the system shall be extendable by multiples of four ADC channels. @Jerry Otherwise the Quad LTC one would be have been an option. I do not know the LTM9012 - may be an option, I will check. Thanks for noting!

@FvM

The device transmits 2 Bits in parallel for each channel (two Links in parallel for each channel, "2 lane mode"). Thats why it's feasible on a low cost FPGA from my point of view.

I will go into details regarding the DPA feature.

Thanks again for your very helpfull comments!

I'll be back with new questions if necessary ;-)

Volker

--- Quote Start ---

The ADC can output the data over 2 lanes, halving the speed requirements to only 480 MBit/s which can be handled, hands down, by a simple deserialiser, using the DCO as the main clock. In a project, a couple of years back now, I deserialised 4 octal ADCs running 50 MHz or 600 MBit/s on an EP2C8F256-C6N. No need for calibration.

--- Quote End ---

Hi josyb,

Thanks for you informations.

In some 8-channel ADCs, there are two DCO, which means each DCO in charge 4-channel. Same as FCO. So in some cases one fpga maybe want to connect multi-ADC chips, the channels are too much and there are not enough didcated serdes inside FPGA. We need to use DDIO + Shift-Register to receive the ADC data, as attached image shows. It seems we don't need to use the DCO.

--- Quote Start ---

The ADC can output the data over 2 lanes, halving the speed requirements to only 480 MBit/s which can be handled, hands down, by a simple deserialiser, using the DCO as the main clock. In a project, a couple of years back now, I deserialised 4 octal ADCs running 50 MHz or 600 MBit/s on an EP2C8F256-C6N. No need for calibration.

--- Quote End ---

Hi josyb,

Did you process the FCO as normal data channel? Otherwise, i don't know how to align the data frame!