UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
6,655 Views
Registered: ‎11-03-2013

Rx LVDS timing

Jump to solution

Hello,

 

I'm trying to sync correctly 4 differential input LVDS data signals and a single differential clock for those 4 inputs.

The clock is about 230 MHz and according to the data sheet of the component that is connected to the FPGA, the valid sample window for the data is ~0.5ns on both sides of rising and falling ends of the clock (it's a DDR setup), i.e. :

                          _____                _____              

clock : //__|___/     |      \___|___/     |    \___| __ //

                 |            |             |            |           |

            __ |______| _____  |  _____| _____| ___

data : //__x______x______x______x_____x___ //

                 |            |             |            |           |

                 | <0.5>  |  <0.5>  |  <0.5> | <0.5> |

 

The period of the clock is ~4.3478n, thus half a period is ~2.1739. I tried using the constraints wizard to set the correct timing and IDELAYE2 to delay the data relative to the clock.

 

The timing constraints I got from the wizard are as following :

 

set_input_delay -clock [get_clocks LVDS_CLK_IN] -clock_fall -min -add_delay 0.500 [get_ports {LVDS_DATA_IN[*]}]
set_input_delay -clock [get_clocks LVDS_CLK_IN] -clock_fall -max -add_delay 1.744 [get_ports {LVDS_DATA_IN[*]}]
set_input_delay -clock [get_clocks LVDS_CLK_IN] -min -add_delay 0.500 [get_ports {LVDS_DATA_IN[*]}]
set_input_delay -clock [get_clocks LVDS_CLK_IN] -max -add_delay 1.744 [get_ports {LVDS_DATA_IN[*]}]

 

But with those constraints the timing is failing severely (the hold time), If I change the value of the IDELAY_VALUE parameter of the IDELAYE2 I'm able to shift the negative slack from hold to setup time, but I'm never able to get correct timing.

 

I'm able to get the correct timing only if I set the sample window to ~1.5ns, 0.75ns on both sides, with IDELAY_VALUE set to 14 and the following constraints :

 

set_input_delay -clock [get_clocks LVDS_CLK_IN] -clock_fall -min -add_delay 0.750 [get_ports {LVDS_DATA_IN[*]}]
set_input_delay -clock [get_clocks LVDS_CLK_IN] -clock_fall -max -add_delay 1.494 [get_ports {LVDS_DATA_IN[*]}]
set_input_delay -clock [get_clocks LVDS_CLK_IN] -min -add_delay 0.750 [get_ports {LVDS_DATA_IN[*]}]
set_input_delay -clock [get_clocks LVDS_CLK_IN] -max -add_delay 1.494 [get_ports {LVDS_DATA_IN[*]}]

 

According to the data sheet of the FPGA I'm using (Artix7, speed grade -2), the LVDS should be able to work with much higher speeds (up to 1.25G). So I'm guessing that my constraints are somehow incorrect. I'm using Vivado's selectIO IP (v 5.1) in Vivado 2015.4.

 

Does anyone know what I'm doing wrong?

Does anyone have an example for timing constraints for LVDS inputs? 

 

0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
12,648 Views
Registered: ‎01-23-2009

Re: Rx LVDS timing

Jump to solution

If I understand your timing correctly, the only thing you are doing wrong is expecting that this will work... (Sorry)

 

From your timing description, it seems that you have a data valid window that is only 1ns wide (500ps before the clock edge and 500ps after the clock edge). This is too small for static capture in an FPGA (forget an Artix-7).

 

The 1.25Gbps "rating" for LVDS is telling you that the I/O can operate at this speed, and that, under ideal conditions data can be recovered. It does not say "statically" - to get to these speeds you need to be doing some kind of dynamic calibration.

 

If you look at the datasheet (DS181 v1.20) Table 47 shows Tpscs/Tphcs, which is the "best" static capture mechanism; it needs a 1.08ns valid data window. This is before you add clock jitter and (more importantly) the IDELAY - while the taps on the IDELAY are compensated, you pay some penalty by routing the data to and from the IDELAY... So a 1ns window is just not wide enough for static capture.

 

For more information, take a look at this post which discusses clocking structures for input interfaces, and these which talk about constraining edge aligned interfaces and center aligned interfaces.

 

Avrum

3 Replies
Historian
Historian
12,649 Views
Registered: ‎01-23-2009

Re: Rx LVDS timing

Jump to solution

If I understand your timing correctly, the only thing you are doing wrong is expecting that this will work... (Sorry)

 

From your timing description, it seems that you have a data valid window that is only 1ns wide (500ps before the clock edge and 500ps after the clock edge). This is too small for static capture in an FPGA (forget an Artix-7).

 

The 1.25Gbps "rating" for LVDS is telling you that the I/O can operate at this speed, and that, under ideal conditions data can be recovered. It does not say "statically" - to get to these speeds you need to be doing some kind of dynamic calibration.

 

If you look at the datasheet (DS181 v1.20) Table 47 shows Tpscs/Tphcs, which is the "best" static capture mechanism; it needs a 1.08ns valid data window. This is before you add clock jitter and (more importantly) the IDELAY - while the taps on the IDELAY are compensated, you pay some penalty by routing the data to and from the IDELAY... So a 1ns window is just not wide enough for static capture.

 

For more information, take a look at this post which discusses clocking structures for input interfaces, and these which talk about constraining edge aligned interfaces and center aligned interfaces.

 

Avrum

Historian
Historian
6,615 Views
Registered: ‎01-23-2009

Re: Rx LVDS timing

Jump to solution

By the way (and I know it is one of the Vivado wizards that does this), remove the -add_delay from the first set of set_input_delays. The first set of min and max (be they the rising edge ones or the -clock_fall ones) should not have the -add_delay option - the second set of min and max need the -add_delay.

 

Having both with the -add_delay creates the possibility of accidentally adding even more constraints to these pins...

 

Avrum

Explorer
Explorer
6,590 Views
Registered: ‎11-03-2013

Re: Rx LVDS timing

Jump to solution
Thank you very much!
0 Kudos