|
Posted by Woody Brison on June 12, 2008, 9:04 pm
If you were Registered and logged in, you could reply and use other advanced thread options
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
_______________________________________________________
|
|
Posted by Albert Manfredi on June 13, 2008, 5:10 pm
If you were Registered and logged in, you could reply and use other advanced thread options
> For 100BASE-TX, the scrambler is defined with 18 lines of Verilog
> code. =A0One could use some different circuit as long as it acts
> exactly the same as this. =A0That code I include below. =A0If 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:
>
> =A0 always @(posedge txclk)
> =A0 if (!txen)
> =A0 ds[10:0] =3D #1 11'h0; // reset key stream
> =A0 else if ( ds =3D=3D 11'h0 )
> =A0 ds[10:0] =3D #1 11'h1; // initialize key stream
> =A0 else
> =A0 ds[10:0] =3D #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). =A0When 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?
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
|
|
Posted by Woody Brison on July 1, 2008, 3:43 pm
If you were Registered and logged in, you could reply and use other advanced thread options >
> > 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?
>
> You will see 31.25 MHz as a maximum possible fundamental frequency, in
> 100BASE-TX.
> .
> 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
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
|
|
Posted by Woody Brison on July 7, 2008, 4:09 pm
If you were Registered and logged in, you could reply and use other advanced thread options >
> > For 100BASE-TX, the scrambler is defined with 18 lines of Verilog
> > code. =A0One could use some different circuit as long as it acts
> > exactly the same as this. =A0That code I include below. =A0If 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:
>
> > =A0 always @(posedge txclk)
> > =A0 if (!txen)
> > =A0 ds[10:0] =3D #1 11'h0; // reset key stream
> > =A0 else if ( ds =3D=3D 11'h0 )
> > =A0 ds[10:0] =3D #1 11'h1; // initialize key stream
> > =A0 else
> > =A0 ds[10:0] =3D #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). =A0When 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?
>
> You will see 31.25 MHz as a maximum possible fundamental frequency, in
> 100BASE-TX.
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
|
|
Posted by Rich Seifert on July 7, 2008, 4:17 pm
If you were Registered and logged in, you could reply and use other advanced thread options
[snip]
> 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?
>
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
|
| Similar Threads | Posted | | Routing problem | December 12, 2005, 3:48 pm |
| Problem with WAP and LAN connection | September 4, 2006, 7:21 am |
| Problem: UTP only works at 10 MHz | July 27, 2007, 8:02 pm |
| problem on LAN or firewall | November 22, 2007, 7:21 am |
| baffling speed problem | July 23, 2005, 2:52 am |
| Problem with Crossover Cable | August 28, 2005, 1:18 pm |
| Problem with 2 NAT boxes behind a router | February 10, 2006, 12:23 pm |
| Network configuration problem | September 7, 2007, 7:23 am |
| Help with debugging 10/100/1000Base-T PHY problem | July 31, 2008, 12:22 am |
| 3Com switches and 1000Base SX problem | July 14, 2005, 9:45 pm |
|
|
Yahoo! 
Google 
Windows Live 
del.icio.us 
digg 
Netscape 
XML site map