Re: Interface reality check
Rick,
Bottom line is that if /A/K/R/ and even /I/ are supported only as full columns
(i.e. /AAAA/, /KKKK/, /RRRR/ and /IIII/ that no additional TYPE codes need be
added and a hamming distance of 4 is preserved. The addition of 7-bit line codes
for /A/ and /I/ should be straightforward and good hamming distance is
maintained if /A/'s and /K/s always occur in columns. I believe that potential
nervousness about running out of control codes to support /A/K/R/ in 64B/66B is
unfounded.
Mr. Ben Brown and I seem to agree that the only issue remaining with respect to
"code leakage" is whether or not the XGXS transmitter is allowed to forward
/A/K/R/ to the PCS or not. Doing so is not a problem for the strongly endorsed
WWDM and Serial LAN PHY proposals. I don't see any problem with PAM5 either as
all my PAM5 proposals supported it.
I don't understand your comment about the MAC cleaning up XAUI's mess. My
current proposal is to terminate all XAUI control codes at the Reconciliation
sublayer, which is part of the PHY.
Best Regards,
Rich
--
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
-------------------------------------------------------
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