Cyclone V LVDS deserializer bitrate

[Spieler]

Hi,

I am writing to see if we can identify the reason why the LVDS receiver of our system has problems to receive the incoming stream properly.

The incoming stream comes from an LVDS ADC (AD9257) that consists on 8 LVDS data lines (1 line for each ADC channel), a frame clock LVDS line to align the boundaries of the received data and an LVDS clock line to which both data and frame clock lines are center-aligned. That is, for each AD9257 in our system we receive a total of 10 LVDS channels.

According to the specification of the ADC AD9257, the maximum clock-to-data output difference is 300ps, and the length of all the channels are matched with a maximum difference of 3mm (below 40ps).

With all this said, achieving a proper data reception at a bit-rate of 580MHz should be easy according to Cyclone V GX specs and the speed-grade (7) of the device we are using.

However, we are having problems to receive all the data properly. For instance, even after a period of time left to align the data-words to its boundaries using the frame_clock signal, the word-alignment is lost besides of the wrong reception of the data with fliping bits,...

We have tried to setup the ALTLVDS_RX core in both internal and external PLL clock, using the latter configuration to try to find the best clock phase shift to sample the data, but still without good results. 

At this point we are running out of ideas, we think that our time constraints should be fine and we have could meet the timing. For that reason we would like to know if there is a setting we are not using and at the same time ensure that the ALTLVDS_RX is is able to receive data at these rates for the FPGA we are using.

One point that comes to our minds is the LVDS termination. So far we are using the internal FPGA termination for LVDS channels, but due to the high tolerance (40%) we do not know if it would be advisable to mount external termination resistors, and if this could be the rootcause of our reception problems.

Thanks!!!

[Rahul_S_Intel1]

Hi ,

Hope you the serdes circuit for the Cyclone V is using the dedicated circuitry in your setting.

As you said termination is an another point to note. Please ensure that the termination is on internally on the FPGA.

Regards,

Rs

[Spieler]

Hi Rs,

Thanks for your answer.

Yes, we are using the dedicated circuitry to deserialize the incoming stream. This is the reason why we do not understand what is going wrong. Timing is met, the differential termination is set as well, the length of the LVDS lines are matched, but still we have problems to receive the stream of data at 580Mbps.

My question regarding the termination was in the sense that for such a tolerance in the termination resistor (40%), it could (and it will) lead to reflections in the LVDS line that degrade the link. The question is how much it can be degraded because of this tolerance in the termination. From the datasheet it should be possible to receive data over 800Mbps, but maybe this is only possible when the termination is precise enough (external).

Has anybody succeeded to receive such rates using the internal termination?

Cheers

[IDeyn]

Hi Spieler!

First of all, why did you choose 580 Mbps?

As about internal termination, I suppose that it is unlikely that issue comes from internal termination because of relatively slow speeds on each individual LVDS pair.

Also did you try to choose slower speeds? Do you use dev. board or your own PCB?

Best regards,

Ivan

[Spieler]

Hi Ivan,

Thanks for answering!

Sorry, I made a mistake. It is 560MHz, the output bitrate of a 14-bit ADC channel sampling at 40MHz. We developed our own PCB and put a lot of effort in matching the lengths of the different LVDS lines.

And yes, with lower bitrates (280Mhz, 448MHz) we were able to receive the bitstream without problems

Cheers and thanks for your help

[IDeyn]

Hi Spieler.

There are lots of possible reasons for mistake.

First of all ideally you need to find out if there are PCB bugs and also you should check I/O assignment analysis for warnings.

Also SSN should be taken into account. If you will type actual toggle rate for your I/O pins you will receive more actual analysis results

from I/O assignment analysis.

Also of course I recommend to verify your timing constraints.

Then, maybe on one or several pairs you have some timing shift, ideally you need to look using oscilloscope if all edges from your LVDS lines are aligned, but you can also try to find out that using signal tap. After that you can change individual I/O delays to correct timing.

Best regards,

Ivan

[Spieler]

Hello Ivan

From the tool we did not get any warning regarding I/O assignments or anything. Plus, we are using a dedicated bank for all the LVDS signals and only LVDS signals, there is no single-ended signal in that bank. Using Quartus Prime v16.1 we did not get any message regarding possible crosstalk or SSN effects.

Thank you so much for all the advices. For the skew between the different LVDS pairs we took into consideration a couple of rules to design the trace length. Basically, the maximum skew is below 50ps with a maximum mismatch of 30ps between the positive and negative lines. These two references we took them from [1]

I do not find it so straightforward to check if the edges of all the LVDS signals are aligned, first because we do not have a couple of differential active probes to measure with the oscilloscope, and with Signaltap we should sample at a frequency at least equal than those 560MHz. Do you have an idea of how could we check this?

By changing the individual I/O delays, do you mean to change them using the IOBUF configurable input delay?

Best regards,

Carlos

[1] - JOHNSON, Howard; GRAHAM, Martin. High-speed signal propagation: advanced black magic. 2003

[IDeyn]

Hello Carlos.

As about your last question -

"By changing the individual I/O delays, do you mean to change them using the IOBUF configurable input delay?"

Well, yes, from the assignment editor you can manually set different I/O delay, and even you can dynamically adjust delays in modern devices.

Also from ECO mode, you could adjust I/O delays after compilation, which is very useful if your compile time is significant.

As about the measurement of LVDS signals - in case you haven't an option of measurement using oscilloscope you can try to use the internal SignalTap logic analyzer. The idea is somewhat like that (I will try to explain but not sure it will be clear) - you create a signal tap system together with In system source and probes or System Console or other for controlling the I/O delays dynamically. After that, you need to start acquisition of your signal (of course for ADC for example it's known test pattern), and what you need is to find iteration where your data is closer to be 50% correct to 50% incorrect. That will be a position where you are in the metastable state, you need to iteratively move from that point to receive your data more and more correctly. So because you know the amounts of delay step and know the most close to metastable position of your data, you can estimate edges of your LVDS signals.

Hope that helps.

Best regards,

Ivan