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: 
Visitor staslapanja
Visitor
322 Views
Registered: ‎10-03-2018

Constraining LVDS inverted clock

Jump to solution

Hi,

In our project we are using a LVDS clock source to capture data from an ADC device (DDR). The clocking is done in this way:

INPUT (P,N) -> MMCM -> BUFG and BUGCE_DIV (in parallel) -> capture logic (IDELAY and ISERDES3)

However on our board the P and N LVDS pins were swapped effectively inverting the clock. To counter this a 180 degree phase shift was added to the MMCM output clock.

My question is how should a LVDS clock that has switched PN pins be constrained for our scenario. Should the clock be defined like this:

create_clock -period 2.000 -name clock -waveform {1.0 2.0} [get_ports clock_pad_p_i]

Are there any other changes to the constraints that need to be taken into account?

 

Thank you.

0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
285 Views
Registered: ‎01-23-2009

Re: Constraining LVDS inverted clock

Jump to solution

My guess is that the question/problem is more complex then this.

Yes, the command given by @evant_nq describes a clock that has a falling edge at time 0 and a rising edge at time 1, however, that, on its own, does not describe the edge relationship you want.

For example, if you use

set_input_delay -clock clock 0.5 [get_ports data_pad]

this will still define a 0.5ns delay with respect to the rising edge of the clock, regardless of whether the rising edge is defined to be at 0ns or at 1ns.

If you really want to describe the data transitioning with respect to the falling clock then you need to use the -clock_fall option

set_input_delay -clock clock 0.5 [get_ports data_pad] -clock_fall

this is really what tells the tool that the input changes relative to the falling edge of the clock (not the rising edge).

And given that this is the case, there is no real advantage to defining the clock with the -edges {1 2} rather than the default (which is {0 1}) - the -clock_fall is what does what you need it to do...

If you really want to do it with clocks, then you will need two clocks - a real one and a virtual one

create_clock -period 2.000 -name clock        -waveform {1.0 2.0} [get_ports clock_pad_p_i]
create_clock -period 2.000 -name virt_clock -waveform {0.0 1.0}

set_input_delay -clock virt_clock 0.5 [get_ports data_pad]

Now your data is defined to change on the rising edge of virt_clock (with rising edges at 0 and 2), but the FPGA is getting a clock that is 180 degrees out of phase. In Vivado all clocks are related by default so the tool understands that these two clocks are related and are 180 degrees apart.

Avrum

3 Replies
Explorer
Explorer
291 Views
Registered: ‎07-18-2018

Re: Constraining LVDS inverted clock

Jump to solution

Hi staslapanja,

 

  I think the create_clock:

create_clock -period 2.000 -name clock -waveform {1.0 2.0} [get_ports clock_pad_p_i]

Should give you the expected shift. The best way to confirm this is to run timing with the constraint, and then do a report timing on the input paths.

The clock should start with a 180 degree shift compare to the data (You can do the normal waveform of 0 1 to confirm)

Which means the tools will be trying to cacualting timing of the data assuming the rising edge is 180 out of phase

0 Kudos
Historian
Historian
286 Views
Registered: ‎01-23-2009

Re: Constraining LVDS inverted clock

Jump to solution

My guess is that the question/problem is more complex then this.

Yes, the command given by @evant_nq describes a clock that has a falling edge at time 0 and a rising edge at time 1, however, that, on its own, does not describe the edge relationship you want.

For example, if you use

set_input_delay -clock clock 0.5 [get_ports data_pad]

this will still define a 0.5ns delay with respect to the rising edge of the clock, regardless of whether the rising edge is defined to be at 0ns or at 1ns.

If you really want to describe the data transitioning with respect to the falling clock then you need to use the -clock_fall option

set_input_delay -clock clock 0.5 [get_ports data_pad] -clock_fall

this is really what tells the tool that the input changes relative to the falling edge of the clock (not the rising edge).

And given that this is the case, there is no real advantage to defining the clock with the -edges {1 2} rather than the default (which is {0 1}) - the -clock_fall is what does what you need it to do...

If you really want to do it with clocks, then you will need two clocks - a real one and a virtual one

create_clock -period 2.000 -name clock        -waveform {1.0 2.0} [get_ports clock_pad_p_i]
create_clock -period 2.000 -name virt_clock -waveform {0.0 1.0}

set_input_delay -clock virt_clock 0.5 [get_ports data_pad]

Now your data is defined to change on the rising edge of virt_clock (with rising edges at 0 and 2), but the FPGA is getting a clock that is 180 degrees out of phase. In Vivado all clocks are related by default so the tool understands that these two clocks are related and are 180 degrees apart.

Avrum

Visitor staslapanja
Visitor
252 Views
Registered: ‎10-03-2018

Re: Constraining LVDS inverted clock

Jump to solution

Thank you both for your replays, especially yours avrumw.

0 Kudos