Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: XGMII a/k/r




Ben and All:

Ben you may like to apologize for your tone to keep peace, but your statement 
is worthy discussing.

The issue of IDLE can cause EMI problem has been floating on the reflector 
for a while, yet no one can provide the test data from a certified EMI 
laboratory to prove it.  The data from any engineering laboratory is far 
deviated from the certified data due to the reflection and being not an 
actual enclosure or environment.   

Some reported 20 dB, and some reported 6 dB increment from the engineering 
laboratory without description of enclosure.   Furthermore, if the base line 
emission is 10 dBuv/m, then with the upper limit 40 dBuv/m,  even with the 
additional 6 dBuv/m or 20 dBuv/m, they are one-hundredth or one-tenth of the 
upper limit-- why it is a problem?  

It is also a valid question that why A/K/R is the cure for EMI while IDLE 
K28.5 is the cause of EMI.  The /A/K/R is also a repetitive pattern as the 
IDLE K28.5 which  is a repetitive pattern.  All repetitive patterns have the 
same characteristics of enhancing the emission of the corresponding 
frequencies; as a result, they are the candidates of causing EMI problem  --- 
Both /A/K/R and IDLE k28.5 REPETITIVE.

My latest GbE EMI test data provided by the certified EMI laboratory showed 
both data and IDLE emission level were near 10 dBuv/m which is one-thousandth 
of the agency's upper limit 40 dBuv/m -- no EMI at all. 

I agree we should keep looking for the weakness in design; however, we should 
not try to add a fix without proving a problem.  There were several examples 
in the past, we should try to avoid it. 

Even though to add /A/K/R may be trivial, we still should prove that there is 
a problem before adding a fix.

 Regards, 

Ed Chang



<< 
 Dan, Brad, All,
 
 Again, I apologize for my tone. I just read my note again and
 don't know why I even sent it.
 
 Ben
 
 "DOVE,DANIEL J (HP-Roseville,ex1)" wrote:
 > 
 > Hi Brad,
 > 
 > While I don't really sympathize with Mr. Brown's tone, I have
 > to agree that I can't understand why the a/k/r symbols are sent
 > over the XGMII.
 > 
 > It looks like a trivial effort to incorporate them into the RS,
 > but can you explain why they belong there rather than in the XGXS?
 > 
 > Thanks,
 > 
 > Dan Dove
 > ProCurve Networks Division
 > 
 > >  -----Original Message-----
 > >  From: Brown, Ben [BAY:NHBED:DS48] [mailto:bebrown@xxxxxxxxxxxxxxxxxx]
 > >  Sent: Wednesday, April 05, 2000 2:48 PM
 > >  To: HSSG
 > >  Subject: Re: Interface reality check
 > >
 > >
 > >
 > >
 > >  Brad,
 > >
 > >  So, now the XGMII has an EMI problem with IDLE? This is the first
 > >  I've heard of this. This is also the first that I've heard that
 > >  /a/k/r/ can fix such a problem. It seems purely coincidental that
 > >  the same pattern used to fix an IDLE EMI problem on XAUI just
 > >  happens to be the same pattern used to fix an IDLE EMI problem
 > >  on the XGMII. It sounds like you're trying to find a question to
 > >  an answer.
 > >
 > >  I must apologize now for the tone of this note. Perhaps this has
 > >  simply been a bad day but, for the life of me, I can't see where
 > >  this is coming from or what problem you're hoping to solve.
 > >
 > >  Ben
 > >
 > >  "Booth, Bradley" wrote:
 > >  >
 > >  > Taking Rich's slides that he sent out last Friday, I did a
 > >  couple of tweaks.
 > >  > The concept is that the /A/, /K/ and /R/ that are used for
 > >  XAUI are 10-bit
 > >  > symbols.  We can make them correspond to /a/, /k/ and /r/
 > >  which are their
 > >  > "byte equivalents."  I put that in quotes, because all
 > >  /A/s decode to a
 > >  > single /a/, all /K/s decode to a single /k/ and all /R/s
 > >  decode to a single
 > >  > /r/.  The reverse is not true; /a/ is not encoded to a
 > >  single /A/ (due to
 > >  > running disparity).  This is the same as in 802.3z.
 > >  >
 > >  > I left the /O/ in, because I think that it might add some
 > >  good features in
 > >  > the future.  But /BL/ and /RF/ got turfed.
 > >  >
 > >  > This format would work for, or could be applied to, all the current
 > >  > proposals we have on the table from SLP, SUPI, WWDM, WIS,
 > >  Serial, MAS/PAM,
 > >  > etc.  I tried to keep this at an architectural level, not
 > >  an implementation
 > >  > level.  I believe that this architecture should permit the
 > >  majority, if not
 > >  > all, of the implementations that get built.
 > >  >
 > >  > Cheers,
 > >  > Brad
 > >  >
 > >  >  <<000405_RScoding.pdf>>
 > >  >
 > >  >
 > >  -------------------------------------------------------------
 > >  -----------
 > >  >                           Name: 000405_RScoding.pdf
 > >  >    000405_RScoding.pdf    Type: Acrobat (application/pdf)
 > >  >                       Encoding: base64
 > >
 > >
 > >  --
 > >  -----------------------------------------
 > >  Benjamin Brown
 > >  Router Products Division
 > >  Nortel Networks
 > >  1 Bedford Farms,
 > >  Kilton Road
 > >  Bedford, NH 03110
 > >  603-629-3027 - Work
 > >  603-624-4382 - Fax
 > >  603-798-4115 - Home
 > >  bebrown@xxxxxxxxxxxxxxxxxx
 > >  -----------------------------------------
 > >
 
 
 -- 
 -----------------------------------------
 Benjamin Brown
 Router Products Division
 Nortel Networks
 1 Bedford Farms,
 Kilton Road
 Bedford, NH 03110
 603-629-3027 - Work
 603-624-4382 - Fax
 603-798-4115 - Home
 bebrown@xxxxxxxxxxxxxxxxxx
 -----------------------------------------
 
 
 ----------------------- Headers --------------------------------
 Return-Path: <owner-stds-802-3-hssg@xxxxxxxx>
 Received: from  rly-za02.mx.aol.com (rly-za02.mail.aol.com [172.31.36.98]) 
by air-za05.mail.aol.com (v70.20) with ESMTP; Wed, 05 Apr 2000 19:24:06 -0400
 Received: from  ruebert.ieee.org (ruebert.ieee.org [199.172.136.3]) by 
rly-za02.mx.aol.com (v71.10) with ESMTP; Wed, 05 Apr 2000 19:23:50 -0400
 Received:  by ruebert.ieee.org (8.9.3/8.9.3)   id TAA26547; Wed, 5 Apr 2000 
19:06:50 -0400 (EDT)
 Message-ID: <38EBC6C6.EFB1ACCF@xxxxxxxxxxxxxxx>
 Date: Wed, 05 Apr 2000 19:05:42 -0400
 From: "Brown, Ben [BAY:NHBED:DS48]" <bebrown@xxxxxxxxxxxxxxxxxx>
 Organization: Nortel Networks
 X-Mailer: Mozilla 4.5 [en] (Win95; I)
 X-Accept-Language: en
 MIME-Version: 1.0
 To: HSSG <stds-802-3-hssg@xxxxxxxx>
 Subject: Re: XGMII a/k/r
 References: <91A1374F62F6D21198D400A0C9F2D42804F11E69@xxxxxxxxxxxxxxxxxxx>
 Content-Type: text/plain; charset=us-ascii
 Content-Transfer-Encoding: 7bit
 Sender: owner-stds-802-3-hssg@xxxxxxxx
 Precedence: bulk
 X-Resent-To: Multiple Recipients <stds-802-3-hssg@xxxxxxxxxxxxxxxxxx>
 X-Listname: stds-802-3-hssg
 X-Info: [Un]Subscribe requests to  majordomo@xxxxxxxxxxxxxxxxxx
 X-Moderator-Address: stds-802-3-hssg-approval@xxxxxxxxxxxxxxxxxx
  >>