Re: XGMII a/k/r
Brad,
"Booth, Bradley" wrote:
>
> Ben,
>
> Okay. :-) But this time, let's make sure Rich doesn't walk into the
> kitchen. :-)
We'll just have to watch him closer this time...
>
> The idea stemmed from Rick Walker's presentation in March where he showed
> "Building frames with XAUI(HARI) mapping." There was a lot of discussion
> about the need to use XGMII at this interface, and not XAUI. That got me
> thinking that both XAUI and XGMII, being optional, are not the PCS service
> interface. If the PCS Service Interface, which talks to the RS, were to
> have a coding that made Rick's proposal work better and made the XAUI have
> less of an EMI issue, then it might be worth tossing out for review.
So, I guess my opinion is, rather than fix the RS to make Rick
Walker's presentation work, I'd rather see the proposal get fixed
directly since it has no need to carry /a/k/r/... As for the need to
use XGMII, this was a problem with terms. We have all finally
agreed that we meant the RS/XGMII encodings vs XAUI encodings as
opposed to the actual physical interfaces themselves.
>
> I left the /k/ and /r/ in as Rick has in his proposal (except his were the
> 10-bit versions /K/ and /R/). I left /a/ in from the XAUI /A/ because I
> felt this might be useful to guarantee alignment of the XGMII lanes (like in
> XAUI). I figured that if I was going to go that far, I could put a
> pseudo-random generator in for the /k/ and /r/ to make XGXS a simpler
> design.
I made the assumption that the 8b10b coding was stripped in the
XGXS and that the 64b/66b proposal encoded 8b bytes rather than
10b code-groups. If it does not, then it requires more than just
the 3.125% additional overhead since it would be starting at 25%
overhead. Therefore, I jumped to the assumption that Rick really
meant /a/k/r/... (8b form) rather than /A/K/R/ (10b form).
The statement that the XGMII requires the /a/ code-group/character
is an interesting one. Since there is a single clock for all 32
bits, I was under the assumption that no lane alignment would be
necessary at the receive side of this interface. Is this not so?
>
> I do have another slide that is much simpler in format, but I thought I'd
> try the radical one first to gauge feedback.
I'd like to see this if you have it. I promise to react a bit
more civilized.
Ben
>
> Thanks,
> Brad
>
> -----Original Message-----
> From: Brown, Ben [BAY:NHBED:DS48]
> [mailto:bebrown@xxxxxxxxxxxxxxxxxx]
> Sent: Thursday, April 06, 2000 11:23 AM
> To: HSSG
> Subject: Re: XGMII a/k/r
>
> Brad,
>
> I think this meeting should be close to your birthday again.
> I'll treat you to an entire evening of Guiness or Scotch,
> whichever you prefer.
>
> I still don't agree with your idea and I'd like to
> understand
> more about why you think it is required. I still feel like
> it
> is a solution looking for a problem. If you could possibly
> ignore the nasty tone of my previous message, I would still
> appreciate a response.
>
> Ben
>
>
--
-----------------------------------------
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
-----------------------------------------