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

Re: XGMII a/k/r


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


> Thanks,
> Brad
>                 -----Original Message-----
>                 From:   Brown, Ben [BAY:NHBED:DS48]
> []
>                 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