LVPECL output skew

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

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

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?

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.

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

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

Bob,

Yes.

Austin

OK, It seems that bufio skew specification of 50ps clock tree skew is not part of the equation.

10ps skew is something per load is how it works. Thus having 40 clock load on a given buiio will have 400ps skew.

This just takes care of the clock skew. But I would imagine that there will be package skew. I am assuming that 10ps skew per load does not include this.

Is that correct?

Maverick

Maverick,

Flight time or package trace, is not included.

You need that, as well.

The IBIS file has RLC values that give an estimate when they are used to create a t-line.

We also have support information for actual time per IO.

Austin

Don't use the Xilinx pseudo-differential LVPECL output drivers at 800 Mbps, use the LVDS current mode output drivers instead.

If your external device has LVPECL inputs with sufficient common mode input range, you may be able to drive it directly from the FPGA drivers.

For LVDS LVPECL interfacing notes, see:

Chapter 4 of XAPP707 discusses I/O clocking in V4, not sure if there's a V5 equivalent document yet; anyone thinking of using ChipSync at 800Mbps input rates should also have a good look at XAPP707, particularly figures 2-5, 2-7, and table 3-22

Brian

Brian,

Thanks for the tip. We can do the voltage translation using external resistors but that affects the signal integrity and attenuates the signal.

In my application, I need to interface the FPGA LVDS output to CML that is normally powered at 3.3V. The CML part of interest supports differtnial swing of

400mV to 1200mV. Thus the single ended range is 200 to 600mv and the desired common mode voltage range is vcc-100mv to vcc-300mv where vcc = 3.3V. Also the output can not exceed vcc +0.5V.

I wish that the FPGA provided the ability to vary the output common mode voltage. This can help solve the electrical issuses.

Mavrick

If you want to do LVDS -> CML, I'd look at the translators from TI/OnSemi/Micrel for that function; I think you can find some with < 100 ps part-part skew. (SN65CML100,SY58603U)

Brian