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
>>