RE: Interface reality check
Oops, that might have been an error on my part. Too much travel, not enough
sleep. What I was trying to get at is that it would be easier to solve the
XAUI EMI via the RS. Currently, the RS is pretty much an empty layer in
802.3. The concept I was thinking of was to use the RS to generate a
"designed" idle pattern rather than our usual data = 0x00. That would
result in the XGXS operating as a four lane 8b/10b encoder/decoder. It
would also generate an 8-bit representation of /a/, /k/ and /r/ for use by
Rick Walker's 64/66 encoder/decoder.
Just food for thought.
Cheers,
Brad
-----Original Message-----
From: Brown, Ben [BAY:NHBED:DS48]
[mailto:bebrown@xxxxxxxxxxxxxxxxxx]
Sent: Wednesday, April 05, 2000 4: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
-----------------------------------------