LVPECL output skew

I would like to use Virtex5 FPGA to output 16 differential channels at 800Mbps source synchronously. I am planning to use bufio to minimize the clock skew internally. Bufio has about 50ps skew on the clock input of 16 oserdes.

I would like to know roughly how much output skew will be there between the 16 channels.

Thanks.

Mavrick

Mavrick,

In general, each IO off the clock distribution is ~ 10ps.  So 16 IO's, 
160 ps.

If you route the IOs across to another Xilinx part, and 1 for 1 connect 
them to a bank in the same fashion, then the skew between IOs cancels at 
the receiving end the skew induced at the driving end.

I would draw a picture to illustrate, but I can't draw very well with 
---, ...., and ||||!

I think you get the idea.

If you route across to some other device, then you may have to take this 
skew into account, as well as the package skew, and make all lengths 
exact to compensate.

Even from X to X, you may have to take the "flight time" of the package 
into account.

Austin

Austin,

Can you please explain why the skew is multiplication of # of outputs and clock skew? This means that if I have 32 outputs then the skew from one output to the other will be 320 ps. For 64 outputs it will be 640ps. At some point this may become difficult to support by the target device.

Maverick

Mavrick,

It is called the speed of light in silicon.

The clock distribution has skew with distance.

All chips have this to some degree or another.

If a design has no skew at all, it is called a "customer ASIC" which was 
designed to be that way.

It is not required to make an interface work, so it just has to be taken 
into account.

Austin

"austin" <austin@xilinx.com> wrote in message 
news:f4a388$pba1@cnn.xilinx.com...
> Mavrick,
>
> In general, each IO off the clock distribution is ~ 10ps.  So 16 IO's, 160 
> ps.
>
> If you route the IOs across to another Xilinx part, and 1 for 1 connect 
> them to a bank in the same fashion, then the skew between IOs cancels at 
> the receiving end the skew induced at the driving end.
>
> I would draw a picture to illustrate, but I can't draw very well with ---, 
> ...., and ||||!
>
> I think you get the idea.
>
> If you route across to some other device, then you may have to take this 
> skew into account, as well as the package skew, and make all lengths exact 
> to compensate.
>
> Even from X to X, you may have to take the "flight time" of the package 
> into account.
>
> Austin

I had never thought about this, but I'll bet your internal edge times are 
starting to get close to the intra-silicon transit times. Do you (Xilinx) do 
any type of termination on the clock distribution nets? If so, it seems like 
you'd have to use end termination (as opposed to source termination). Wild 
and weird stuff!

Bob
 

Bob,

As per my understanding using the bufio the fpga internal clock tree skew is 50 ps. I am still not able to understand the 10 ps skew per fpga output pin and you multiply that by the number of outputs used. Is this 10ps skew due to mismatch in trace routing inside the fpga? If so why we need to multiiply by the number of pins used?

Mavrick

Mavrick wrote:
> Bob,
> 
> As per my understanding using the bufio the fpga internal clock tree skew is 50 ps. I am still not able to understand the 10 ps skew per fpga output pin and you multiply that by the number of outputs used. Is this 10ps skew due to mismatch in trace routing inside the fpga? If so why we need to multiiply by the number of pins used?
> 
> Mavrick

My interpretation of Austin's comment in a bad analogy:

A mail truck delivers the clock edge to each house (each oserdes) 
driving at a speed that gets 10 ps between mailboxes.  If the clock 
distribution is a single wire for those oserdes, it's like one street 
for the mailman, all happening one direction.

Mavrick wrote:
> Bob,
> 
> As per my understanding using the bufio the fpga internal clock tree skew is 50 ps. I am still not able to understand the 10 ps skew per fpga output pin and you multiply that by the number of outputs used. Is this 10ps skew due to mismatch in trace routing inside the fpga? If so why we need to multiiply by the number of pins used?

I get 1mm as around 5ps (0.67 vf), so you can get the order of the 
physical skews from that.

-jg

<Mavrick> wrote in message news:eea754b.4@webx.sUN8CHnE...
> Bob,
>
> As per my understanding using the bufio the fpga internal clock tree skew 
> is 50 ps. I am still not able to understand the 10 ps skew per fpga output 
> pin and you multiply that by the number of outputs used. Is this 10ps skew 
> due to mismatch in trace routing inside the fpga? If so why we need to 
> multiiply by the number of pins used?
>
> Mavrick

The thing that drives a global clock line is a BUFG (aka, BUFGMUX). Each 
clock line is driven from one end (as far as I know) and the IOBs tap off of 
this (long) clock line. So, as a given clock edge moves down the clock line 
it passes by the IOBs. Each IOB gets this clock edge a little later than the 
previous one, so an output generated (clocked out) by that IOB is delayed (a 
little) from the previous one. It's that simple.

Bob 

I like your analogy but we are using bufio to clock the oserdes. The Xilinx spec says that maximum skew with bufio is 50ps. Thus if I drive 40 loads with bufio clock output then the maximum skew should not exceed 50 ps.

Is that correct?

Mavrick