RE: 16-bit wide XGMII
This approach seems to have merit in light of some recent discussions. If
the XGMII can be defined to have some "length" to it, then you may be able
to avoid specifying another intermediate layer/signalling mechanism (XAUI,
etc).
We're working on an un-related interface that is a source synchronous LVDS
bus at 1.25 Gbaud.
JR
At 11:36 AM 3/20/00 -0500, Mike Lerer wrote:
>
>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
>
>
>