Re: XAUI and 64b/66b
Rick,
I agree with you that 64B/66B has no dependence on 8B/10B and instead transports
data and control information assembled by the MAC interface (actually the
Reconciliation Sublayer).
Since both the XGMII and XAUI/XGXS are both optional, a Serial PHY employing
64B/66B must operate in the absence of both and as well as the presence of
either or both. To that end, I'll enclose below a mapping of RS data and codes
to codes passed across either the XGMII or XAUI for further encoding by 64B/66B.
This proposed mapping has been developed by Don Alderrou of nSerial:
RS/XGMII RS Code Data Corresponding XGXS/XAUI Codes
Code Name XD<7:0,K> Code name(s)
------------- -------------- -------------------------
DATA (D) xxx xxxxx,0 Dxx.y
IDLE (I) 000 00111,1 K28.5/K, K28.0/R, K28.3/A
SOP (S) 111 11011,1 K27.7/S
EOP (T) 111 11101,1 K29.7/T
ERROR (E) 111 11110,1 K30.7/E
ALT_SKIP (R) 000 11100,1 K28.0/R
ALT_B_SYNC (Kb) 001 11100,1 K28.1/Kb
ALT_unused1 010 11100,1 K28.2
ALT_ALIGN (A) 011 11100,1 K28.3/A
ALT_unused1 100 11100,1 K28.4
ALT_SYNC (K) 101 11100,1 K28.5/K
ALT_unused3 110 11100,1 K28.6
ALT_unused4 111 11100,1 K28.7
ALT_B_SKIP (Rb) 111 10111,1 K23.7/Rb
Kardont@xxxxxxx wrote:
>
> Rick,
>
> These are good news. I only would like to point out some slight differences
> in interpretation about what the XGMII delivers/receives. You will find my
> comments between the lines of your email:
>
> In a message dated 3/25/00 12:50:43 AM, walker@xxxxxxxxxxxxxxxxx wrote:
>
> > ...
> >In fact, if I now understand correctly, XGMII only speaks I,S and T.
>
> In reality the XGMII does not speak I (Idles). It only speaks D (raw
> unencoded data), S (Start of Frame), T (End of Frame) and perhaps E (on
> purpose introduced errors for debugging purposes). It is the PCS that defines
> and sends I (Idles) between frames to the PMA/PMD.
Jamie,
You are correct that the in saying that the XGMII transports more than I, S and
T and have properly identified that it also transports D (data) and E (error).
In support of the Busy Idle Rate Control Mechanism, the XGMII must also
transport Kb/Rb or similar means of indicating Busy Idle to the PCS. The table
above simply mirrors existing proposals on the table.
> >Any 64b/66b dependence on "8b/10b" comes entirely from the MAC interface
> >which specifies a bundle of four octet+control-flag signal groups. When
> >the control-flag is asserted, the corresponding octet is interpreted as
> >an 8b/10b control code. This is the current XGMII interface.
> >--
> >Rick Walker
>
> The XGMII is different.
>
> The MAC does not deliver 8b/10b information through the XGMII and the octets
> it delivers/receives are never interpreted as 8b/10b control codes. When the
> control flags are '0' the MAC signals/interprets that the corresponding lanes
> carry raw unencoded data. When the control flags are '1' the MAC
> signals/interprets that the corresponding lanes do not carry anything.
On the contrary, since more than one control code is required per lane to
distinguish between I, S, T, E, etc. lanes must contain a code which identifies
the specific XGMII code whenever the corresponding control flag is set to '1'.
I may be missing something obvious in your response. If I am, please supply me
with your complete coding table which supports all of the following:
1) Direct connection between RS and 64B/66B PCS;
2) Optional XGMII between RS and 64B/66B PCS;
3) Optional XAUI/XGXS between RS and 64B/66B PCS;
4) Optional XGMII and XAUI/XGXS between RS and 64B/66B PCS;
5) Support for functions in other proposals such as Idle Busy.
> The XGMII is transparent to and does not have any preference towards any PCS
> coding.
If "transparent" implies "independent", then I agree. If not please explain.
> Jaime
--
Best Regards,
Rich
-------------------------------------------------------
Richard Taborek Sr. Phone: 408-845-6102
Chief Technology Officer Cell: 408-832-3957
nSerial Corporation Fax: 408-845-6114
2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
Santa Clara, CA 95054 http://www.nSerial.com