RE: 64/66 control code mapping
I would agree that we have to be careful in how we think of XAUI, XGMII and
64/66 encoding. In the standard, XAUI and XGMII may be optional
instantiations of service interfaces. XAUI being an instantiation of the
XGXS service interface. XGMII being an instantiation of the PCS service
interface.
As of yet, the Task Force hasn't decided what those service interfaces look
like, but I think it would be fair to assume that the PCS service interface
is a 32 bit data interface and the XGXS service interface is a 4 pair
differential interface (one direction only of course). If that is that
case, then the 64/66 proposal should be based on the 32 bit data PCS service
interface, rather than the XGXS service interface.
If the 64/66 proposal could show how it is implemented using a XGMII and a
XAUI, then I think that would help show a PCS service interface
implementation and a XGXS service interface implementation. The XGMII
implementation would be closer to being a true PCS proposal.
Thanks,
Brad
-----Original Message-----
From: Benjamin J. Brown [SMTP:bebrown@xxxxxxxxxxxxxxxxxx]
Sent: Saturday, March 11, 2000 11:19 AM
To: Rick Walker
Cc: stds-802-3-hssg-64B66B@xxxxxxxx
Subject: Re: 64/66 control code mapping
Rick,
I guess I forgot that this reflector existed.
I'm a little confused by your comments.
Rick Walker wrote:
>
> Dear Ben,
>
> > I've been looking at your 64b/66b presentation and, in
> > particular, looking at your control code mapping. The
> > 7-bit line code is specific to encodings from the 8b10b
> > XAUI interface. This is an optional interface and may
> > not exist between all MAC and PCS layers. When the XAUI
> > doesn't exist, what 7-bit line codes should be used?
>
> The same linecodes as for XAUI.
>
> A 64/66 coder running off of XGMII needs all the logic of a XAUI
encoder
> except for the 8b/10b encoders and serializers. This logic is
required to
> ensure insertion of Align characters, force SOP to be in lane 1,
etc.
The XGMII enforces that the SOP is in lane 1. XAUI relies on this
but there is no buffering within XAUI to support an XGMII that
didn't
enforce this. As for align characters, without a physical XAUI
instantiation, there is no need for alignment.
>
> > Given the protocol stack shown by Brad Booth, I would expect
that this
> > PCS layer be specified to an XGMII and not to an XAUI.
> > Implementations may choose to short- cut the conversion from
XAUI to
> > XGMII to 64b/66b but the specification should assume it
communicates
> > to the XGMII.
>
> XAUI can be thought of as an optional XGMII extender.
>
> 64/66 is probably best thought of as optional XAUI physical layer.
>
> 64/66 replaces XAUI's 4x3.125Gb/s physical layer with a single
10.3Gb/s
> serial fiber link. In the same way, WWDM or parallel fiber
solutions
> can be thought of as optional XAUI physical layers.
>
> This may not be consistent with 10GbE's rigorous taxonomy of
layers, but
> I think it is a self-consistent way to describe the situation.
>
Wow. I don't see any reason why 64/66 needs to rely on XAUI
encoding. I can understand that many implementations may
desire to have a mapping between XAUI and 64/66 but, since
XAUI is optional, why should all implementations be required
to use its encoding?
The XGMII requires 4 or 5 control words: Idle, SOP, EOP, Error
and perhaps Busy-Idle (if we choose this method of rate adaption).
The XAUI requires 8 (your list of 7 plus the align code) and a
more complex state machine (okay, just slightly more complex).
Maybe I'm splitting hairs with this one. The more I look for
problems with doing it this way, the more I find out that the
differences are slight. I guess I just seem confused by your
description of this layer as an optional XAUI physical layer.
Maybe its the use of terms. 64/66 is an encoding layer, not
a physical layer. If we choose this as the encoding layer for
the uni-phy, then it will not be optional, it will be
mandatory for all physical layers using serial LAN or WAN.
XAUI is an optional interface, not a required encoding layer.
Parallel of WDM physical layers may choose to use this same
encoding (and then it would become mandatory) but the
interface would still be optional.
I understand what you're developing but I think you need to
work on the definition and description.
Ben
--
-----------------------------------------
Benjamin Brown
Router Products Division
Nortel Networks
1 Bedford Farms,
Kilton Road
Bedford, NH 03110
603-629-3027 - Work
603-629-3070 - Fax
603-798-4115 - Home
bebrown@xxxxxxxxxxxxxxxxxx
-----------------------------------------