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