Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Interface reality check





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