Reply by John Larkin October 17, 20122012-10-17
On Tue, 16 Oct 2012 22:29:21 -0700, josephkk
<joseph_barrett@sbcglobal.net> wrote:

>On Sun, 14 Oct 2012 14:22:57 -0700, John Larkin ><jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: > >> >>>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. >> >>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. > >At that speed try B3ZS (a derivative of alternate mark inversion [AMI]) > >?-)
Interesting; thanks. We do need something relatively simple to map our baseband data into something with no lf/dc components. -- 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 Allan Herriman October 17, 20122012-10-17
On Tue, 16 Oct 2012 22:29:21 -0700, josephkk wrote:

> On Sun, 14 Oct 2012 14:22:57 -0700, John Larkin > <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: > >> >>>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. >> >>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. > > At that speed try B3ZS (a derivative of alternate mark inversion [AMI]) > > ?-)
I wrote a B3ZS core sometime last century and released it on opencores.org about a decade back. http://opencores.org/project,hdbn Regards, Allan
Reply by josephkk October 17, 20122012-10-17
On Sun, 14 Oct 2012 14:22:57 -0700, John Larkin
<jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

> >>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. > >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.=20
At that speed try B3ZS (a derivative of alternate mark inversion [AMI]) ?-)
Reply by John Larkin October 15, 20122012-10-15
On Mon, 15 Oct 2012 13:19:39 -0700 (PDT), "langwadt@fonz.dk"
<langwadt@fonz.dk> wrote:

>On 15 Okt., 21:29, John Larkin <jlar...@highlandtechnology.com> wrote: >> On 13 Oct 2012 20:21:32 GMT, Jasen Betts <ja...@xnet.co.nz> wrote: >> >> >> >> >> >> >> >> >> >> >On 2012-10-13, 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. >> >> >Millibits per second? &#4294967295;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. >> >> 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
Right!
> >-Lasse
I guess, when people design real flipflops, they usually make sure that a shift register will work. -- John Larkin Highland Technology, Inc jlarkin at highlandtechnology dot com http://www.highlandtechnology.com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom laser drivers and controllers Photonics and fiberoptic TTL data links VME thermocouple, LVDT, synchro acquisition and simulation
Reply by lang...@fonz.dk October 15, 20122012-10-15
On 15 Okt., 21:29, John Larkin <jlar...@highlandtechnology.com> wrote:
> On 13 Oct 2012 20:21:32 GMT, Jasen Betts <ja...@xnet.co.nz> wrote: > > > > > > > > > > >On 2012-10-13, 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. > > >Millibits per second? =A0Just 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=3D1n" Spice directive to give them > >> some prop delay. > > >I had no problem making a johnson counter earlier. > > 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 =3D Td Doesn't make much sense, since technically for a shift register to work input hold time must be less that propagation delay -Lasse
Reply by John Larkin October 15, 20122012-10-15
On 13 Oct 2012 20:21:32 GMT, Jasen Betts <jasen@xnet.co.nz> wrote:

>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.
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. -- John Larkin Highland Technology, Inc jlarkin at highlandtechnology dot com http://www.highlandtechnology.com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom laser drivers and controllers Photonics and fiberoptic TTL data links VME thermocouple, LVDT, synchro acquisition and simulation
Reply by Joerg October 14, 20122012-10-14
John Larkin wrote:
> On Sun, 14 Oct 2012 13:09:06 -0700, Joerg <invalid@invalid.invalid> > wrote: > >> John Larkin wrote: >>> On Sun, 14 Oct 2012 07:52:40 -0700, Joerg <invalid@invalid.invalid> >>> wrote: >>> >>>> John Larkin wrote: >>>>> On Sat, 13 Oct 2012 16:06:24 -0700 (PDT), "langwadt@fonz.dk" >>>>> <langwadt@fonz.dk> wrote: >>>>> >>>>>> On 14 Okt., 00:41, John Fields <jfie...@austininstruments.com> wrote: >>>>>>> On Sat, 13 Oct 2012 08:50:12 -0700, 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. >>>>>>> --- >>>>>>> Invent something dumber? >>>>>>> >>>>>>> It sounds like you've bit off more than you can chew, the contract >>>>>>> doesn't allow you to split, and you're blaming the FPGA for your >>>>>>> nervousness. >>>>>>> --- >>>>>> if inventing something dumber achieves the goal of making what you >>>>>> need >>>>> >from what you have, I'll call that success >>>>>>>> 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. >>>>>>> --- >>>>>>> Since LTspice can't read your mind, and you want to use the behavioral >>>>>>> models, allowing you to define the prop delay is a good thing. >>>>>>> --- >>>>>> 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 >>>>> 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. >>>>> >>>>>>>> The RC lowpass filter below gives a quick visual indication of the >>>>>>>> sequence periodicity. The sequence taps are from AoE page 657. >>>>>>> --- >>>>>>> Have you finally lost your mind? >>>>>>> >>>>>>> Your circuit shows only a basic 7 bit PRSG with no data input port and >>>>>>> no sync. >>>>>>> >>>>>>> -- >>>>>> it shows what happens to a "random" 20MHz signal through a model of >>>>>> an >>>>>> ethernet transformer that was the point I assume >>>>> 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. >>>> 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. >>> >> 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. > > 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. >
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 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. > > > What do you use for antennas? >
I have an EMCO probe kit, this one plus their LNA in a little briefcase: http://www.atecorp.com/Equipment/emco/7405.asp 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 1*2" from the hardware store, wire, coax, ferrite, bulkhead BNC, some screws, staple gun (or some tape if they don't have any). Takes less than 15mins to make if they have a good saw. -- Regards, Joerg http://www.analogconsultants.com/
Reply by John Larkin October 14, 20122012-10-14
On Sun, 14 Oct 2012 13:09:06 -0700, Joerg <invalid@invalid.invalid>
wrote:

>John Larkin wrote: >> On Sun, 14 Oct 2012 07:52:40 -0700, Joerg <invalid@invalid.invalid> >> wrote: >> >>> John Larkin wrote: >>>> On Sat, 13 Oct 2012 16:06:24 -0700 (PDT), "langwadt@fonz.dk" >>>> <langwadt@fonz.dk> wrote: >>>> >>>>> On 14 Okt., 00:41, John Fields <jfie...@austininstruments.com> wrote: >>>>>> On Sat, 13 Oct 2012 08:50:12 -0700, 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. >>>>>> --- >>>>>> Invent something dumber? >>>>>> >>>>>> It sounds like you've bit off more than you can chew, the contract >>>>>> doesn't allow you to split, and you're blaming the FPGA for your >>>>>> nervousness. >>>>>> --- >>>>> if inventing something dumber achieves the goal of making what you >>>>> need >>>> >from what you have, I'll call that success >>>>>>> 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. >>>>>> --- >>>>>> Since LTspice can't read your mind, and you want to use the behavioral >>>>>> models, allowing you to define the prop delay is a good thing. >>>>>> --- >>>>> 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 >>>> 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. >>>> >>>>>>> The RC lowpass filter below gives a quick visual indication of the >>>>>>> sequence periodicity. The sequence taps are from AoE page 657. >>>>>> --- >>>>>> Have you finally lost your mind? >>>>>> >>>>>> Your circuit shows only a basic 7 bit PRSG with no data input port and >>>>>> no sync. >>>>>> >>>>>> -- >>>>> it shows what happens to a "random" 20MHz signal through a model of >>>>> an >>>>> ethernet transformer that was the point I assume >>>> 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. >>> >>> 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. >> > >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.
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.
> > >> We are doing some simple cable equalization, but heroic equalization, >> like Gb Ethernet does, isn't practical in this system. >> >> 8b10b goes to extremes to make sure there is zero DC component in the >> data, and very little low-frequency stuff. It keeps a running 1s/0s >> longterm count, and substitutes alternate 10b symbols to servo that to >> zero. >> >> >> 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). ... > > >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 >> 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? >> >> http://www.aaronia.com/products/antennas/HyperLOG-7040-LogPer-antenna/ >> > >Don't know the antenna and I am not so partial to their analyzers, I >favor another kind: > >http://signalhound.com/
Looks good. Thanks. $919 for 4 GHz is impressive.
> >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.
What do you use for antennas? -- 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 Joerg October 14, 20122012-10-14
John Larkin wrote:
> On Sun, 14 Oct 2012 07:52:40 -0700, Joerg <invalid@invalid.invalid> > wrote: > >> John Larkin wrote: >>> On Sat, 13 Oct 2012 16:06:24 -0700 (PDT), "langwadt@fonz.dk" >>> <langwadt@fonz.dk> wrote: >>> >>>> On 14 Okt., 00:41, John Fields <jfie...@austininstruments.com> wrote: >>>>> On Sat, 13 Oct 2012 08:50:12 -0700, 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. >>>>> --- >>>>> Invent something dumber? >>>>> >>>>> It sounds like you've bit off more than you can chew, the contract >>>>> doesn't allow you to split, and you're blaming the FPGA for your >>>>> nervousness. >>>>> --- >>>> if inventing something dumber achieves the goal of making what you >>>> need >>> >from what you have, I'll call that success >>>>>> 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. >>>>> --- >>>>> Since LTspice can't read your mind, and you want to use the behavioral >>>>> models, allowing you to define the prop delay is a good thing. >>>>> --- >>>> 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 >>> 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. >>> >>>>>> The RC lowpass filter below gives a quick visual indication of the >>>>>> sequence periodicity. The sequence taps are from AoE page 657. >>>>> --- >>>>> Have you finally lost your mind? >>>>> >>>>> Your circuit shows only a basic 7 bit PRSG with no data input port and >>>>> no sync. >>>>> >>>>> -- >>>> it shows what happens to a "random" 20MHz signal through a model of >>>> an >>>> ethernet transformer that was the point I assume >>> 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. >> >> 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. >
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.
> We are doing some simple cable equalization, but heroic equalization, > like Gb Ethernet does, isn't practical in this system. > > 8b10b goes to extremes to make sure there is zero DC component in the > data, and very little low-frequency stuff. It keeps a running 1s/0s > longterm count, and substitutes alternate 10b symbols to servo that to > zero. > > > 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). ...
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
> 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? > > http://www.aaronia.com/products/antennas/HyperLOG-7040-LogPer-antenna/ >
Don't know the antenna and I am not so partial to their analyzers, I favor another kind: http://signalhound.com/ 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. -- Regards, Joerg http://www.analogconsultants.com/
Reply by John Larkin October 14, 20122012-10-14
On Sun, 14 Oct 2012 07:52:40 -0700, Joerg <invalid@invalid.invalid>
wrote:

>John Larkin wrote: >> On Sat, 13 Oct 2012 16:06:24 -0700 (PDT), "langwadt@fonz.dk" >> <langwadt@fonz.dk> wrote: >> >>> On 14 Okt., 00:41, John Fields <jfie...@austininstruments.com> wrote: >>>> On Sat, 13 Oct 2012 08:50:12 -0700, 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. >>>> --- >>>> Invent something dumber? >>>> >>>> It sounds like you've bit off more than you can chew, the contract >>>> doesn't allow you to split, and you're blaming the FPGA for your >>>> nervousness. >>>> --- >>> if inventing something dumber achieves the goal of making what you >>> need >>>from what you have, I'll call that success >>>>> 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. >>>> --- >>>> Since LTspice can't read your mind, and you want to use the behavioral >>>> models, allowing you to define the prop delay is a good thing. >>>> --- >>> 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 >> >> 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. >> >>>>> The RC lowpass filter below gives a quick visual indication of the >>>>> sequence periodicity. The sequence taps are from AoE page 657. >>>> --- >>>> Have you finally lost your mind? >>>> >>>> Your circuit shows only a basic 7 bit PRSG with no data input port and >>>> no sync. >>>> >>>> -- >>> it shows what happens to a "random" 20MHz signal through a model of >>> an >>> ethernet transformer that was the point I assume >> >> 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. > > >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. 8b10b goes to extremes to make sure there is zero DC component in the data, and very little low-frequency stuff. It keeps a running 1s/0s longterm count, and substitutes alternate 10b symbols to servo that to zero. 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? http://www.aaronia.com/products/antennas/HyperLOG-7040-LogPer-antenna/ -- 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