PRBS in LT Spice

Whatever happened with LVDS? You can get serializers/deserializers which do all the heavy lifting.

We're working over long distances in what might be a nasty environment, so we want bigger electrical drive levels and more common-mode rejection than literal LVDS. We're currently using a higher-speed equivalent of RS422, with some line equalization, but the customer is paranoid about ground loops and may want to add transformers.

We have to look around to see if we can find some FPGA IP that does the DC-balanced encoding/decoding for us, so we don't have to invent it. If it wants to pretend it's LVDS, that's OK. At 80-100 serial lanes, the master FPGA doesn't have enough available pins to do 2 wires per lane, so actual LVDS won't work.

Our gut feeling is that 8b10b, with some sort of clock recovery per lane, would use too much FPGA. We don't have enough ram or PLLs to do that a hundred times.

gnuradio has an 8b10b encoder/decoder

as for clock recovery, you could do like it's done with USB sample at 4x data rate( or 2x with DDR input flop ) and a small state machine to pick the right phase

shouldn't take that many resources, what FPGA are you using?

-Lasse

It's an Altera Arria II GX65, 780 balls. One whole side is taken up doing PCI Express. If our data rate is 125 Mbps, and we did a uart-like clocked state machine to decode the bits, the clock would have to be astonomical. Maybe we can use both clock edges. So we could drop the rate (unhappy customer, but that's life) or give up one pair and ship the clock in from the transmitting boxes.

Thanks for the link. I'll have my FPGA guys look at it.

My next step will be to generate a real PRBS and run it through lengths of CAT6, through Ethernet magnetics, and see what sort of eye diagrams we can get. The SRS clock generator does 2^7-1 differential PRBS (all with ECL, the hard way), so that part's not too hard.

USB get by with 4xdatarate, with +/-2500ppm clocks and 12Mbit

using both clk edges for 125Mbit that is only 250MHz using both edges is "free" the input flipflop can do DDR

don't know much about Altera, but in something like a spartan6 you could

if you have a board with an FPGA on it is a 2minute job

-Lasse

The data stream in your sim looks like far enough from DC but I guess that isn't what will be sent in reality. Anyhow, not knowing your FPGA, can these things be wired so the inputs become a Schmitt? If not you could use Schmitt buffers/inverters up front.

Method 1: If you bias correctly in the middle on the RX side and then provide a hysteresis that is high enough to ignore noise but low enough to still work at max line loss only the logic level after power-on would be undetermined. After the first transition all logic levels become valid and should remain so as long as the whole system is powered up. You could send a dummy transition after power-up to set everything to a known state.

You might not want to directly DC-drive the transformers. They cores will eventually saturate. Not that anything goes PHUT but then your amplitudes can collapse and you could see data errors.

Method 2: If #1 is "too pedestrian" :-) ... Instead of high-low signals use a transmission gate, provided the FPGA has that. The input is a high frequency global clock. The TX gate would close for high and open for low. On the RX side this can be rectified fairly simply and then fed in. The clock for method 2 would have to be many times higher in frequency than the highest data rate.

Method 3: Same as method 2 but the clock is also transferred on another pair (one for all of them). The receiving FPGA takes that clock and uses transmission gates also as inputs. These are sampling the signals which will DC-restore everything. If all data channels are clock-related to one another the clock frequency could be the same as the highest frequency appearing on any pair.

if there's enough bandwidth to support much more that the 125Mbit datarate, you could just use manchester

-Lasse

if inventing something dumber achieves the goal of making what you need from what you have, I'll call that success

sure being able to define prob delay is good, but it is still a bit suprising that LTspice doesn't have some internal timestep delay or order of operations that would make a simple shift register work out of the box

it shows what happens to a "random" 20MHz signal through a model of an ethernet transformer that was the point I assume

-Lasse

I'd look into using Gigabit ethernet gear. Creating UDP packets in an FPGA is a piece of cake. Maybe you won't even need a master device but could get by with a PC which has several network cards and do whatever needs to be done in software.

What I found is that, if the D input of the first flop is high, then the first clock loads 1's into ALL the flops of a shift register. Somehow I didn't expect that.

Right. It was to evaluate how a baseband data pattern makes it through the magnetics. Of course, the 2^7 PRBS is a rough model of whatever data we eventually have to ship, and we'll probably need to run-limit or scramble our data somehow.

NRZI would be better, but can still be fooled by data patterns. Manchester, as suggested, solves the DC balance problem, and is easy to do clock/bit recovery on, but costs half the channel bandwidth.

Yeah. 8b10b is great, but we may have to do it as many as 112 times in one FPGA, and I don't think we have the resources. Altera has an 8b10b core, about 100 CLBs each, but the receiver just assumes that a bit clock comes in from somewhere magically.

I'm not nervous. This is what I do, and it's fun. We're poking around for the best way to ship a lot of data (from pulsed IR and EUV photodiodes) fast. It's working now, with one twisted pair for clock and two pairs for data, all DC-coupled baseband. If we go to transformer coupling next generation, it's got to be DC balanced, so it gets more interesting.

Not any more than normal. I design stuff. It usually works.

What I said. It's a test pattern generator.

If you used mid-biased Schmitt inputs, how?

Except for the very first state after power-up but that could be dumped.

The low-frequency rolloff makes the receive comparator baseline shift when it sees a long run of 1's or 0's. You can see that in my sim by lowering the clock frequency. The problem is, if I want to push the data rate as high as possible (el customer wants to ship a lot of data ASAP) the eye diagrams at the end of the cable are by definition not perfect. So the baseline shift will cause errors.

We are doing some simple cable equalization, but heroic equalization, like Gb Ethernet does, isn't practical in this system.

Hey, this same customer is now insisting on worldwide EMI compliance (for a box with 80 connectors, and roughly 140 high-speed i/o signals). I was thinking I could get one of those little USB spectrum analyzers and one of those surfboard-looking antennas. I could run the analyzer on a laptop. I'd haul the DUT, the antenna, and the laptop/SA up to Truckee and put it all down on tree stumps for open-field pre-lab testing. Whose SA did you like?

Ever used these?

If you really max out the link or the RX/TX chips then you can't do cheap NRZ, of course. But as they say, one has got to pay for what one gets. So if the customer wants to multicast lots of HDTV channels across it then it'll take some serious hardware. I found that if the transitions are fast enough the Schmitt method is ok.

If this demand is accompnaied by a commensurate check that's ok :-)

You can go to Elliott or whoever is your favorite EMC place and have it tested for 100-something countries. But that does get expensive. And keep in mind that some countries now go to 6GHz for EMC.

I was thinking I could get one of those little USB spectrum

Don't know the antenna and I am not so partial to their analyzers, I favor another kind:

I got the 4.4GHz version, the 12.4GHz version came out a month later. It has already paid for itself by avoiding a chunk of rental costs at a client, plus the hassle of packaging and shipping.

But keep in mind that those things are SDR so they can't deal with fast pulse stuff, might miss it or mis-interpret the level. There is a trick though, I unhook image-reject for a second once in a while, to see if any missed nasties pop up. So it's not quite like the old HP boxes but one can't beat the portability.

We'd like to go simple NRZ (and skip the 10/8 rate loss, and the complexity of 8b10b) but we do need to limit the run lengths somehow. My sim is a first shot at examining the effect of run length. If I had a good cable model, I could add that, and a comparator, and do eye diagrams. I'll probably just do it experimentally.

Looks good. Thanks. $919 for 4 GHz is impressive.

What do you use for antennas?

Run length should only matter if you are riding it pedal to the metal. Sometimes I model cables in LTSpice but most of the time I just measure, especially when it's a DC/DC converter and the sims (like the ones today) take almost an hour each.

I have an EMCO probe kit, this one plus their LNA in a little briefcase:

Pops lots of eyes because people think these are dowsing rods or something. Mostly clients call me after things have hit the fan and then all I need is these probes plus a before-after sanity check. For the sanity check I use locally made dipoles or brings some. The usual, cheap

A simple d-flop divide by 2 worked, q-bar back to D. But the shift register didn't. Strange.

Maybe somebody else can try this, making a shift register from the as-furnished flops in the LT Spice "digital" parts library.

A flipflop with zero prop delay, zero setup time, and zero hold time is sort of a singularity. It could be that the order in which Spice "executes" the flops can change the outcome.

I tried a string of flops, it doesn't work unless you add propagation delay looking in the help file it does say the dflop default to zero propagation delay, also says input hold time = Td

Doesn't make much sense, since technically for a shift register to work input hold time must be less that propagation delay

-Lasse