XGMII a/k/r
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
> -----------------------------------------
>