100BASE-TX Scrambler Problem

Have a question or want to start a discussion? Post it! No Registration Necessary.  Now with pictures!

Threaded View

For 100BASE-TX, the scrambler is defined with 18 lines of Verilog
code.  One could use some different circuit as long as it acts
exactly the same as this.  That code I include below.  If you will
refer to the part about 2/3 down in that defines the operation of
the flipflops in the LFSR... oh, WTH let's quote it right here:

  always @(posedge txclk)
  if (!txen)
  ds[10:0] = #1 11'h0; // reset key stream
  else if ( ds == 11'h0 )
  ds[10:0] = #1 11'h1; // initialize key stream
  ds[10:0] = #1 s[10:0]; // save current key stream

You will notice that when TXEN is deasserted, ie. between frames,
the LFSR is forced to all zeros (11 bits of value 0 expressed in
hex notation).  When TXEN is reasserted, ie. a new frame starts,
the LFSR will be forced to state 00000000001 by that all zeros
detector on the line beginning "else if". After that it will step
thru all of its 2047 normal states in sequence, repeating ad
infinitum - until the end of frame when it will be forced to all
zeros again by TXEN going away.

This means that between frames, the scrambler outputs a stream of
all zeros. That means that the IDLE states issued by the 4b5b
encoder between frames will go out on the twisted pair. That means
that the cable will broadcast on a sharp tight 31.25 MHz, which
means that the FCC will be all upset. But this thing was designed
not to do that.

Where's the detail I'm missing here? How can this scrambler issue
anything but all zeros between frames?



Verilog code

IEEE 802.3 Clause 25 refers us to ANSI X3.263-1995. The ANSI
standard was simply annexed to serve as Clause 25, with a very
few adaptations in terminology.  The ANSI standard gives us this
Verilog code in Annex G:

G.2 Stream Cipher Scrambler Example
// for bit serial data path with parallel key stream load
// txclk: transmit bit clock
// txen: transmit enable (disables scrambler)
// tnrzdin: unscrambled input NRZ data stream (plaintext)
// tnrzdout:scrambled output NRZ data stream (ciphertext)
module scrambler (txclk, txen, tnrzdin, tnrzdout);
input txclk, txen, tnrzdin;
output tnrzdout;
wire [11:0]s; // descrambler key stream
reg [10:0]ds; // key stream register
reg tnrzdout; // ciphertext output bit
assign s[11:1] = ds[10:0]; // shift previous bits
assign s[0] = s[11] ^ s[9]; // generate newest bit
always @(posedge txclk)
if (!txen)
ds[10:0] = #1 11'h0; // reset key stream
else if ( ds == 11'h0 )
ds[10:0] = #1 11'h1; // initialize key stream
ds[10:0] = #1 s[10:0]; // save current key stream
always @(posedge txclk)
tnrzdout = #1 s[0] ^ tnrzdin; // scramble NRZ data bit

Re: 100BASE-TX Scrambler Problem
Quoted text here. Click to load it

You will see 31.25 MHz as a maximum possible fundamental frequency, in
I believe that the idle symbol in 4B5B is a string of 1s, not zeroes,
because of the NRZI encoding? But then, for Fast Ethernet, it goes
through an additional MLT-3 encoding after that.


Re: 100BASE-TX Scrambler Problem
Quoted text here. Click to load it

I'm really not understanding this.  I understand your answer
well enough, but why the elaborate descrambler?  It has a
cyphertext stream, a hypothesis stream, several pattern
detectors to look for things in the hypothesis stream, an
elaborate init scheme for the LFSR (the Key Stream), then
there's a half dozen clumps of random logic that produce
different signals, not sure what all - Locked/Unlocked,
Active/not Active, Idlestate/not, and counters, timers...
Surprise there isn't a grand ringmaster for this whole
circus.  All that's needed is to look at the cyphertext and
detect the interframe sequence of all 1's, and the point
where it turns into something else (that's the start of frame)
and where it resumes (that's the end of frame.)  I could do
that with a very small block of code, maybe ten gates and
some FFs. Why the complexity?


Re: 100BASE-TX Scrambler Problem
Quoted text here. Click to load it

Some reading on this newsgroup (comp.dcom.lans.ethernet)
pulls up some statements from Rich Seifert that shed some
light on this question, or maybe an ominous shadow...

  Continuous signal on LX links ?, Feb 11 2002:
  "In 100BASE-X, the IDLE pattern ("11111") is a 5B code
  that is generated continuously by the PHY between frames
  (i.e., between the End-of-Stream Delimiter of one frame
  and the Start-of-Stream Delimiter of the next). ... In
  twisted pair, the IDLE code is scrambled by the polynomial
  shift register (precisely to avoid sending a continuous
  signal at a single frequency, for EMI reasons), and then
  MLT-3 line-coded for transmission on the wire. The result
  is a semi-random signal, but still decodable at the
  receiver by using the same polynomial shift register as a

  Q: 100BaseTX scrambler et al, Sep 16 2001:
  "The LFSR is "free-running", and generates a pseudo-random
  "key" that repeats every 2048 bits (2^11, from an 11-bit
  shift register). The data is added (XOR'ed) with the
  output of the LFSR key and then submitted for MLT-3
  encoding and transmission. The scrambler reduces
  interference caused by EMI by spreading the energy over a
  wider frequency range than would be present from just
  transmitting the normal data patterns."

  100BASE-T Idle Question, Jun 20 2001:
  "The scrambling prevents IDLEs (and any other repetitive
  data pattern) from concentrating all of the transmitted
  energy into a narrow frequency band, and hence violating
  EMI requirements. (Without scrambling, the MLT-3 encoded
  IDLE would appear as a continuous, 31.25 MHz continuous-
  wave signal.)"

  What's scrambling?, Oct 31 2000:
  "It is easy, without scrambling, for the signal energy to
  be highly concentrated in a single, narrow frequency
  range. The worst case is actually the "Idle" signal used
  between frames. The 5B code for "Idle" is 11111. When
  encoded using MLT-3, this would result in (effectively) a
  31.25 MHz sinusoid---all of the transmitted energy would
  be concentrated in a single frequency! Given the (poor)
  EMI-reducing characteristics of UTP cable, such a signal
  would easily exceed the radiated emissions limits imposed
  by the FCC (in the US) and similar international agencies.
  The scrambler distributes the energy so that such
  concentrations do not easily occur."

It would appear from these statements that the ANSI standard
X3.263-1995 has it wrong.  The Scramber cannot issue zeros
between frames, it must continue thru its 2047-state sequence.

How is it all these PHY designers knew to ignore that one
specific line of code in the spec?  For we put a scope on the
twisted pair coming out of the wall, and we could not find an
example of an interframe sequence of Idle codes. Whatever brand
of PHY is sending this signal, is not following the ANSI spec but
instead keeps the LFSR running between frames. As I suspect all
of them do.

Any hints, Rich?


Re: 100BASE-TX Scrambler Problem
In article


Quoted text here. Click to load it

As I am not a Verilog guru, I cannot speak to the meaning or validity of
the code cited. However, it should be clear that 100BASE-TX does a
"scramble-AFTER-encode", and that the scrambler is never turned in a
twisted-pair PHY, except perhaps for test purposes.

Of course, in a fiber medium (100BASE-FX), there is no need for the
scrambler, as there will be no EMI generated from the fiber pulses.
Perhaps the cited section of the standard and the code reflect
100BASE-FX, rather than -TX?

It is possible that there is a typo in the ANSI standard, but I doubt
that something this catastrophic would have gone unnoticed this long.

Rich Seifert              Networks and Communications Consulting
                          21885 Bear Creek Way
(408) 395-5700            Los Gatos, CA 95033
(408) 228-0803 FAX

Send replies to: usenet at richseifert dot com

Re: 100BASE-TX Scrambler Problem
Quoted text here. Click to load it

I'm going to proceed with my design, arrange the scrambler to
run all the time.  We'll be connecting this to various other
commercial PHYs and we'll see if they play together, that's
the bottom line.  I'll keep you posted from time to time.
Least I can do for the help you (all) have been.


Site Timeline