Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: 16-bit 625Mbaud XGMII




Hi Jaime,
If I recall correctly, last time a 16 bit interface
was proposed, it was a differential interface. This would 
take about the same amount of pins as a single ended 32 bit XGMII.
(Anyone know about a single ended PMA to PMD interface?)

For design simplicity a single ended 312.5 Mbaud is very much preferred.

-Curt Berg-
Extreme Networks


-----Original Message-----
From: Jaime Kardontchik [mailto:kardontchik.jaime@ulinear.com]
Sent: Monday, March 20, 2000 1:57 PM
To: stds-802-3-hssg@ieee.org
Subject: 16-bit 625Mbaud XGMII



Hello 10G'ers,

I do not remember any detailed discussion in the HSSG
about the optimum number of octets for the XGMII,
except for a brief discussion in Idaho, June 99, at the end
of the presentation's section (the so called motion
madness period), where people brainstormed about whether to
choose a 32, 16 or 8 bit wide MII interface.

An 8-bit XGMII was considered too advanced and 32 was
considered a very matured CMOS technology (it needs a
symbol rate of only 312.5 Mbaud).

It seems that 32-bit wide was chosen by default because
it also fitted nicely with the HARI interface that was
being developed in parallel in another forum (Infiniband).

However, 32-bits means an interface consisting of
2*(32+4+1) = 74 I/Os. This is very different from the
small MII interfaces we were used to in previous versions
of Ethernet. An interface with two many I/Os leads people
in a natural way to try to hide it and avoid implementing
it. This gave rise to the second interface, XAUI, with
only 8 lanes (4 for Tx, 4 for Rx). This interface has
the advantage that can be easily exposed. However, it
comes with an added weight that the XGMII did not have:
the I/Os in the 4-lane XAUI are not raw data but encoded
symbols. And everyone proposes a different encoding: 8b/10b,
64/66, PAM-5, etc., etc. Hence, the 4-lane XAUI creates
a serious problem of compatibility and interoperability.

The solution seems to be to go back to the XGMII and
use a 16-bit wide interface with a symbol rate of 625 Mbaud.
This amounts to 2*(16+2+1) = 38 I/Os, total. This is an
interface that can be exposed. In addition, since the I/Os
send/receive raw unencoded data, this interface is
compatible and interoperable with any coding scheme applied
later in the chain to the raw data.

A 16-bit wide interface is a well known interface for the
WAN PHY proponents that already use 16-bit wide interfaces
between the PMA and the PMD.

For those that need to carry the 10 Gbps over long Copper
traces in the backplane before reaching the PMD and wish
to use in the Copper traces the 4-lane scheme shown in
H. Frazier's presentation "10Gig MII update", Nov 99,
they only have to add at the input of their PCS/PMA
chip a simple 1:2 serial to parallel converter to go
from 16-bits wide at 625 Mbaud to 32-bits wide at
312.5 Mbaud, and from then on use the 4-lane architecture
they wish (see page 19 in H. Frazier's presentation).

The same applies to those that want to run the MAC at only
312.5 MHz.

Finally, for those that would like to integrate in the
future the MAC with their specific PCS, they can eliminate
the XGMII and run both the MAC and the PCS at 312.5 MHz,
without the need to upconvert and downconvert at the
(deleted) XGMII.

Using a 32-bit wide exposable XGMII eliminates, in practice,
the need to define an additional XAUI interface, which is
in fact a PHY transceiver over Copper for backplanes using
a specific coding scheme.

10 Gbps PHY transceivers over Copper backplanes should be
left outside the scope of the 10 GbE Standard.

Jaime

Jaime E. Kardontchik
Micro Linear
San Jose, CA 95131
email: kardontchik.jaime@ulinear.com