100BASE-TX Scrambler Problem

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
else
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?
Wood
_______________________________________________________
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
//
// STREAM CIPHER SCRAMBLER
//
// 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
//
// KEY STREAM
//
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
else
ds[10:0] = #1 s[10:0]; // save current key stream
//
// CIPHERTEXT STREAM
//
always @(posedge txclk)
tnrzdout = #1 s[0] ^ tnrzdin; // scramble NRZ data bit
endmodule
_______________________________________________________
Reply to
Woody Brison
Loading thread data ...
You will see 31.25 MHz as a maximum possible fundamental frequency, in 100BASE-TX. =2E 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.
Bert
Reply to
Albert Manfredi
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?
Wood
Reply to
Woody Brison
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 descrambler."
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?
Wood
Reply to
Woody Brison
In article , Woody Bris[snip]
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
Reply to
Rich Seifert
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.
Wood
Reply to
Woody Brison

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.