3.2 Gb/s high speed interface over 50m: copper, fiber, other ideas?

Question

I need to run a 3.2 Gb/s interface over 50m. My client is keen on Cat6e. The lower the price, the better. These are my findings so far:

I'm looking at using a Spartan 6 GTP Tranceiver with copper (Cat6/6a). I've spent most of the past few days digging through Xilinx's documentation on high speed tranceivers (mostly http://www.xilinx.com/publications/archives/books/serialio.pdf), however I'm still a bit unsure about this. The following is what I've found:

• The above document mentions that copper is OK for less than 6 Gb/s (GTP max is 3.2 Gb/s, so cool) and for distances less than 20m (I'm looking at 50m or so).
• The cat6a specifications are for 100m and 10Gb ethernet (so that's fine?)

So what I'd like to do is maybe use Xilinx 10Gb Ethernet core in the FPGA with the GTP transceiver. (This core: http://www.xilinx.com/support/documentation/ip_documentation/ten_gig_eth_mac_ds201.pdf)

That document mentions that Spartan LXT is compatible with the 10Gb ethernet MAC, however, it doesn't say anything about copper, all the examples are fiber, and I'm assuming that the 10 Gb Ethernet core has a maximum speed of 10 Gb/s, but will work with lower speeds?

ALSO:

Is is possible to use other interfaces (AURORA, XAUI) over Cat6e as long as the specs meet the Cat6e requirements, (and considering that I'm looking at a 3.2 Gb/s interface)? Or do I need to use specific connectors/cables for Aurora/XAUI? (1 channel).

ALSO #2:

How "easy" is a board design/layout for a 3.2 Gb/s tranciever? The xilinx high-speed documentation mentions that special equipment (scopes, etc) is necessary for debugging high-speed interfaces. Since the clock period is 3x bigger than 10 Gb/s, i assume that the tight timing requirements are not as stringent?

I've used Aurora and XAUI before, but always the FPGA HDL design side, never the board design, and we always used high-speed connectors. This is my first high-speed serial board design. A second opinion would be hugely appreciated!

Answer 1

The cat6a specifications are for 100m and 10Gb ethernet (so that's fine?)

I think what you're trying to say with this is that if 10G Ethernet can transmit 100 m over Cat6A cable, then it should be possible to transmit 3.2 Gb/s over 50 m with the same cable.

The difference between what it sounds like you want to do and how 10GbE does things is that the Xilinx serial IO, if I recall correctly, outputs a single 3.2 Gb/s serial data stream over a single pair of wires.

10GbE uses several tricks to get the maximum data rate through the longest copper cable.

First, they use all 4 pairs in the Cat6A cable to transmit the 10 Gb/s. That means that each pair is only transmitting 2.5 Gb/s.

Second, they use pre-emphasis encoding to maximize the usable bandwidth of the cable. Basically they enhance the high frequency portion of the transmitted signal. The transmitted signal then doesn't look like a clean data signal. But when its transmitted through the cable, the high-frequency portion is attenuated, and the received signal is closer to the ideal wave shape.

Third, they use error detecting and error correcting codes to allow error-free data transmission even when the cable degrades the signal enough to cause some errors in the raw bit stream.

Fourth, they use a 16-level pulse-amplitude modulation (PAM), instead of simple on-off coding, to send 4 bits of data for every symbol transmitted over the wire.

These last two methods are possible to improve the data rate due to the Shannon Theorem, which says that the maximum possible data transmission rate through a channel is determined both by the bandwidth of the channel and the signal-to-noise ratio in the channel.

I don't think any of this means that what you're proposing is utterly impossible. For example, the 2.5 Gb/s per pair data rate of 10 GbE actually becomes something like 3.125 Gb/s per pair when you include encoding overhead. But doing the PAM encoding to follow the 10GbE model is likely to require a specialized chip for both the transmitter and receiver, and some detailed design work to get it to work.

One possibility is, can you simply packetize this data up and actually send it over a 10 GbE link? That would allow you to use mostly commodity hardware to keep costs down, and also use a "proven" solution to reduce your risks. Some Xilinx FPGAs include a full Ethernet MAC that should enable this solution, but I don't know if its available at the price point you're trying to work at.

Answer 2

I think 3.2 Gbits over 50M is going to be nearly impossible over even the best single twisted pair. I think you would be better off going with coax if you can, single mode fiber even better.

Look into the broadcast video market chipsets from TI/National. They have some nice SDI cable drivers and adaptive EQ that top off near 3Gbits. They will usually go a little further. Look into renting a bit error rate tester, or BERT. You are going to need it to evaluate physical medias.

You are also going to need a fast scope and a LVDS probe if you expect to really "look" at anything. The BERT spits out a PRBS and you look at the eye diagram at your receiver.

Layout isn't really going to be that bad, but its basically RF at this point. Check out some of the eval board reference manuals, they will have nice layouts to steal. Depending on the length of your board, you are going to need some controlled impedance PCB capability, and a PCB tool that supports it and diff pair routing. Most fast boards like this need fancy materials, Gtek is a good place to start.

Its all about the "launch" you get into your cable.

If you don't care much about the wire, just use some cable drivers and the Xilinx SER/DES'es over a few pairs of some bonded pair and you should be gold. I think you will probably need to go "wider" than the standard 2 pairs on CAT6, I'm sure you can get away with 4 no problem.

Cable EQs are nice, but they are basically wideband amps with tons of gain, they tend to oscillate if you aren't careful. Premphasis is a nice way to deal with it too, just don't have any stubs on your line.

LVDS-M might also work for your app, TI and Analog make nice parts.

Check this out and its app notes: http://www.ti.com/tool/drivecable02evk

Are you forced to use twisted pair?