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.
Great.
> 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.
Excellent.
--
Rick Walker