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

Re: XAUI and 64b/66b




Rick

Thank you for the explanation.  It is not so much the motivations of some of
individuals that I am objecting to as much as the paradigm and perceptions
that are presented by some of the individuals.  You fell into this when you
mistakenly accepted that 8B10B was the defacto coding coming out of the MAC
to the PCS.  It is this defacto perception that keeps 8B10B coming back in
different forms all the time.

Given the architectural structure of the standard, I think that using XGMII
signals as a precursor for any coding is the correct thing to do.  In that
case, only the XGMII signals, or characterizations should be carried through
the 64B66B, to the receiver.  With none of the 8B10B codings carried
through, the receiver does not have to interpret and convert codes for which
there are not equivalents in the XGMII, when XAUI is not present.

I apologize if I seem a bit paranoid.  You must admit that it is a strange
set of circumstances.

Thank you,
Roy Bynum


----- Original Message -----
From: Rick Walker <walker@xxxxxxxxxxxxxxxxx>
To: <stds-802-3-hssg@xxxxxxxx>
Cc: Roy Bynum <rabynum@xxxxxxxxxxxxxx>
Sent: Friday, March 24, 2000 6:40 PM
Subject: Re: XAUI and 64b/66b


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