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

Re: Interface reality check

Dear Rich,

> The issue is not whether XAUI encodings are required for 64B/66B, the
> issue is whether either the MAC needs to signal the PHY with anything
> other than Idles or the PHY itself needs to signal over the medium. 

Absolutely.  This is exactly what I was trying to indicate.  I only
used XAUI as a particular example of this more general problem. 

> I completely forgot about the obvious case of ERROR, where the MAC
> transmitter or the PHY at any point in the link needs to replace a
> data or control code with an ERROR code.  In order to support this
> proposed function, 64B/66B must transport /E/ codes in addition to /I/
> codes across the medium. 

/E/ has been in the 64b/66b control table for some time now.  Any one
of /K/ or /R/ can be redefined to be /I/ as they are not needed for
the 64b/66b functionality.

> This makes for a potential requirement to signal at least three
> control codes besides /I/, /T/, /S/ and /D/ across 64B/66B and the
> medium.  A further requirement is to support the transport of these
> codes through the optional instantiations of the PCS Service
> interface. 


> One way I'll propose to do this cleanly is to have the RS receiver
> treat /A/K/R/ the same as /I/.  In fact, all codes other than /T/,
> /S/, /D/ and /E/ could be treated as /I/ by the RS receiver until
> those other codes are defined by 10 G bE. 

Thank you for working through this.  I'm quite happy with this proposal.

I apologize for the difficult time in communicating.

> No translations by the PCS, including 64B/66B, would be necessary. 

Rick Walker