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: 
Contributor
Contributor
5,281 Views
Registered: ‎11-09-2012

Minimum output skew of source synchronous interface for Virtex-7

Jump to solution

I am constraining the output skew of a source synchronous interface for a xc7vx485tffg1761-2 in Vivado 2016.2. The receiving device requires a clock/data skew of +/-150 ps on its input, but the best I am seemingly able to achieve out of the V7 is around +250/-350 ps according to the Vivado timing analyzer. The data is driven by OSERDESE2, and I have tried forwarding the clock through ODDR and OSERDESE2.

 

Is 250/350 ps a reasonable value for the best achievable output skew of this device, or is it likely that I am missing something? Is this due to stackup of PVT conditions?

 

Here are the constraints that I am using (the output delays fail at these values).

 

create_clock -period 5.000 -name clk_200mhz_i [get_ports clk_200mhz_i]
create_clock -period 2.500 -name clk_400mhz_i [get_ports clk_400mhz_i]
#create_generated_clock -name clk_o -source [get_pins CLK_ODDR_INST/C] -divide_by 1 [get_ports clk_o]
create_generated_clock -name clk_o -source [get_pins CLK_OSERDES_INST/CLK] -divide_by 1 [get_ports clk_o]
set_output_delay -clock [get_clocks clk_o] -min -add_delay 0.150 [get_ports data_o]
set_output_delay -clock [get_clocks clk_o] -max -add_delay 2.350 [get_ports data_o]
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Historian
Historian
9,467 Views
Registered: ‎01-23-2009

Re: Minimum output skew of source synchronous interface for Virtex-7

Jump to solution

The signs (+ve and -ve) can be confusing in these timing reports.

 

On the Destination Clock Path, it is determining the "required time". The later (larger) the required time is, the easier it is to meet timing (on a setup check, which this is), the earlier the required time is, the harder it is.

 

If you look at the "pessimism" line, it is being added to the destination clock delay, hence making the "required time" later. This makes the path easier to meet timing. The clock uncertainty and the set_output_delay are subtracted from that, these make the path harder to meet (both of which are correct). 

 

So the 221ps of pessimism is being added back into your budget - it is, in essence, making your slack 221ps larger. Furthermore, you can verify that the 221ps is correct; look at the common components on the Source Clock Path (SCP) and the Destination Clock Path (DCP)

 

                   SCP         DCP      DIFF

IBUF            0.330     0.163     0.167

net              0.217     0.187     0.030

BUFIO         0.506     0.482     0.024

net              0.140     0.120      0.020

-----------------------------------------------

total          1.193      0.952   0.241

 

So the 0.221 added back is all but 20ps of the 0.241 of pessimism (presumably some of the final net is not common between the two paths).

 

The real source of your skew is the difference in timing of the OSERDES and OBUF on the data path (0.221 + 1.371) and the OSERDES and OBUF on the clock path (0.192 + 1.143), which is 0.257ns (plus the 20ps above and the 35ps of clock uncertainty).

 

It is this that I was referring to. For the common components, the pessimism is completely removed. For the components that are not common (the OSERDES and OBUF), there is no pessimism being removed. But the issue is, is it really possible to have two side by side OSERDES+OBUFs on the same die at the same time driving the same load differ in timing by 257ps. According to the tool - yes; in the real world, probably not...

 

Avrum

Tags (1)
5 Replies
Historian
Historian
5,277 Views
Registered: ‎01-23-2009

Re: Minimum output skew of source synchronous interface for Virtex-7

Jump to solution

This is a tough question to answer...

 

If everything is coming from OSERDES directly and they are on the same clock, and they pins are all from the same bank and are very close to each other (even better if the forwarded clock is in the middle of the group of IOB that generate the forwarded data), then one would expect to get better skew than this.

 

The tools are probably somewhat pessimistic when it comes to measuring systems like this. The "on chip variation" is very bi-modal; if elements on the source and destination clock paths are the same resource, then they the "pessimism" is removed (i.e. the pessimism of going through the same BUFG). But if they are different, then they use the on chip variation difference (slow_min vs. slow_max). The ratio of slow_min to slow_max is (I believe) a constant, regardless of whether the two resources are right beside each other on the die or on opposite corners of the die. Logically, though, there will be a significant difference in this ratio in these two cases; if the two OBUFs (which are the largest source of this variation) are right beside each other, they will have virtually identical process/voltage/temperature, and hence very little on chip variation...

 

But, the tools are the only thing that you can go by, and they say "it fails"... What we can say is that what you are doing (everything coming from the OSERDES) is the best you can do (depending on what kind of clocking you are using - you might get slightly better number if you are using a BUFIO). If that isn't good enough, then nothing from the FPGA will be...

 

Avrum

Contributor
Contributor
5,208 Views
Registered: ‎11-09-2012

Re: Minimum output skew of source synchronous interface for Virtex-7

Jump to solution

Thank you @avrumw for the explanation. Yes, same clock, same bank, all OSERDES. I had tried a BUFIO (instead of a BUFG) and, interestingly, it had no appreciable effect on the timing results. I am sure that in practice the output skew will be tighter than reported, but I was hoping to be able to properly constrain the interface. This same output has worked previously on a Virtex-5 (no output constraints) with the same receiving device, so I think I'll be OK.

0 Kudos
Contributor
Contributor
5,158 Views
Registered: ‎11-09-2012

Re: Minimum output skew of source synchronous interface for Virtex-7

Jump to solution

I took another look at the timing report and see the clock pessimism of 221ps, which alone kills the output delay requirement. @avrumw, is this a proper timing analysis? It seems to me that the clock pessimism should be removed, but I do not see that it is.

 

Timing Report

0 Kudos
Highlighted
Historian
Historian
9,468 Views
Registered: ‎01-23-2009

Re: Minimum output skew of source synchronous interface for Virtex-7

Jump to solution

The signs (+ve and -ve) can be confusing in these timing reports.

 

On the Destination Clock Path, it is determining the "required time". The later (larger) the required time is, the easier it is to meet timing (on a setup check, which this is), the earlier the required time is, the harder it is.

 

If you look at the "pessimism" line, it is being added to the destination clock delay, hence making the "required time" later. This makes the path easier to meet timing. The clock uncertainty and the set_output_delay are subtracted from that, these make the path harder to meet (both of which are correct). 

 

So the 221ps of pessimism is being added back into your budget - it is, in essence, making your slack 221ps larger. Furthermore, you can verify that the 221ps is correct; look at the common components on the Source Clock Path (SCP) and the Destination Clock Path (DCP)

 

                   SCP         DCP      DIFF

IBUF            0.330     0.163     0.167

net              0.217     0.187     0.030

BUFIO         0.506     0.482     0.024

net              0.140     0.120      0.020

-----------------------------------------------

total          1.193      0.952   0.241

 

So the 0.221 added back is all but 20ps of the 0.241 of pessimism (presumably some of the final net is not common between the two paths).

 

The real source of your skew is the difference in timing of the OSERDES and OBUF on the data path (0.221 + 1.371) and the OSERDES and OBUF on the clock path (0.192 + 1.143), which is 0.257ns (plus the 20ps above and the 35ps of clock uncertainty).

 

It is this that I was referring to. For the common components, the pessimism is completely removed. For the components that are not common (the OSERDES and OBUF), there is no pessimism being removed. But the issue is, is it really possible to have two side by side OSERDES+OBUFs on the same die at the same time driving the same load differ in timing by 257ps. According to the tool - yes; in the real world, probably not...

 

Avrum

Tags (1)
Contributor
Contributor
5,147 Views
Registered: ‎11-09-2012

Re: Minimum output skew of source synchronous interface for Virtex-7

Jump to solution

Excellent explanation, @avrumw. Thank you. This now makes perfect sense to me.

0 Kudos