Re: XAUI and 64b/66b
Thanks Rick,
This has been very useful piece. Now the picture is much clear and symmetry
around
XAUI has been established. Now I would request that discussion on UniPHY is
limited
to XGMII, 64B/66B and beyond (towards medium) and it should not include
reference to
XAUI (and related 8B10B), other than in the context that towards MAC side
the UniPHY could talk on XAUI or XGMII (any one or both). People who want
to drive long traces before hitting PHY (or not hitting at all) can use
XAUI. Others could use XGMII. It would be different
case that as we go along, we decide to drop one of them altogether.
Regards,
Tripathi.
At 04:40 PM 3/24/00 -0800, you wrote:
> > "Roy Bynum" <rabynum@xxxxxxxxxxxxxx> writes:
> > All I can do is observe the actions of the individuals involved with
> > "Hari", and now "XAUI", to be able to determine what their agenda is.
> > I can not ascribe to their actual thoughts or words amongst
> > themselves. I know that several non-"Hari/XAUI" individuals have
> > attempted to be accommodating by allowing it in as an optional
> > implementation practice, only to have it used against them by having a
> > "UniPHY" that has 8B10B as a precoding requirement now be pushed.
>
>Dear Roy,
>
>I'm sorry about this misunderstanding. I see your point here and will
>attempt to explain the situation. I think you are reading way too much
>into the motivations of the various presenters.
>
>When I developed 64b/66b in my naivete, I looked for the most clear
>and succinct description of the 10GbE data stream. At that time that
>the best description I could find was HARI.
>
>I then followed the logic that since HARI transparently supported 10GbE,
>then 64b/66b would also be a transparent conduit provided that it
>transparently signalled HARI semantics. This assumption drove the
>design of the code.
>
>Since I was not an expert in Ethernet, I falsely assumed that the MAC
>was speaking HARI-style octets through XGMII. This includes K,R,A,S,T,...
>etc.
>
>In fact, if I now understand correctly, XGMII only speaks I,S and T.
>The more complex XAUI IPG is not generated directly by XGMII.
>
>OK. Now after that background - here is the fix for your concerns:
>
>64b/66b will be defined to operate from XGMII not XAUI. Although the
>control-code table supports 10 out of the 12 8b/10b control symbols
>XGMII, as the MAC is currently conceived it will not exercise the full
>set. In this regard, 64b/66b is a superset of the functionality that is
>strictly required. This is a *good* thing because it allows for future
>architectural innovations that may need extra control groups to be
>indicated through XGMII by the MAC.
>
>I will change all my future presentation slides to show 64b/66b coding
>XGMII octets, not XAUI lanes.
>
>Rather than showing XAUI-style K/R/A signalling during the IPG, I'll
>change my illustrations to just the simple Idle as indicated by the MAC.
>
>I hope this has addressed your concerns. I can assure you that there
>never was any sort of conspiracy going on here. I'm sure that these
>issues would have been eventually hammered once we moved to firming up
>the standard.
>
>So, there you have it. Both XAUI and 64b/66b are independently
>architected w.r.t. the XGMII interface and have no mutual dependence
>whatsoever.
>
>Any 64b/66b dependence on "8b/10b" comes entirely from the MAC interface
>which specifies a bundle of four octet+control-flag signal groups. When
>the control-flag is asserted, the corresponding octet is interpreted as
>an 8b/10b control code. This is the current XGMII interface. It is
>well beyond the scope of 64b/66b to try to change this. I hope you
>understand that using the XGMII interface is entirely in good faith and
>without any "hidden agenda".
>
>Best regards,
>--
>Rick Walker
>