Determine latency of GTX links vs Aurora+LVDS

I have a design partitioned over 2 FPGAs. I am trying to determine the bene= fits of selecting GTX links vs. LVDS to transfer the data between FPGAs. =20 Target Device : xc6vlx550t Target Package : ff1759 Target Speed : -2=EF=BB=BF =20 Latency calculations:

  1. GTX interface: The GTX transceiver is configured at 106.25 MHz with 20 b= its input. This means the bits are transmitted at bit-rate =3D 20*106.25 MH= z =3D 2.125 Gbps. # of bits to be transferred =3D 1728 Latency of this interface =3D 1/(80% of bit-rate * (20/16)*(# of bits=EF=BB= =BF transferred/16)) =3D 1/(2.295+e11) =3D 4.35+e-12 seconds =20
  2. LVDS+Aurora: The Aurora interface is configured at 600MHz (6 Gbps) with = lane width as 2 bytes. =20 Latency of this interface =3D 1/(80% of clock rate * (# of bits=EF=BB=BF tr= ansferred/16)=EF=BB=BF) =3D 1/(5.184+e10) =3D 19.29+e-12 seconds =20 =20 Is this calculation correct? My assumption for the LVDS calculation is that= Aurora does not up-sample the clock frequency by 20 for transmitting data. =20 Thanks in advance for all the feedback.
Reply to
Vivek Menon
Loading thread data ...

bene=

b=

MH=

bits=EF=BB=

=

tr=

that=

data.

Generate both lots of IP. Write a testbench with both instantiated. Simulate.

--------------------------------------- Posted through

formatting link

Reply to
RCIngham

Vivek,

I've recently determined the latency of Aurora in my design by running simulation. It's V6, 250Mhz, 20bit, no framing. I've got 340ns. If there is a clock compensation, it periodically inserts a symbol and adds an additional clock .

Thanks, Evgeni

========================

formatting link

Reply to
OutputLogic

If it's simply 2 halves of a design with a pipe between them I would use LVDS as the pipe because it can be very predictable latency and you can build that into the combined design as simply something that looks like a normal register pipeline. As soon as you stick something in that adds channel handling messaging, or retransmission of packets, etc. maintaining that fixed latency is much more difficult.

If your board design isn't fixed you could add one or two more pairs of LVDS to allow parity, frame sync, or even clock forwarding techniques. The clock forwarding is a good technique because it is simple but also the clock delay at the second chip then tends to track the data variation with temperature, voltage, silicon batch etc.. This avoids all the complication of recovery or syncing of data and you are unlike to need any error detection as once it is setup correctly in the design/board the link probably never fail.

John Adair Enterpo> I have a design partitioned over 2 FPGAs. I am trying to determine the be=

nefits of selecting GTX links vs. LVDS to transfer the data between FPGAs.

bits input. This means the bits are transmitted at bit-rate =3D 20*106.25 = MHz =3D 2.125 Gbps.

=BB=BF transferred/16)) =3D 1/(2.295+e11) =3D 4.35+e-12 seconds

h lane width as 2 bytes.

transferred/16)=EF=BB=BF) =3D 1/(5.184+e10) =3D 19.29+e-12 seconds

at Aurora does not up-sample the clock frequency by 20 for transmitting dat= a.

Reply to
John Adair

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.