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