Using multiple LVDS ADC in a single Arria 10 GX IO bank

[corestar]

I want to use 8 LTC2271 16-bit ADC in an Arria 10 GX 320. They use serial LVDS and each one needs 4 LVDS pairs (bit clock, frame clock and 2 data lanes). The FPGA has 8 IO banks, so we could clearly put one per bank, but that consumes the whole chip. We use one ALTLVDS_RX core per ADC.

All the ADC will be clocked using the same source, so they will have the exact same frequency. Only the phase will vary.

Is there a way to use the "external PLL" mode to put more than one ADC in a given bank? Each bank has 24 LVDS pairs, so I would then just need two banks.

It seems like this should work, but I've seen other posts implying otherwise.

Each LVDS core should latch it's ADC using the given ADC's bit clock. Doesn't the PLL just generate clocks needed on the fabric side?

I don't know of any ADC that use 24 LVDS paris; seems like a waste to have that many in  a bank if there is no way  to use them. 

[FvM · Accepted solution]

Hi,
it's not generally necessary to connect DCO and FRAME clock of all ADCs. There are different choices to acquire the serial data.

- use individual DCO and FRAME clock but no RX PLL. At least DCO must use dedicated clock input.

- use FRAME clock and PLL per ADC, generate bit clock internally. FRAME must use dedicated clock input
- if delay skew between individual ADC is small enough (e.g. no additional buffers and long traces involved), use common DCO and FRAME clock for all ADC
- if you are unsure about delay skew but want to avoid individual clock inputs for each ADC, you can use soft CDR with training pattern on startup. Need to connect ADC SPI interface 

[corestar]

Hello @FvM 

That's alot to think about.

Side Note: In the past (using Cyclone V) we did not bother with a FRAME clock at all. Used a test pattern for bit slip and it also gives a nice warm feeling that all the data is coming in correctly.

Regarding your list:

- use individual DCO and FRAME clock but no RX PLL. At least DCO must use dedicated clock input.

Are you saying I don't need a PLL at all?

- use FRAME clock and PLL per ADC, generate bit clock internally. FRAME must use dedicated clock input

I'm afraid we don't have enough PLL for that. Unless we can use an fPLL. Does the LVDS serdes care what kind of PLL is used? If not, I could just feed the DCO into an fPLL and put multiple ADC on a bank with no problem.

- if delay skew between individual ADC is small enough (e.g. no additional buffers and long traces involved), use common DCO and FRAME clock for all ADC

I'm not sure we can depend on that even if all the traces are the same length. For the LTC2271, we have a DCO of 160 MHz. It outputs the DCO at the center of the data but with significant variation of 0.3 tSER (which 3.25 ns). Almost a ns. Then the tPD between the ENC clock and DCO varies by another 0.8 ns. Seems risky.

- if you are unsure about delay skew but want to avoid individual clock inputs for each ADC, you can use soft CDR with training pattern on startup. Need to connect ADC SPI interface

Need to investigate this option more. Looking at Figure 110 in the Arria 10 handbook, it still shows an IOPLL. Are you saying use a single DCO input to drive a PLL that drives more than one ADC (all in same bank)? Then let the DPA pick the right phase for each ADC LVDS lane?

The LTC2271 centers the DCO on the data very nicely. I had not planned to use DPA (they Cyclone V did not even have it). It seems to me DPA might actually screw things up. There are only DPA 8 clocks 45 degrees apart.

If I could use an fPLL as an external LVDS PLL, it seems like the whole problem goes away.

Thanks for the help.

[FvM]

Hi,
sorry for delay. 

- yes, you don't need necessarily RX PLL. Might need to setup your own deserializer because SERDES IP probably doesn't support this operation mode, but I didn't try on newer devices with SERDES IP. Major drawback is requirement of a dedicated clock input per ADC. Just wanted to mention the option.

- I agree that DPA solution is probably overengineering for rather slow 320 MSPS. 

- You don't tell how you want to set clock phase with your (single) external PLL solution. If phase isn't measured and adjusted online (DPA/soft-CDR solution), it has to be preset to a fixed value. How is this different from my suggestion to use common DCO and frame clock? You can at best compensate for known trace delay differences by setting individual phase shift.

[corestar]

@FvM,

- yes, you don't need necessarily RX PLL. Might need to setup your own deserializer because SERDES IP probably doesn't support this operation mode, but I didn't try on newer devices with SERDES IP. Major drawback is requirement of a dedicated clock input per ADC. Just wanted to mention the option.

I think I understand. A shame to waste the SERDES though. Also, the LTC2271 was an example. We may go to higher speed.

- You don't tell how you want to set clock phase with your (single) external PLL solution. If phase isn't measured and adjusted online (DPA/soft-CDR solution), it has to be preset to a fixed value. How is this different from my suggestion to use common DCO and frame clock? You can at best compensate for known trace delay differences by setting individual phase shift.

If you're referring to my question of if I could use an fPLL, I meant to say I would use an fPLL per ADC, not one for all of them. Some banks have multiple clock inputs which would determine how many ADC per bank. Of course, would have to try it and see if the tools complain.

But a better way might be your last suggestion. Say I want four ADC on a bank:

1. Create 4 ALT_LVDS cores in external PLL mode with DPA.
2. Feed the DCO from one ADC into the IOPLL on that bank
3. Use DPA on all LVDS data lines.
4. Use test pattern to do bit-slip per ADC

It seem to me, the DPA would be off by at most half of 45 degrees or 22.5 degrees. In practice, the perfectly centered 90 degree offset option of the LTC2271 will have some variation anyway. 

This would actually save alot of traces. No need for FRAME clocks at all (true of any solution) and really only need the DCO from say a fourth of the ADC.

Of course, you never know what the tools will complain about. It's all a bit unclear still.

Thanks for the help.