RE: [802.3ae] RE: [802.3ae_Serial] 802.3ae PRBSs are upside down
Tom,
BERTs tend to be one of two types: Sonet/SDH BERTs and regular bit stream
BERTs.
The SONET/SDH BERTs are programmed to receive test patterns embedded in
frames where the PRBS resets at the start of each frame. They understand
SONET/SDH framing and sychronize to the frame and it does not need to be a
RAM based pattern. The mandatory test pattern for WIS is a standardized
framed test pattern which is built into such testers.
The optional PRBS31 which was added as a result of sponsor ballot is
unframed - just a continuously running PRBS31. This pattern should be
compatible with patterns built into the regular (non-Sonet/SDH) BERTs.
Regards,
Pat
P.S. Fortunately the PRBS twins with taps farther closer to the end of the
LFSR are the ones that are consistantly used. We specify the PRBS in terms
of a circuit to make the tap locations explicit. Taps closer to the end save
a few gates for parallel generator implementations.
-----Original Message-----
From: Tom Waschura [mailto:tom_waschura@xxxxxxxxxxxxxxxxxxxxx]
Sent: Wednesday, March 06, 2002 1:56 PM
To: stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
Subject: RE: [802.3ae] RE: [802.3ae_Serial] 802.3ae PRBSs are upside
down
I could lay-in on Tim's point about what is normal--the polynomial equation
people write down to document their data pattern says nothing about an
inverter; however, that being said, it's not a practical problem for the
BERT. The point about restarting the PRBS pattern on frame boundaries IS a
big issue to the BERT. This will force you to use RAM-based patterns rather
than straight PRBS patterns.
You could; however, use the BURST-MODE feature found on many BERTS where
resynchronizations can be requested manually, externall and will complete
quickly (for PRBS patterns). If you had a pulse that designated where the
reset was going to occur, you could raise this external resynchronization
request control just before the reset and then drop it right after the
reset. Once the BERT sees it is dropped, it will resynchronize again.
Theoretically in good data, this could only take 100-200 bits or so and you
could go back to measuring bit error rates. You do; however, not include
those bits in your error rate measures. If bit errors occur during this
resynchronization time (e.g. you seed a bad value during resynchronization,
this extends the amount of time required to get into resynchronization often
in units of 128 bits or so).
This is the same application for testing BER in recirculating fiber loops
where a long fiber is loaded with PRBS data and then left to recirculate a
few times before wanting to make a BER measurement. You must wait
(blank-out) until the circulation-of-interest then, because PRBS phase has
been lost everytime it recirculates, you must synchronize quickly.
This may or may not be helpful for some people. BERTs with long user
patterns and high bit error rates are a problem. Synchronization can take
hours (literally) in the worst cases (ask the satellite communication
guys--it's enough time to get a cup of coffee). The shorter the pattern and
the better the expected BER, the quicker synchronization to user patterns
will occur.
Tom Waschura,
SyntheSys Research, Inc.
p.s. Any maximal length PRBS pattern has an evil-twin which is the
time-reversed version of the original. This pattern is easily (and, often,
accidentally) created by choosing your taps wrong in the LFSR (take a
mirrored-set of the taps). THIS, can be a real nightmare for BER testers.
Older BERTS that were used in space systems applications usually have this
capability (to synchronize to the forward or reverse, true or inverted)
version of a polynomial. This stems from the old longitudinal tape
recording systems put on satellites...during the playback to earth, they
would play in reverse to save electricity (e.g. they did not have to rewind
the tape).