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

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@xxxxxxxxxxx]
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@xxxxxxxxxxx