Re: scramblers

[Jaime Kardontchik <kardontchik.jaime@ulinear.com>]

I do not think that there is a danger of scramblers going to the zero state. The
state of the scrambler does not depend on the input data, so once it is properly
initialized it will never go to the zero state. Scramblers are used in
100BASE-Tx and 1000BASE-T, for example. The problems with the scramblers (in
these standards) is that they generate long runs of 'ones' that give rise to
1) baseline wandering (since the transmission media uses ac coupled
transformers) and 2) receiver PLL synchronization problems when there is a long
period of missing transitions. Of these problems, only baseline wandering has
been shown to be the most difficult issue. In 10-giga only the latter problem
(receiver synchronization)  would be relevant. The advantage of the scrambler is
that it does not increase the transmission rate.

8b/10b is a very nice balanced coding with very short running disparity, and if
the overhead it introduces can be tolerated, it would be the recommended choice.

Jaime E. Kardontchik
Microlinear
San Jose, CA, 95131
email: kardontchik.jaime@ulinear.com

********************************************************************************

Ed Grivan wrote:

> Paul A. Bottorff wrote:
>
> >
> > Bill:
> >
> > I certainly agree that the PHY must provide fast failure detection (<10
> > msec). In addition, it would be nice if the PHY layer could inform the
> > transmitting end of failures.
> >
> > 10 GigE has a broad range of uses for both LAN and WAN applications. The
> > design tradeoffs for photonics in the WAN and LAN are different. In the WAN
> > a major component of cost is the optical reach. The data which I've seen
> > indicates that transmission frequency very significantly affects reach. To
> > get the lowest cost solutions 10 GigE should move away form group codes
> > systems like 8/10 into scrambler code systems. Scrambling provides an NRZ
> > efficient line encode giving 10 gigabits of data at 10 gigabaud.
>
> While scrambling is an efficient way of dealing with data, it is also
> non-deterministic in how that data is handled.  Given any scrambling
> polynomial and an uncontrolled data stream, it is always possible to
> zero out the scrambler.  Once this happens, there are NO transitions
> in the serial stream until new data containing 1's is present to
> re-seed the scrambler.
>
> The SMPTE-259 serial interface recognized this problem a long time ago
> and requires the characters in the video field to be between 004h
> and 3FBh.  Even with these limitations, they can wind up with long
> repeating patterns of 19 zero bits followed by a single 1-bit (or 19
> one bits follwed by a single 0-bit).  These signals have a very high
> DC content (making it difficult to send through an AC-coupled channel).
> An alternate pattern that they see consists of an alternating 20
> 0-bits followed by 20 1-bits (which generates a square wave).  These
> are all referred to as the SMPTE pathalogical patterns (see ANSI/SMPTE
> RP-178-1996).  They are nasty to handle, both for the interface
> circuitry AND for the PLLs.
>
> Since there is no control over the content of the data field in Ethernet
> packets, and the fact that many records are padded with trailing zeros,
> I feel that the usage of a scrambler would not be condusive to good
> engineering practices for THIS application.  As the data rate is increased,
> the time penalty and system-level impact required to recover from
> data errors becomes much more significant.  If the scrambler ever did
> zero out, the PLL would most surely drift by at least one bit.
>
> Once that happend framing must occur again to start processing data.
> But frameing is no longer simple either.  Unlile a block code (such as
> 8B/10B) where not all characters are valid and extra chracters are
> present for in-band signalling, scrambled codes use all possible
> characters.  This carries numerous implications.
>
> First, framing must be done using combinations of data characters.
> In telecom environments they identify a specific sequnce  oc data
> characters and the specific period in which they must occur.  Once these
> characters are found numerous times in that location, framing is
> declared to be achieved.  Unfortunately, nothing prevents these specific
> characters from being part of the data field, where they may also
> occur on the same bopundaries.
>
> Since Ethernet is also not based on fixed length records or records that
> are sent on a continuous basis on the same boundary, performaing framing
> with a scrambled codeing will be quite difficult.  Because it requires
> multiple recognitons of the pattern to validate the framing, it also
> takes a lot of time.  All this to handle errors that are GUARENTEED
> to happen because of the uncontroled nature of the data streem contents.
>
> This makes the handling of errors much more onerous on the system.  Its
> bad enough that the lost data may have to be resent, but the system
> level impact is much more than just the time necessary to re-transmit.
> 802.3z chose a block coded interface for mutiple reasons, including those
> listed here.  Yes there is a penalty in symbol rate to deal with this,
> but generally the 20% adder is significantly easier to handle than the
> baggage that comes with a scrambled interface.
>
> By changing to a scrambler, this also makes the optics much more difficult
> to design and more expensive to build.  Most cannot handle even a limited
> unbalance in the data stream.  They are usually AC-coupled to limit the
> noise gain in the receiver. The clock/data recovery PLLs are also more
> difficult and must be much more stable.
>
> Regards,
>
> Ed Grivna
> Cypress Semiconductor
> elg@cypress.com
>
> >
> > Paul
> >
> > Paul A. Bottorff
> > Director Switching Architecture, Bay Architecture Lab
> > Nortel Networks, Inc
> > pbottorf@nortelnetworks.com
> >