PRBS in LT Spice

[John Larkin]

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

[Nico Coesel]

John Larkin <jjla...@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=.)
--------------------------------------------------------------

[John Larkin]

On Sat, 13 Oct 2012 16:07:33 GMT, ni...@puntnl.niks (Nico Coesel)
wrote:

>John Larkin <jjla...@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.

[lang...@fonz.dk]

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)

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

[John Larkin]

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.

[lang...@fonz.dk]

On 13 Okt., 23:12, John Larkin
<jjlar...@highNOTlandTHIStechnologyPART.com> wrote:
> On Sat, 13 Oct 2012 13:13:34 -0700 (PDT), "langw...@fonz.dk"

> >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

[John Larkin]

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.

[Joerg]

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/

[lang...@fonz.dk]

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


-Lasse

[John Fields]

On Sat, 13 Oct 2012 08:50:12 -0700, John Larkin
<jjla...@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.
---

>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.
---

>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.

--
JF

[lang...@fonz.dk]

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

>
> >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


-Lasse

[Nico Coesel]

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

[John Larkin]

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.
Manchester, as suggested, solves the DC balance problem, and is easy
to do clock/bit recovery on, but costs half the channel bandwidth.

[John Larkin]

On Sat, 13 Oct 2012 17:41:03 -0500, John Fields
<jfi...@austininstruments.com> wrote:

>On Sat, 13 Oct 2012 08:50:12 -0700, John Larkin
><jjla...@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?

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

>
>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.

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

>---
>
>>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.
>---
>
>>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?

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

>
>Your circuit shows only a basic 7 bit PRSG with no data input port and
>no sync.

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

[Joerg]

If you used mid-biased Schmitt inputs, how?

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

> Manchester, as suggested, solves the DC balance problem, and is easy
> to do clock/bit recovery on, but costs half the channel bandwidth.
>

--

Regards, Joerg

http://www.analogconsultants.com/

[John Larkin]

On Sun, 14 Oct 2012 07:52:40 -0700, Joerg <inv...@invalid.invalid>
wrote:

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/

[Joerg]

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.

[John Larkin]

On Sun, 14 Oct 2012 13:09:06 -0700, Joerg <inv...@invalid.invalid>

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?

[Joerg]

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.

[Jasen Betts]

On 2012-10-13, John Larkin <jjla...@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: ne...@netfront.net ---

[John Larkin]

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

[lang...@fonz.dk]

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

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

-Lasse

[John Larkin]

Right!

>
>-Lasse

I guess, when people design real flipflops, they usually make sure
that a shift register will work.

[josephkk]

On Sun, 14 Oct 2012 14:22:57 -0700, John Larkin
<jjla...@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])

?-)

[Allan Herriman]

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

[John Larkin]

On Tue, 16 Oct 2012 22:29:21 -0700, josephkk

Interesting; thanks. We do need something relatively simple to map our
baseband data into something with no lf/dc components.