RE: 16-bit wide XGMII
Perhaps something can be learned from the SONET world which has been dealing
with OC-48 2.5 Gigabit and OC-192 10 Gigabit data rates.
At OC-48 there is almost universal agreement on a 32 bit at 100 MHz interface
between Network processor and Framer.
Saturn group POSPHY 3
ATM Forum Utopia 3
OIF SF3.
At OC-192 there are two approaches. The straight forward approach which is to
make the bus faster and wider as evidenced by:
OIF SF4A which speaks to a HSTL 64 bits at 200 Mhz interface.
Or the more elaborate approach taking note of the increased clock rates and the
desire of some that the interface be able to go through connectors. This
results in the following tentative specifications.
OIF SF4B 16 bits LVDS at 832 Mhz
Saturn POS PHY Level 4 16 bits LVDS at 832 Mhz
ATM Forum Utopia 4 32 bits LVDS at 400 Mhz
Mike Lerer
Avici Systems Inc.
101 Billerica Ave
North Billerica, MA 01862-1256
Phone 1-978-964-2058
Fax 1-978-964-2100
-----Original Message-----
From: Jaime Kardontchik [SMTP:kardontchik.jaime@ulinear.com]
Sent: Sunday, March 19, 2000 10:19 PM
To: HSSG
Subject: 16-bit wide XGMII
Rich Taborek wrote:
> Walt,
>
> I have never viewed XAUI/XGXS as REQUIRING the XGMII. XGMII has always been
> proposed as an optional interface as was XAUI/XGXS. Therefore, XAUI/XGXS is
> proposed as an additional interface. It was then located in the stack between
> the XGMII and PCS.
>
> I don't believe that there were ever any presentations made to the HSSG nor
any
> reflector discussion requiring an XGMII for XAUI. The only folks I ever hear
> suggesting such a requirement are those that dislike XAUI/XGXS for one reason
or
> another, mostly because it's not SONET.
>
> The XGMII and XAUI/XGXS directly follow the well proven and flexible
1000-BASE-X
> architecture where both the GMII and TBI are optional. Requiring the XGMII is
> not consistent with the evolution of 1 GbE products where the SerDes (PMA)
has
> moved into the MAC/PHY ASIC in many instances to reduce product cost and
enable
> higher port densities.
>
> .....
>
> Extending the XGMII with XAUI/XGXS just to provide another XGMII on the other
> side is simply not optimal from an architecture or implementation viewpoint.
> Early prototypes 10 GbE solutions may do this, but so what. .....
> .......
> I then have to go back to the root issue in the last paragraph because I fail
to
> see
> another one. Please help!
>
> Best Regards,
> Rich
>
Hello 10G'ers,
Help is coming !
We initially had a 32-bit data/4-control wide
optional XGMII interface, clocked at 312.5 Mbaud.
Then HARI came and we added an additional 4-lane
interface, clocked at 3.125 Gbaud, with the 8b/10b
coder inside. It became the optional XAUI interface.
Then the final step came. Rich, suggests now that
the XGMII interface is clumsy anyway and people will
not implement/expose it. So let's center everything
on the HARI interface, and force all the architectures
to use it. Those that will not be compatible with it
will have to be thrown away due to their clear
inferiority.
There is another solution.
I propose to define a 16-bit data/2-control wide
XGMII interface, clocked at 625 Mbaud. The data
will be raw data from the MAC, without any encoding
added, except perhaps for the SOP, EOP and ERROR.
And I propose to delete the HARI optional interface
from the 10 GbE standard.
The 16-bit wide XGMII inteface does not exclude any
10 GbE proposal. SONET and WAN people will love it.
People that want to transmit 10 Gbps on long
Copper traces can use it with no problem at
all: They can add HARI with the 8b/10b encoder
clocked at 3.125 GHz or the PAM-5 encoding
clocked at 1.25 GHz or the 64/66 clocked at 2.578 GHz.
Or any other scheme they wish for Copper backplanes.
The standardization of a particular PHY for Copper
backplanes should be left outside the 10 GbE standard.
Jaime
Jaime E. Kardontchik
Micro Linear
San Jose, CA 95131
email: kardontchik.jaime@ulinear.com