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
PRBS in LT Spice
Started by ●October 13, 2012
Reply by ●October 13, 20122012-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.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=.) --------------------------------------------------------------
Reply by ●October 13, 20122012-10-13
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
Reply by ●October 13, 20122012-10-13
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
Reply by ●October 13, 20122012-10-13
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. -- ⚂⚃ 100% natural --- news://freenews.netfront.net/ - complaints: news@netfront.net ---
Reply by ●October 13, 20122012-10-13
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? > >-LasseIt'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
Reply by ●October 13, 20122012-10-13
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
Reply by ●October 13, 20122012-10-13
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 > >-LasseThe 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
Reply by ●October 13, 20122012-10-13
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/
Reply by ●October 13, 20122012-10-13
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
