V5 GTP question

Test01,

Better is to use the IP already developed for this, known as "channel bonding."

Transceivers identified as being part of a group thus have all of the sequencing taken care of for you (and you do not have to figure out the best way to do it, we already did).

8B10B allows the links to pass any stream of data: without 8B10B you must have some kind of coding to prevent long strings of 0's or 1's (which leads to loss of clock).

Channel bonding is a standard feature of Xilinx MGTs (since VII Pro).

The core to support this is the Aurora protocol (any number of channels), or XAUI core (for 10Gbs Ethernet):

Austin

The target device connected to the Xilinx V5 FPGA does not support 8b/10b. There is a well defined training algorithm for bit and packet alignment. The data rate of V5 transceiver is very attractive so I am trying to see if I can use them in a source synchronous mode even if it involves using external precision delay element with 5 ps resolution at the output of each transceivers. If I do not use the FPGA transceivers then I have to use external high speed mux and demux in conjunction with the parallel FPGA I/O. This increases the board design complexity when delaing with 20 source synchronous channels running at 3.2 Gbps each.

Test01,

Sorry, I can't help you.

The choices you are making are likely to lead to a system that can not possibly work.

Controlling delays to 5ps is a recipe for disaster.

The MGTs are designed with a great deal of logic wrapped around the physical layer interface (to make life simple).

I suggest you use a separate physical layer only interface, as if you try to use the MGT in V5, you will be trying to pound a square peg into a round hole.

Austin

Thanks for your feedback. What kind of skew are you looking at between the transceivers? Is it few 100 ps or nano seconds? In our protocol there is going to be training algorithm for each bit and then there is also packet alignment algorithm. This gives an opportunity to adjust the skew externally using software programmable delay elements.

You sueessted using separate phy layer. Are you suggesting to use external high speed discrete components to achieve this? If so what high speed components you recommend? I have seen On Semi has 8:1 mux and demux that can run at this speed but I was trying to avoid that complexity of syncronizing those mux and demux and high speed clocks.

Any suggestions are welcome.

transceivers? Is it few 100 ps or nano seconds? In our protocol there is going to be training algorithm for each bit and then there is also packet alignment algorithm. This gives an opportunity to adjust the skew externally using software programmable delay elements.

high speed discrete components to achieve this? If so what high speed components you recommend? I have seen On Semi has 8:1 mux and demux that can run at this speed but I was trying to avoid that complexity of syncronizing those mux and demux and high speed clocks.

Using multiple GTP SERDES to implement a parallel source synchronous bus is not a supportable implementation and I would strongly encourage you to find an alternative approach to interfacing to your ASIC (or to redesign your ASIC to a different interface).

There are a couple of standard with multiple SERDES that have transmitter requirements of channel-to-channel skew with 1-3 UI which can be supported in the V-5 LXT devices, but the other end of the link is a SERDES that implements a CDR for locking the clock to the data inputs. Without this function in your ASIC the likely have a robust and reliable link is very very low.

Ed McGettigan

-- Xilinx Inc.

I understand that there will be skew. But the alternative solution to run source synchronous is lot more complex. The Paralllel LVDS I/Os from V5 run at maximum speed of 1 Gbps per channel. I have to run them trhough external 4:1 high speed mux (16 of these) to get 16 high speed channels each running at 3.2 Gbps each. This is possible but it is not simple task either. I understand that there will be a skew of 1 to 3 UI from channel to channel but as per my understanding this skew is fixed. Thus if there is a 5 ps resolution software programmable delay element in line with the high speed channels then the mis aligned channels can be aligned usinng the software programmable delay elements.

For example if I need 16, 3.2 Gbps data channels then I use the 17th channel as a forwarded clock running at 1.6 GHz. Again all 17 channels can go through the precise delay elements for channel alignement purpose.

On power-up the link will operate at slowest possible speed say 100 Mbps but the transceivers can keep on running at 3.2 Gbps. The FPGA fabric will pass the data

32 times in order to make it run at slower speed of 100 Mbps. In this mode 1 to 3 UI misalignment may not be a problem as it will be running at such a slow speed. When changed to higher speed (3.2 Gbps), there will be a training algorithm to align the channels using software programmable delay elements.