| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Rick,
Thanks for the additional information here. One question I have regarding
the non-packet codewords (excluding the 'Error' case which I have referred
to in a separate email) is to do with PCS-level link initialisation and
codeword usage for this.
I am trying to think through the sequence of events to bring up a 10Gig link,
comparing it with 1000BASE-X before. Moving up through the layers as far as
the PCS:
(1) PMD - If optics, need some form of 'Signal Detect', light power level.
(2) PMA - Need clock-data recovery.
(3) WIS (optional) - Need SONET (A1,A2) framing
(4) PCS - need 64b/66b codeword alignment at a minimum.
[ Aside: Does PCS codeword alignment belong in the PMA/WIS or the PCS? ].
Codeword alignment might be difficult if there is no guarantee of an 'Idle'
stream, or some special line startup code.
A simple startup sequence would have the PCS transmit a ZZZZ/ZZZZ codeword
repeatedly. And define a 7-bit type for Breaklink. Transmit this
repeatedly until some handshake response comes - Breaklink Response.
The Management Interface (not XGMII or XAUI) would be the source and monitor
of link initialisation. The datapath to/from XGMII or XAUI would only be
enabled once the link is up.
Have you thought about a management interface for sourcing such codewords (i.e.
a data source which is not coming from the MAC directly (but from the Serial
Management interface)? Maybe Brad would add this extra interface on his drawing,
and it would illustrate this.
Providing a PCS Link Initialisation sequence will allow us to isolate faults on
the external link from faults on the local XAUI links. I expect XAUI will also
have some local link initialisation sequence, looking for Comma alignment, and
Receive synchronisation. It would seem crazy to also require a Management
interface to initialise this link, but there will probably need to be a minimal
set of registers, for diagnostic purposes. However, with XGXS separated into two
separate physical devices, would we need management registers on both sides?
Regards,
Una Quinlan.
-----Original Message-----
From: Rick Walker [mailto:walker@xxxxxxxxxxxxxxxxx]
Sent: 08 April 2000 02:39
To: stds-802-3-hssg@xxxxxxxx
Subject: Re: XGMII a/k/r and XGXS - PCS Interface
Dear Una,
> 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
>
> or
>
> Mixed Data/Control Codewords
>
> These are then sub-typed to
> DDDD/DDDD
> ZZZZ/ZZZZ
> ZZZZ/SDDD
> 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
violated.
> ----------------------------------------------------------------
>
> 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.
Best regards,
--
Rick Walker