Re: 16-bit 625Mbaud XGMII
It seems amazing that there is so little traffic about 10 Gigabit
Ethernet on this list and so much traffic about the backside bus.
Clearly, everyone has a good idea of what they want the PHY to
do. The only thread on the list in the last month about the PHY is
whether they should be separate or UNI.
However there's at least four answers for what the backside bus
needs to be. To summerize the data paths (for each direction):
1) a 32 wide, single ended interface (XGMII)
2) a 16 wide, differential interface
3) a 4 wide, differential interface (XAUI)
4) nothing at all (integrated MAC)
All of these solutions have some virtue and some downside.
And each solution is more optimal for some applications versus
others. Each solution has a degree of "implementation difficulty"
that varies as well. And each solution has a batch of promotors
that feel strongly that their option is the best.
I can see a need for (at least) most of these approaches.
1) The 32 wide part (XGMII) would run at a reasonable speed that
would allow mature, cost effective process technology use
for MAC components. It also allows FPGA protyping. This
is a very appropriate interface for NICs.
2) The 16-bit approach seems to have the length advantages of the 4-bit
wide approach and allows MAC implementation in most of the available
process technologies (but not quite as many as the slower 32-bit
approach). It does not have a reduced pin count.
3) The XAUI approach has great distance span capability and great (low)
pin count, but it requires really fast process technology. This is a very
appropriate piece of hardware for switches and routers.
4) Embedded MAC is great, but it's a level of integration that's very
hard to successfully achieve.
I don't really understand why the "front-side" 10 GBit standard is so closely
tied to the "back-side" interface standard. I asked a bit about this early and the chair
noted the many advantages to a standardized back-side interface. I'm not arguing
against a standardized back-side interface, just that it is a separate problem that
has separate benefits and that it could be worked by separate sub-groups.
Then, if the XAUI folks want to add 47/48+1/2 secret sauce encoding...it does not have
to excite the XGMII folks. Each camp of people can concentrate on making their
solution work rather than searching so hard for flaws in the other approaches. Over
time, the market will prove who is right.
RR
----- Original Message -----
From: Jaime Kardontchik <kardontchik.jaime@xxxxxxxxxxx>
To: <stds-802-3-hssg@xxxxxxxx>
Sent: Thursday, March 23, 2000 5:32 PM
Subject: Re: 16-bit 625Mbaud XGMII
>
> Mike Jenkins wrote:
>
> > Jaime, et al,
> >
> > For what it's worth, I would like to remind everyone who may have
> > lost sight of it, the best way to eliminate the switching noise
> > of the XGMII is to absorb it into the chip. That is, integrate
> > the XGXS and the MAC into one chip, solving not only that
> > switching noise issue, but yielding the pin count benefits
> > of the XAUI interface, as well.
> >
> > I know there is still a migration toward that goal to contend
> > with, but the switching noise issue is very likely more
> > shortlived than the 10G standard.
> >
> > Regards,
> > Mike
>
> Mike,
>
> I had exactly this in mind when I insisted that the electrical
> specs of the (optional) XGMII should be carefully defined so
> as to give a fair chance of success to anyone planning on
> exposing/implementing this interface.
>
> I do not share the optimism of those betting on an
> early (or late) integration of the MAC with the PHY.
> The experience in this area is not very convincing
> and many times in the past it was more effective to have
> two separate chips, one for the MAC and the other for
> the PHY (PCS/SERDES).
>
> Jaime
>
> Jaime E. Kardontchik
> Micro Linear
> San Jose, CA 95131
>
>
>