adaptive equalizers for LVDS data over CAT5

We're thinking about building a rackmount signal generator that has a basic internal clock, ballpark 400 MHz maybe. It will have, say, 8 channels of output, analog or digital, with all channels synchronized in time. If a customer wanted to expand to more channels, he'd buy another box, and we'd interconnect them somehow. One box would be the "master", and any number of additional boxes would be "slaves" [1]. The master would send out a 200 or 400 MHz square wave, modulated by triggers or other useful packets of data; all slaves would phaselock their clocks to the master's, and decode global triggers and such. I'm thinking distances like, say, 50 to 100 feet would be enough; if we ever had to go really far, or had a bad emi environment, we'd probably cut over to fiberoptics.

One economical way to do the interconnects would be to use LVDS signal levels and CAT5 cabling. Long runs will be trashed by cable losses (how long? gotta find out) but equalized receivers are available, and some are automatic adaptive equalizers.

I'm just starting to think about this, and will post as I learn. Anyhow, it's better than talking about climate change or how fat and stupid Americans are.

Has anybody done anything like this, sending fast clock/data like this? Do the equalizers work in real life? What about errors?

But this weekend's project is to measure the harmonic distortion of an analog output stage that can swing as much as +-10 volts behind 50 ohms, up to at least 32 MHz [2]. That's tricky. Our other project is to pick up a load of compost at the local sewage treatment plant, not as much fun.

John

[1] I understand that some organizations have stopped using "master" and "slave" out of cultural sensitivity, but I don't recall what the pc substitutes are. [2] It's interesting what rotten THD specs many modern high-end RF signal generators and arbs have. I see specs like -30 dBc all over the place. Old tube generators were a lot better. I guess that's what happens when you have one VCO or whatever and you follow it with a string of pin diode attenuators and modulators and levelers and low-headroom wideband amps.

I don't think you want the idle state to be a square wave. With a square wave you only get information about the workings of the cable at a small collection of frequencies. When you send data, many frequencies you couldn't learn about are used.

An old good RS-232 would do. Synchronize the slave clock PLLs to the time of arrival of bytes. Of course, the Ethernet can be used for that purpose also unless somebody will stuck the hub on the way.

You don't really have to transmit the high speed data unless there is a need for the fast external master trigger.

Adaptive Equalizer implies the unpredictable amount of delay.

If it would be only the Americans. How great I am and how fat, stupid and unfair is the whole rest of the world.

I know what the classic equalizer is; however I don't know much about the modern CAT5 equalizers.

How much of distortion? A spectum analyser with a notch filter on the fundamental frequency will probably do.

How to get rid of the extensive algae groth in the swimming pool? The double doze of algaecide + oxidizer didn't help.

Would it be politically correct to paint the master unit in the black and the slave unit in the white colors?

You may have to add a bandpass filter to get the clean signal out of the generator.

VLV

John,

You should look into how 10GBaseT is done. It's 10Gbps Ethernet over four pairs (2.5Gbps full duplex per pair). The 'full duplex' aspect is what really amazes me (obviously some pretty robust eq and echo cancellers).

It'll do 100 meters with CAT7 cable, but CAT5 is not officially included in the spec (iirc). In the work I did with 10GBaseT, we were able to get about

30 meters with CAT5 at

Do the equalizers acquire additional information from wider-bandwidth data patterns?

National, TI, and Maxim seem to be the main guys doing LVDS equalizers. What little I've seen so far is fairly vague as to how they do adaptive receive equalization, and whether the signal rate and data pattern influence equalizer training. We could send 8b/10b frames or something to spread things out, I suppose.

Here's one intro:

Boosting up a tiny, ugly signal like this seems scairy to me.

As I said, I've got to do more reading, then experimenting.

John

You should also look at how 10G ethernet CX4 version of XAUI is done...

...and look at what Broadcom calls their Eye Opener adaptive equalizer.

Bob

the stuff at

looks interesting, although I only do video, sort of low speed these days, any comments on gennum stuff?

Martin

I did something similar a few years ago with much slower clocks (2MHz with a frame sync encoded in it) using RS485 transceivers to synchronise E1 trunks. It worked very well except in an environment where they had electric trains passing by while pulling out of a railway station (engines at full power).

Besides, most gigabit ethernet connections are using multiple pairs and/or multi-level encoding schemes which essentially pack more bits in a clock period.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Doesn't CAT5 have intentionally different propagation delays for the pairs? Anything can be equalized, there seems to be a ton of papers on various more or less successful schemes, and you're not constrained the same way IC designers are.

How about dominant and subservient then...

I've had equalisers in the cable for 2.5Gb/s signalling and for a single pair on really nice cable we went about 50 feet before the eye closed out - that was a 8b/10b link. At 5Gb/s getting that range wasn't quite feasible though. I don't think CAT5 would have given that performance, though.

Using a line code (like 8b/10b) helps a lot because it minimises the bandwidth necessary for the equaliser (it doesn't have to work down to DC), although the equalisers I see advertised don't usually put such requirements on it. I seem to recall that the maximum run length in

8b/10b is 5, incidentally. Equaliser training is sensitive to the data pattern because of the bandwidth of the patterns; the wider the signalling bandwidth, the tougher it is for the equaliser - that seems obvious, but it's amazing how many times it seems to get forgotten ;)

The most common applications I know of for LVDS signalling are FPD-Link (video data, DVI (more video and a horrendous EMI generator) and general medium speed interconnects. I used LVDS for MPEG2 data about 10 years ago, and each link was running at about 3.3Mb/s, not fast by today's standards, but we were sending the data quite a long way and with up to

1024 links coming off the board we needed to manage crosstalk ;)

I've been using LVDS recently for fairly short run interconnects (up to

20 feet) for link rates ~700Mb/s. I use pre-emphasis on those links (some call it de-emphasis, confusingly) to get the range without a receive equaliser (because I'm sending the data to someone else's equipment and I can't do anything outside my own box).

For this app, you'd need to get a nice amplitude and phase v. frequency plot for the cable you want to use - the better mfrs have them available. That would help determine what a given eye would look like after a particular run so you could choose an appropriate equaliser.

Note that limiting the driver rise/fall times can help minimise EMI problems and ISI.

Aside: when I was working on an older piece of equipment (designed mid-70s) that was running a 90Mb/s link in free space (4.5 - 6.25GHz band) we had discrete adaptive equalisers for the IF with a dynamic range of 50dB ;)

Cheers

PeteS

They obviously must. They need to know or at least be able to guess at the amplitude and phase across the entire band that is used for signalling. Unless you do something dumb, the curves will be smooth ones but they won't be simple single pole cases.

Tape decks and hard disks have to solve parts of the same problem as running signals over long cables. The encoding methods used restrict the bandwidth of the signal to not include either low or high frequencies. You may want to look at some of the methods they use.

What sort of cabling? Your 20 feet could easily become my 50 feet at

200 MHz (ie, 400 mb/s), so just pre-emphasizing might work. I like that, because it puts more energy into the line and should have better s/n than receive equalization.

I could also maybe use some ghastly-high-power driver like an EL89, add some homebrew pre-emphasis network, and still blast 3x LVDS levels down the line! Sounds like some interesting experiments.

I'm thinking shielded Cat5e, which is plenty available in pre-made assemblies.

If you mean *other peoples* EMI problems, that's not my problem!

Good stuff: thanks.

John

We really only need one pair. We're already doing this at 32 MHz, synchronizing VME waveform generator modules within one crate, at essentially TTL levels. We send a constant 32 MHz square wave, which slaves use to phaselock their oscillators, and occasionally invert a cycle or so to convey global triggers and such. We want to extend the concept to higher speeds and longer distances, like between racks.

Sending the clock and triggers on a single pair ensures that we won't have any trigger timing (relative to clock) ambiguity. If we used another pair for triggers, then we'd have to investigate pair skew.

Anybody got guesses as to Cat5e pair skew?

Maybe we could use the other pairs for some sort of slow signalling, RS485 maybe, if we come up with a use for that.

John

If you get to the point that you need to worry about the pair-to-pair skew then you might need to do something like what XAUI does.

XAUI uses the concept of "pair bonding" where the pair-to-pair skew is relatively unimportant because each pair's data is fifo'd and then resynced. It's more complex than you probably need and you do incur some latency, but as a last resort it will work.

Bob

Whoever, why not have a slower clock to distribute and PLL it up locally ? Targetting low phase noise I guess. Nevertheless the skew stays the same. I'd counter that with a MC100EP196, a digital delay chip to stay flexible. On the other hand Onsemi has clock distribution solutions that are thought to counter clock skew.

Rene

--
Ing.Buero R.Tschaggelar - http://www.ibrtses.com
& commercial newsgroups - http://www.talkto.net

We could do that, but we still need the triggers to be unambiguous as to which 400 MHz cycle they fire on. So if we did distribute something slower, the edge rates would still need to be ballpark 1ns to make sure we don't slip a cycle. Given the parts available nowadays, it seems pretty simple to just pump 200 or 400 MHz around.

It's a more general issue of how well one can pump logic-level signals around, between racks maybe, using cheap, available parts, with one candidate being LVDS over Cat5 cables and connectors.

John

Top posting this comment: Inline responses

That was cabling specifically designed for Infiniband / PCIe and the like. Based on SpectraStrip, which is available from all the usual suspects. (If you need a contact at AMP in Pa [which is where they make their high speed cable assemblies], email me privately and I'll give you a couple of names). There is usually some 'extra' hanging around for experiments if there is a possible sale in the offing, as always.

Pre-emphasis is great for a wide range of issues (and it's not pre-emphasis in the classic sense of boosting the edge, but limiting the DC portion of the signal - the key is keeping the relative levels the same). 6dB is pretty standard and available on most line drivers for this sort of stuff. Look at the specs for the rocket IO on Xilinx parts for a typical implementation of pre-emphasis in digital parts.

Oh my! Actually, bumping to 3x levels won't necessarily help a huge amount - that's only 8dB (voltage wise) although at your speeds might get you to where you want. Interestingly, the levels I worked with at in InfiniBand (for up to 5Gb/s) were up to 1.6V drive.

Good stuff, but get the datasheet anyway so you can predict the performance :)

Actually, it's your problem - ISI is partly [mainly, imo] due to deterministic jitter which is determined primarily by the amplitude/phase v. frequency response of the cable. The EMI is caused by the same issue and it's always nice to minimise emissions, because that means more signal gets to the other end of the link.

Note that 'pure' LVDS is a current mode output (CML) so there needs to be a DC return path. On long runs, you want to AC couple for a number of reasons, so put a terminator on the link at the source and then couple to the cable through a nice cap.

Cheers

PeteS

Well, CAN has dominant and recessive modes ;)

Cheers

PeteS