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
PRBS in LT Spice
Started by ●October 13, 2012
Reply by ●October 15, 20122012-10-15
Reply by ●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 ●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? �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 delayRight!> >-LasseI 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 ●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.=20At that speed try B3ZS (a derivative of alternate mark inversion [AMI]) ?-)
Reply by ●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 channelsacross>>>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 ●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
