Re: Interface reality check
Rick,
I applaud your rigorous standards expressed below (especially liked
the analogy about cleaning up campsites), but I want to draw one
distinction regarding control codes. The ordered set control code(s)
(/O/) is (are) needed to transmit Fibre Channel traffic, not solely to
enable XAUI. The needs of byte vs. word striping may vary, but that's
another issue. Ordered sets (K28.5, Dxx.x, Dxx.x, Dxx.x) are a
necessary part of Fibre Channel, as much as SOP, EOP, etc., are for
Ethernet. (Since it's just K28.5, I admit I'm not sure whether it's
extra control codes or just more frame types that are needed.)
I realize that encompassing FC was not part of your original objective
but use of 64b/66b code is being discussed here in the FC plenary
sessions. I think we need to know soon if this code will or won't
accommodate Fibre Channel.
Thanks,
Mike
Rick Walker wrote:
>
> Hi Rich,
>
> > Rich Taborek writes:
> > 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.
>
> I'm actually quite nervous about running out of control codes. I'm
> convinced that we have enough to accomplish out task, but only if we
> take care not to use them up frivolously.
>
> Currently we are limited to 8+2 control codes with a hamming distance of 4.
>
> We could increase that to 16+2 codes with a hamming distance of 3, but I'd
> prefer not to weaken the code.
>
> In working on expanding the 64b/66b codespace to support 3 different
> flavors of /O/ characters for FC, XGENIE, etc., I think we are pushing
> against the limit of both TYPE bytes and control codes. I've looked at
> some exotic ways of extending the code by doing frame checksums, etc.,
> but I'd prefer to keep the code as simple as possible.
>
> I feel that we should be conservative in using up our control space.
> This policy has the advantage of retaining maximum options for future
> standards efforts.
>
> It may be "simpler" for each CODEC to leak out its idiosyncratic
> codes, but I think that this is poor hygiene. Following this path leads
> to using up our control space unnecessarily. If we allow this "leaking"
> for XAUI, then do we also allow it for WWDM-specific codes, or for MAS
> initialization codes, or ...?
>
> I could agree with this policy if the implementation penalty for
> stripping off these extra signals were tens of thousands, or even
> thousands of gates. I don't believe this to be the case, however. The
> implementation cost for stripping out any /A/K/R/ mess is only a few
> hundred gates.
>
> Why should the MAC clean up XAUI's mess?
>
> It's only good citizenship to: "clean up your trash, put your fire out,
> scatter the ashes, and restore your camp to the way you found it".
>
> If XAUI gets away with leaking codes, then we will have to allow it for
> all CODECS, and we will end up with such a complicated MAC clean-up
> policy that we'll never get it right.
>
> A draft of conservative, stable policy is the following:
>
> 1) Do what you are asked to do:
>
> *every* CODEC must support a minimal set of defined Ethernet
> LCD signalling semantics.
>
> 2) Do anything extra that you need to get your job done:
>
> within the domain of a given CODEC, it is permissible to
> introduce CODEC-specific signalling to support special needs
> of that CODEC and its physical layer.
>
> 3) Clean up after you are done:
>
> Any such CODEC-specific extensions *must* be translated back
> to pure Ethernet LCD semantics at the CODEC boundaries.
>
> 4) And to be safe, clean up after anyone who may have broken the rules:
>
> All non-LCD signals received during IPG shall be interpreted
> as IDLE. All non-LCD signals during Data shall be treated as
> Errors.
>
> For those familiar with software engineering, I am simply restating the
> principle of "Information Hiding" and the principle of "Abstract Data
> Types", in a different domain.
>
> Using these principles results in a single abstract interface (which I
> was erroneously calling XGMII). This LCD is *not* a physical
> instantiation, but rather a simple set of semantics that are supported
> by *all* CODECs.
>
> It is something like a subroutine-calling convention, if you will.
>
> A prime rule in the software domain is that *none* of the implementation
> details must "leak" out. The interface (control codes) must be kept
> consistent across all possible implementation (CODEC) styles.
>
> The small amount of extra work to enforce this will be paid back by the
> simplicity of the resulting standard.
>
> In addition, there should perhaps be one more principle to make all
> of this easy:
>
> 5) CODECs shall not be nested.
>
> By this I mean that a XAUI TX always talks to a XAUI RX. Any
> idiosyncratic control codes created by the TX are removed by the RX.
>
> I am suggesting that it should not be architecturally permitted to have
> a XAUI TX talk to a 64b/66b coder in some non-standard way, and to have
> a 64b/66b decoder send symbols to a XAUI RX.
>
> This is allowed: "{}()[]", but not this "{()[]}".
>
> The disallowed nested implementation is the only case for which one can
> make an argument requiring control space leakage. I don't think that
> such a system should be allowed because of the huge cross-pollution that
> it will create in handling control characters.
>
> > The LCD rule just doesn't make sense from an integration viewpoint.
>
> I think it is an essential requirement if we are to have any hope of a
> simple, easily understood standard that can be proven to be rigorously
> correct.
>
> If a single logical (not physical) LCD is agreed upon, then all CODECs
> stand alone. There are no complexifying cross terms or special cases.
> The system analysis is enormously decoupled and the simplified.
>
> Best regards,
> --
> Rick Walker
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mike Jenkins Phone: 408.433.7901 _____
LSI Logic Corp, ms/G715 Fax: 408.433.7461 LSI|LOGIC| (R)
1525 McCarthy Blvd. mailto:Jenkins@xxxxxxxx | |
Milpitas, CA 95035 http://www.lsilogic.com |_____|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~pc
begin:vcard
n:Jenkins;Mike
x-mozilla-html:FALSE
org:LSI Logic Corporation
version:2.1
email;internet:jenkins@xxxxxxxx
title:Senior Design Engineer
tel;fax:408.433.2840
tel;work:408.433.7901
adr;quoted-printable:;;1551 McCarthy Blvd=0D=0AMS G-750;Milpitas;CA;95035;USA
x-mozilla-cpt:;0
fn:Jenkins, Mike
end:vcard