Re: 64/66 control code mapping
I was unaware that there was a separate ad hoc for the 64B66B encoding. I
know that a group of you are working with the 'hari' people to develop a
method of keeping 'hari' as part of the requirements for all of the PHYs in
the standard. I did not know that it had developed into an officially
sanctioned ad hoc with an officially sanctioned reflector extension. I was
unable to get one for the EoS ad hoc when I asked for it. How did you do it
for something as simple as an encoding scheme?
Note: I am still using this e-mail because I have not been able to get my
mindspring account active on the reflector yet.
Rick Walker wrote:
> Dear Ben,
> > I've been looking at your 64b/66b presentation and, in
> > particular, looking at your control code mapping. The
> > 7-bit line code is specific to encodings from the 8b10b
> > XAUI interface. This is an optional interface and may
> > not exist between all MAC and PCS layers. When the XAUI
> > doesn't exist, what 7-bit line codes should be used?
> The same linecodes as for XAUI.
> A 64/66 coder running off of XGMII needs all the logic of a XAUI encoder
> except for the 8b/10b encoders and serializers. This logic is required to
> ensure insertion of Align characters, force SOP to be in lane 1, etc.
> > Given the protocol stack shown by Brad Booth, I would expect that this
> > PCS layer be specified to an XGMII and not to an XAUI.
> > Implementations may choose to short- cut the conversion from XAUI to
> > XGMII to 64b/66b but the specification should assume it communicates
> > to the XGMII.
> XAUI can be thought of as an optional XGMII extender.
> 64/66 is probably best thought of as optional XAUI physical layer.
> 64/66 replaces XAUI's 4x3.125Gb/s physical layer with a single 10.3Gb/s
> serial fiber link. In the same way, WWDM or parallel fiber solutions
> can be thought of as optional XAUI physical layers.
> This may not be consistent with 10GbE's rigorous taxonomy of layers, but
> I think it is a self-consistent way to describe the situation.
> If you want to discuss this further, we should probably move to the 64/66b
> reflector at:
> I've replied both to the main hssg reflector and to the 64/66 address.