Forums

PRBS in LT Spice

Started by John Larkin October 13, 2012
We are considering sending data over CAT6 twisted-pairs, from one FPGA
to another at some 10s of meters distance. It might be prudent to
transformer-couple the data, to avoid ground-loop common-mode hazards,
and the obvious choice would be to use RJ45 connectors with built-in
Ethernet magnetics. These seem to have inductance in the 400 uH range,
which gives a low-end frequency response in the 40 KHz sort of range.
The data would have to be DC-balanced, and we'd have to use NRZI
coding, bit filling, whatever to avoid long runs of 1s or 0s from
adding any low-frequency components. We have 80 or so streams arriving
at the main FPGA from the field, so we may not have enough FPGA
resources to do full 8b10b or some such encoding; we may have to
invent something dumber. Our bit rates will be in the 25-125 mbps sort
of range.

Anyhow, I started playing with pushing uncoded pseudo-random data
through the magnetics. I used the standard LT Spice "digital" parts
and found that they would NOT make a working shift register. I had to
edit all the flops to add the "TD=1n" Spice directive to give them
some prop delay.

The RC lowpass filter below gives a quick visual indication of the
sequence periodicity. The sequence taps are from AoE page 657.


Version 4
SHEET 1 3280 884
WIRE 96 -320 48 -320
WIRE 160 -320 96 -320
WIRE 160 -272 -592 -272
WIRE 720 -272 336 -272
WIRE 720 -32 720 -272
WIRE 720 -32 624 -32
WIRE 560 -16 -496 -16
WIRE 1616 -16 624 -16
WIRE 1712 -16 1616 -16
WIRE 1856 -16 1712 -16
WIRE 2064 -16 1936 -16
WIRE 2128 -16 2064 -16
WIRE 2176 -16 2128 -16
WIRE 1392 0 624 0
WIRE 2064 64 2064 -16
WIRE 2064 208 2064 128
WIRE -496 352 -496 -16
WIRE -432 352 -496 352
WIRE -96 352 -272 352
WIRE 208 352 64 352
WIRE 512 352 368 352
WIRE 832 352 672 352
WIRE 1152 352 992 352
WIRE 1392 352 1392 0
WIRE 1392 352 1312 352
WIRE 1472 352 1392 352
WIRE 1712 352 1712 -16
WIRE 1712 352 1632 352
WIRE 1824 352 1712 352
WIRE 2064 352 1904 352
WIRE 2352 352 2176 352
WIRE 2416 352 2352 352
WIRE 2464 352 2416 352
WIRE 2352 368 2352 352
WIRE -432 400 -496 400
WIRE -96 400 -176 400
WIRE 208 400 144 400
WIRE 512 400 448 400
WIRE 832 400 768 400
WIRE 848 400 832 400
WIRE 1152 400 1088 400
WIRE 1472 400 1392 400
WIRE 1792 400 1648 400
WIRE 1792 432 1792 400
WIRE 2064 432 1792 432
WIRE 2272 432 2176 432
WIRE -768 448 -800 448
WIRE -736 448 -768 448
WIRE -800 480 -800 448
WIRE 2272 480 2272 432
WIRE 2352 480 2352 448
WIRE 2352 480 2272 480
WIRE 2272 496 2272 480
WIRE -592 560 -592 -272
WIRE -496 560 -496 400
WIRE -496 560 -592 560
WIRE -800 592 -800 560
WIRE -688 720 -816 720
WIRE -496 720 -496 560
WIRE -496 720 -624 720
WIRE -320 720 -496 720
WIRE -176 720 -176 400
WIRE -176 720 -320 720
WIRE 144 720 144 400
WIRE 144 720 -176 720
WIRE 448 720 448 400
WIRE 448 720 144 720
WIRE 768 720 768 400
WIRE 768 720 448 720
WIRE 1088 720 1088 400
WIRE 1088 720 768 720
WIRE 1392 720 1392 400
WIRE 1392 720 1088 720
WIRE -816 752 -816 720
WIRE -816 864 -816 832
FLAG -816 864 0
FLAG -800 592 0
FLAG -768 448 HI
FLAG 96 -320 HI
FLAG 2064 208 0
FLAG 2272 496 0
FLAG 2128 -16 LPF
FLAG 2416 352 XFMR
FLAG 1616 -16 PRBS
FLAG -320 720 CLOCK
SYMBOL Digital\\inv -688 656 R0
SYMATTR InstName A1
SYMBOL voltage -816 736 R0
WINDOW 0 64 44 Left 2
WINDOW 3 48 86 Left 2
WINDOW 123 0 0 Left 2
WINDOW 39 0 0 Left 2
SYMATTR InstName V1
SYMATTR Value PULSE(1 0 50n 1n 1n 5n 50n 500)
SYMBOL Digital\\dflop -352 304 R0
WINDOW 0 -14 -30 Left 2
SYMATTR InstName A2
SYMATTR SpiceLine td=1n
SYMBOL Digital\\dflop -16 304 R0
WINDOW 0 -14 -30 Left 2
SYMATTR InstName A3
SYMATTR SpiceLine td=1n
SYMBOL Digital\\dflop 288 304 R0
WINDOW 0 -13 -30 Left 2
SYMATTR InstName A4
SYMATTR SpiceLine td=1n
SYMBOL voltage -800 464 R0
WINDOW 0 62 44 Left 2
WINDOW 3 70 84 Left 2
WINDOW 123 0 0 Left 2
WINDOW 39 0 0 Left 2
SYMATTR InstName V2
SYMATTR Value 1
SYMBOL Digital\\dflop 592 304 R0
WINDOW 0 -14 -29 Left 2
SYMATTR InstName A5
SYMATTR SpiceLine td=1n
SYMBOL Digital\\dflop 912 304 R0
WINDOW 0 -14 -30 Left 2
SYMATTR InstName A6
SYMATTR SpiceLine td=1n
SYMBOL Digital\\dflop 1232 304 R0
WINDOW 0 -15 -30 Left 2
SYMATTR InstName A7
SYMATTR SpiceLine td=1n
SYMBOL Digital\\dflop 1552 304 R0
WINDOW 0 -13 -29 Left 2
SYMATTR InstName A8
SYMATTR SpiceLine td=1n
SYMBOL Digital\\xor 576 -64 M0
SYMATTR InstName A9
SYMATTR SpiceLine td=1n
SYMBOL Digital\\dflop 240 -368 R0
WINDOW 0 -17 -43 Left 2
SYMATTR InstName A10
SYMATTR SpiceLine td=1n
SYMBOL res 1952 -32 R90
WINDOW 0 0 56 VBottom 2
WINDOW 3 32 56 VTop 2
SYMATTR InstName R1
SYMATTR Value 100
SYMBOL cap 2048 64 R0
WINDOW 0 64 15 Left 2
WINDOW 3 64 49 Left 2
SYMATTR InstName C1
SYMATTR Value 1n
SYMBOL ind2 2048 336 R0
WINDOW 0 2 125 Left 2
WINDOW 3 -11 161 Left 2
SYMATTR InstName L1
SYMATTR Value 400�
SYMATTR Type ind
SYMBOL res 1920 336 R90
WINDOW 0 -54 56 VBottom 2
WINDOW 3 -46 57 VTop 2
SYMATTR InstName R2
SYMATTR Value 100
SYMBOL ind2 2192 336 M0
WINDOW 0 2 125 Left 2
WINDOW 3 -13 158 Left 2
SYMATTR InstName L2
SYMATTR Value 400�
SYMATTR Type ind
SYMBOL res 2368 464 R180
WINDOW 0 -55 69 Left 2
WINDOW 3 -60 34 Left 2
SYMATTR InstName R3
SYMATTR Value 100
TEXT -816 648 Left 2 !.tran 20u uic
TEXT 2056 312 Left 2 !K1 L1 L2 1
TEXT 1064 -304 Left 3 ;PSEUDO-RANDOM SEQUENCER
TEXT 1168 -256 Left 3 ;127 BIT LENGTH
TEXT 992 -200 Left 3 ;J LARKIN   HIGHLAND TECHNOLOGY INC
TEXT 1928 560 Left 3 ;ETHERNET TRANSFORMER
TEXT 1208 -144 Left 2 ;OCT 13  2012


-- 

John Larkin                  Highland Technology Inc
www.highlandtechnology.com   jlarkin at highlandtechnology dot com   

Precision electronic instrumentation
Picosecond-resolution Digital Delay and Pulse generators
Custom timing and laser controllers
Photonics and fiberoptic TTL data links
VME  analog, thermocouple, LVDT, synchro, tachometer
Multichannel arbitrary waveform generators
John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

> >We are considering sending data over CAT6 twisted-pairs, from one FPGA >to another at some 10s of meters distance. It might be prudent to >transformer-couple the data, to avoid ground-loop common-mode hazards, >and the obvious choice would be to use RJ45 connectors with built-in >Ethernet magnetics. These seem to have inductance in the 400 uH range, >which gives a low-end frequency response in the 40 KHz sort of range. >The data would have to be DC-balanced, and we'd have to use NRZI >coding, bit filling, whatever to avoid long runs of 1s or 0s from >adding any low-frequency components. We have 80 or so streams arriving >at the main FPGA from the field, so we may not have enough FPGA >resources to do full 8b10b or some such encoding; we may have to >invent something dumber. Our bit rates will be in the 25-125 mbps sort >of range.
Whatever happened with LVDS? You can get serializers/deserializers which do all the heavy lifting. -- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------
On Sat, 13 Oct 2012 16:07:33 GMT, nico@puntnl.niks (Nico Coesel)
wrote:

>John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: > >> >>We are considering sending data over CAT6 twisted-pairs, from one FPGA >>to another at some 10s of meters distance. It might be prudent to >>transformer-couple the data, to avoid ground-loop common-mode hazards, >>and the obvious choice would be to use RJ45 connectors with built-in >>Ethernet magnetics. These seem to have inductance in the 400 uH range, >>which gives a low-end frequency response in the 40 KHz sort of range. >>The data would have to be DC-balanced, and we'd have to use NRZI >>coding, bit filling, whatever to avoid long runs of 1s or 0s from >>adding any low-frequency components. We have 80 or so streams arriving >>at the main FPGA from the field, so we may not have enough FPGA >>resources to do full 8b10b or some such encoding; we may have to >>invent something dumber. Our bit rates will be in the 25-125 mbps sort >>of range. > >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. -- John Larkin Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom timing and laser controllers Photonics and fiberoptic TTL data links VME analog, thermocouple, LVDT, synchro, tachometer Multichannel arbitrary waveform generators
On 13 Okt., 18:23, John Larkin
<jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
> On Sat, 13 Oct 2012 16:07:33 GMT, n...@puntnl.niks (Nico Coesel) > wrote: > > > > > > > > > > >John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > > >>We are considering sending data over CAT6 twisted-pairs, from one FPGA > >>to another at some 10s of meters distance. It might be prudent to > >>transformer-couple the data, to avoid ground-loop common-mode hazards, > >>and the obvious choice would be to use RJ45 connectors with built-in > >>Ethernet magnetics. These seem to have inductance in the 400 uH range, > >>which gives a low-end frequency response in the 40 KHz sort of range. > >>The data would have to be DC-balanced, and we'd have to use NRZI > >>coding, bit filling, whatever to avoid long runs of 1s or 0s from > >>adding any low-frequency components. We have 80 or so streams arriving > >>at the main FPGA from the field, so we may not have enough FPGA > >>resources to do full 8b10b or some such encoding; we may have to > >>invent something dumber. Our bit rates will be in the 25-125 mbps sort > >>of range. > > >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 http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/253018c6cdb114f5662a2d7ba8ed748c6e68e3a7/show/usrp2/fpga/opencores/8b10b 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
On 2012-10-13, John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:
> > We are considering sending data over CAT6 twisted-pairs, from one FPGA > to another at some 10s of meters distance. It might be prudent to > transformer-couple the data, to avoid ground-loop common-mode hazards, > and the obvious choice would be to use RJ45 connectors with built-in > Ethernet magnetics. These seem to have inductance in the 400 uH range, > which gives a low-end frequency response in the 40 KHz sort of range. > The data would have to be DC-balanced, and we'd have to use NRZI > coding, bit filling, whatever to avoid long runs of 1s or 0s from > adding any low-frequency components. We have 80 or so streams arriving > at the main FPGA from the field, so we may not have enough FPGA > resources to do full 8b10b or some such encoding; we may have to > invent something dumber. Our bit rates will be in the 25-125 mbps sort > of range.
Millibits per second? Just use OOK of some convenient frequency. Ethernet magnetics need to work down to 10Mbps (for 10-Base-T which is manchester coding at 10 Mbaud) any performance below 10Mhz is not by design. Megabits per second would harder. AIUI GBE sends several multilevel streams at 125 Bauds.
> Anyhow, I started playing with pushing uncoded pseudo-random data > through the magnetics. I used the standard LT Spice "digital" parts > and found that they would NOT make a working shift register. I had to > edit all the flops to add the "TD=1n" Spice directive to give them > some prop delay.
I had no problem making a johnson counter earlier. -- &#9858;&#9859; 100% natural --- news://freenews.netfront.net/ - complaints: news@netfront.net ---
On Sat, 13 Oct 2012 13:13:34 -0700 (PDT), "langwadt@fonz.dk"
<langwadt@fonz.dk> wrote:

>On 13 Okt., 18:23, John Larkin ><jjlar...@highNOTlandTHIStechnologyPART.com> wrote: >> On Sat, 13 Oct 2012 16:07:33 GMT, n...@puntnl.niks (Nico Coesel) >> wrote: >> >> >> >> >> >> >> >> >> >> >John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: >> >> >>We are considering sending data over CAT6 twisted-pairs, from one FPGA >> >>to another at some 10s of meters distance. It might be prudent to >> >>transformer-couple the data, to avoid ground-loop common-mode hazards, >> >>and the obvious choice would be to use RJ45 connectors with built-in >> >>Ethernet magnetics. These seem to have inductance in the 400 uH range, >> >>which gives a low-end frequency response in the 40 KHz sort of range. >> >>The data would have to be DC-balanced, and we'd have to use NRZI >> >>coding, bit filling, whatever to avoid long runs of 1s or 0s from >> >>adding any low-frequency components. We have 80 or so streams arriving >> >>at the main FPGA from the field, so we may not have enough FPGA >> >>resources to do full 8b10b or some such encoding; we may have to >> >>invent something dumber. Our bit rates will be in the 25-125 mbps sort >> >>of range. >> >> >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 >http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/253018c6cdb114f5662a2d7ba8ed748c6e68e3a7/show/usrp2/fpga/opencores/8b10b > >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. -- John Larkin Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom timing and laser controllers Photonics and fiberoptic TTL data links VME analog, thermocouple, LVDT, synchro, tachometer Multichannel arbitrary waveform generators
On 13 Okt., 23:12, John Larkin
<jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
> On Sat, 13 Oct 2012 13:13:34 -0700 (PDT), "langw...@fonz.dk" > > > > > > > > > > <langw...@fonz.dk> wrote: > >On 13 Okt., 18:23, John Larkin > ><jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > >> On Sat, 13 Oct 2012 16:07:33 GMT, n...@puntnl.niks (Nico Coesel) > >> wrote: > > >> >John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: > > >> >>We are considering sending data over CAT6 twisted-pairs, from one FPGA > >> >>to another at some 10s of meters distance. It might be prudent to > >> >>transformer-couple the data, to avoid ground-loop common-mode hazards, > >> >>and the obvious choice would be to use RJ45 connectors with built-in > >> >>Ethernet magnetics. These seem to have inductance in the 400 uH range, > >> >>which gives a low-end frequency response in the 40 KHz sort of range. > >> >>The data would have to be DC-balanced, and we'd have to use NRZI > >> >>coding, bit filling, whatever to avoid long runs of 1s or 0s from > >> >>adding any low-frequency components. We have 80 or so streams arriving > >> >>at the main FPGA from the field, so we may not have enough FPGA > >> >>resources to do full 8b10b or some such encoding; we may have to > >> >>invent something dumber. Our bit rates will be in the 25-125 mbps sort > >> >>of range. > > >> >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 > >http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/25... > > >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.
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 4x sampling using the deserializer that is in every iob (8x for differential input)
> > 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. >
if you have a board with an FPGA on it is a 2minute job -Lasse
On Sat, 13 Oct 2012 14:33:06 -0700 (PDT), "langwadt@fonz.dk"
<langwadt@fonz.dk> wrote:

>On 13 Okt., 23:12, John Larkin ><jjlar...@highNOTlandTHIStechnologyPART.com> wrote: >> On Sat, 13 Oct 2012 13:13:34 -0700 (PDT), "langw...@fonz.dk" >> >> >> >> >> >> >> >> >> >> <langw...@fonz.dk> wrote: >> >On 13 Okt., 18:23, John Larkin >> ><jjlar...@highNOTlandTHIStechnologyPART.com> wrote: >> >> On Sat, 13 Oct 2012 16:07:33 GMT, n...@puntnl.niks (Nico Coesel) >> >> wrote: >> >> >> >John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote: >> >> >> >>We are considering sending data over CAT6 twisted-pairs, from one FPGA >> >> >>to another at some 10s of meters distance. It might be prudent to >> >> >>transformer-couple the data, to avoid ground-loop common-mode hazards, >> >> >>and the obvious choice would be to use RJ45 connectors with built-in >> >> >>Ethernet magnetics. These seem to have inductance in the 400 uH range, >> >> >>which gives a low-end frequency response in the 40 KHz sort of range. >> >> >>The data would have to be DC-balanced, and we'd have to use NRZI >> >> >>coding, bit filling, whatever to avoid long runs of 1s or 0s from >> >> >>adding any low-frequency components. We have 80 or so streams arriving >> >> >>at the main FPGA from the field, so we may not have enough FPGA >> >> >>resources to do full 8b10b or some such encoding; we may have to >> >> >>invent something dumber. Our bit rates will be in the 25-125 mbps sort >> >> >>of range. >> >> >> >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 >> >http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/25... >> >> >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. > >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 >4x sampling using the deserializer that is in every iob (8x for >differential input) > >> >> 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. >> > >if you have a board with an FPGA on it is a 2minute job > >-Lasse
The SRS 3 GHz clock box is really nice. It has stunningly low jitter and milliHz setability, something no regular DDS can do. The user interface is classic annoying SRS, or maybe a little worse. -- John Larkin Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom timing and laser controllers Photonics and fiberoptic TTL data links VME analog, thermocouple, LVDT, synchro, tachometer Multichannel arbitrary waveform generators
John Larkin wrote:
> We are considering sending data over CAT6 twisted-pairs, from one FPGA > to another at some 10s of meters distance. It might be prudent to > transformer-couple the data, to avoid ground-loop common-mode hazards, > and the obvious choice would be to use RJ45 connectors with built-in > Ethernet magnetics. These seem to have inductance in the 400 uH range, > which gives a low-end frequency response in the 40 KHz sort of range. > The data would have to be DC-balanced, and we'd have to use NRZI > coding, bit filling, whatever to avoid long runs of 1s or 0s from > adding any low-frequency components. We have 80 or so streams arriving > at the main FPGA from the field, so we may not have enough FPGA > resources to do full 8b10b or some such encoding; we may have to > invent something dumber. Our bit rates will be in the 25-125 mbps sort > of range. >
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. [...] -- Regards, Joerg http://www.analogconsultants.com/
On 14 Okt., 00:25, Joerg <inva...@invalid.invalid> wrote:
> John Larkin wrote: > > We are considering sending data over CAT6 twisted-pairs, from one FPGA > > to another at some 10s of meters distance. It might be prudent to > > transformer-couple the data, to avoid ground-loop common-mode hazards, > > and the obvious choice would be to use RJ45 connectors with built-in > > Ethernet magnetics. These seem to have inductance in the 400 uH range, > > which gives a low-end frequency response in the 40 KHz sort of range. > > The data would have to be DC-balanced, and we'd have to use NRZI > > coding, bit filling, whatever to avoid long runs of 1s or 0s from > > adding any low-frequency components. We have 80 or so streams arriving > > at the main FPGA from the field, so we may not have enough FPGA > > resources to do full 8b10b or some such encoding; we may have to > > invent something dumber. Our bit rates will be in the 25-125 mbps sort > > of range. > > 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