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

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