Re: XGMII a/k/r and XGXS - PCS Interface
> Una Quinlan <Una_Quinlan@xxxxxxxxxxxxxx> writes:
> Commenting on Brad's latest drawing:
> I agree with your current summary of what crosses the XGMII interface,
> and the XAUI interface. One thing that would need to be captured, though,
> is the restriction in what can cross each byte lane - for example the /s/
> can only be present in XGMII lane 0.
> However, what is being carrier across the medium is not 10B codes, but
> 64b/66b codewords (in a serial PMD case) which are much more restricted:
> Data Codewords
> Mixed Data/Control Codewords
> These are then sub-typed to
> TZZZ/ZZZZ and all other 7 EOP options
> + new proposals for ODDD etc.
> I don't know what code sequences were planned for mapping /e/ combinations,
> but lets assume that is covered also - Rick, had you thought about this?
/e/ is one of the set of possible Z code symbols. When the 64b/66b
coder receives an invalid RS indication it transmits ZZZZ/ZZZZ with the
Z's being set to /e/.
Actually, this is not quite correct because there there is neither an
/e/ nor /E/, but rather a 64b/66b logical equivalent, call it \E\ for
lack of a better notation.
> (Actually, I don't know why ODDD isnt actually represented as ZDDD,
> because ODDD is usually a K*.* with 3 following data bytes).
This is because the \O\ character is not any general control code. Only
a particular \O\ is allowed, not a general set of Z codes. Also, it
is just a shorthand to say "ODDD", because the "D" characters in this
context are not the same as "D" characters that compose a data payload.
The "D" groups in the "ODDD" are arbitrary user-defined bit patterns to
be used for any purpose. They are not packet data.
This distinction is what requires ODDD to be transported explicitly with
its own TYPE byte.
> If there is no state-machine, what will the PCS output? If XGXS continues
> to present illegal codes, we want to ensure the packet gets terminated
> correctly, but how is this achieved in a predictable fashion?
We have only mentioned it in passing, but it is expected that the 64b/66b
input block will have a state machine to detect improper input indications.
If XAUI is used, then we rely on XAUI to reliably detect lane skew
problems and to signal the 64b/66b CODEC with an /e/ indication.
If XAUI is not used, we still do some sanity checking on the RS or XGMII
output and will force a 64b/66b /EEEE/EEEE/ frame if proper syntax is
> Another question that I have, which relates to the XGXS - PCS interface
> comes from the 66b Codeword summary:
> Take the case of a codeword ZZZZ/ZZZZ. The PCS does not need to place any
> constraint on the specific Control characters carried - for example if
> it was requested to map eight 'K28.7 Type' characters in sequence, it would
> happily do so. I don't expect that there will be any restrictions here,
> except to conform to one of the 66b Codeword types.
Yes. I have been assuming this. It is expected that commodity optical
modules with XAUI or XGMII-like interfaces will be produced with full
control code generality. This will make the same module useable for
FC/Ethernet or a proprietary backplane application.
The general principle for the 64b/66b CODEC is to allow any one of the
8-permitted control indicators to be substituted for any occurance of Z
in the code definition table.
This is very likely to be more general than what is allowed for Ethernet.
My previous statements about "code leakage", etc., are w.r.t. what
Ethernet standardizes, not what 64b/66b supports.
> Therefore - if the XGXS (in the PHY) does not 'clean up' in error
> conditions, then the PCS will end up transmitting illegal sequences. We are
> now propagating a local XAUI link problem to the outside world, which seems
> unnecessary. So I see this as another good argument for getting the XGXS to
> decode back to an XGMII interface, and let the PCS work with this as a
> starting point.
Certain illegal sequences are detectable and will be forced to EEEE/EEEE
indications. An example would be an XGMII-like indication of DZDZ/DZDZ,
or SDDD/TDDD. Neither of these indications correspond to valid 64b/66b
frames, so will produce error-indicator frames.