Re: XAUI and 64b/66b
> "Brown, Ben [BAY:NHBED:DS48]" <bebrown@xxxxxxxxxxxxxxxxxx> writes:
> I need to apologize to you. I've been having this conversation
> with Rich Taborek as if it is his proposal and not including
> you. Please, accept my apology and chime in any time with your
No problem. It's the information flow that counts. Thanks for
thinking of me, though.
> Wonderful! I agree with you completely. This means the transmit
> PCS simply 64b/66b encodes the information it gets from the MAC
> service interface, be this information in the form of XGMII
> encodings or XAUI encodings.
I don't like this.
I think that a reasonable alternative would be for XAUI to always
take in XGMII and deliver XGMII. A 64b/66b code has no business
indicating /A/ characters. None at all.
All PMD's could take their input from pure XGMII and convert back to
XGMII at their output. It makes no sense to burden all the PMDs with
complex rules for converting between the idiosyncrasies of other coding
> The receive PCS must have the intelligence to know whether its MAC
> service interface requires XAUI encodings or XGMII encodings.
This is really bad. If a future new PMD is invented, how do you upgrade
all the installed base of PMDs to have the new "intelligence" to know
about how this new PMD operates?
> It simply 66b/64b decodes the information then may pass the data
> straight through or convert it to XAUI or XGMII, whichever is
I think that all PMDs should operate on and deliver pure XGMII signals.
> Rich Taborek writes:
> The only thing I disagree with is a REQUIREMENT to implement the XGMII
> between the PCS and XGXS. The writing of the standard should not
> basterdize straightforward implementations.
Of course, I don't mean here that you actually need a 36-bit bus in your
physical implementation, just that the space of control signals should
be strictly limited to the fully sufficient set defined for XGMII. This
does not bastardize the implementation - it is simply a guideline for
what sorts of signalling is supported by a PMD.