Re: Interface reality check
Rick,
I'm going back to a somewhat "old" note from you that I had not previously
responded to.
In this note, you speak of a "lowest common denominator (LCD) of Ethernet
signaling".
I do agree completely with your basic point: "that 64b/66b has no need to ever
see or support /A/K/R/, Idle scrambling, or any other XAUI specific control
code."
My point is that since we're far from running out of control code space in
64B/66B, that it's simpler to have 64B/66B transport /A/K/R/ or /I/ it doesn't
really matter, and have the final receiver, at the Reconciliation Sublayer,
treat /A/K/R/ as /I/. This would also apply to all other codes not defined in
Ethernet.
The LCD rule just doesn't make sense from an integration viewpoint.
Best Regards,
Rich
--
Rick Walker wrote:
>
> 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
-------------------------------------------------------
Richard Taborek Sr. Phone: 408-845-6102
Chief Technology Officer Cell: 408-832-3957
nSerial Corporation Fax: 408-845-6114
2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
Santa Clara, CA 95054 http://www.nSerial.com