Re: Interface reality check
Dear Rich,
> Rich Taborek writes:
> 1) XAUI with XGMII on both sides: I've discussed this issue on the
> reflector in detail, especially with Mr. Ben Brown, Nortel. In one
> of our latest communiqué's, Ben agreed with my view of the various
> physical instantiations of the PCS Service Interface:
I admit to poor use of the terminology.
If you want to understand my point, you'll have to listen between the
poor language. If you choose to dissect each sentence rather than read
the entire posting as a whole, then I'll have very little chance of
making my general point understood.
> Why Rick? Are you proposing that the XGMII as a MANDATORY interface
> between the XGXS and PCS? If so, what purpose does this serve except to
> increase 10 GbE product cost?
I've tried to indicate that I am not suggesting a new requirement that
XGMII be be physically instantiated. I agree with you that such a
requirement would be absurd.
When I write "XGMII", it is my attempt to indicate a simple, lowest
common denominator (LCD) of Ethernet signalling. XGMII happens to be
the simplest LCD that I am familiar with. The key property of XGMII is
that it is CODEC independent. Please teach me by suggesting a better
terminology for indicating Ethernet's lowest common denominator of
signalling semantics and I will change my language.
I am not saying that 64b/66b or any other CODEC should refuse to signal
*anything* that is needed by the Ethernet LCD. These signals include
"remote fault", open fiber control, layer 1 signalling, and fibre
channel compatible codes, and any other thing that we might invent.
However, these new signals must be adopted by the entire Ethernet body
and be supported across *all* CODEC styles. If a given CODEC has an
idiosyncratic need for special symbols over and above the Ethernet LCD
then those symbols should be created and destroyed within the boundary
of that particular flavor of CODEC and not "spill out" into other CODEC
definitions.
My basic point, which perhaps you already agree with, is that 64b/66b
has no need to ever see or support /A/K/R/, Idle scrambling, or any
other XAUI-specific control code.
I am fully in support of all CODECs supporting all symbols that have
been decided by the committee to be necessary for supporting Ethernet
LCD signalling semantics.
For example, if the committee chooses to support busy_idle across all
CODECs, it will need to be voted on as an enhancement of Ethernet LCD
signalling semantics. It is not appropriate to have such signalling
introduced through the "back door" by putting it in any particular CODEC
and then requiring that such signalling be supported by all the other
CODECs. The place that such new signals should be created is in the
"XGMII-like" LCD layer that I hope you will provide the proper name for.
I will not go over the rest of your post point by point, because I think
we disconnected quite early over nit picky details due from my poor use
of the terminology.
I am only making the effort to articulate this because (as I currently
understand it) quite a number of people are concerned about this issue.
kind regards,
--
Rick Walker