RE: XGMII Clocks
All,
I think that it's important that XGMII<>XGMII back-to-back connections be
supported. Having center-synchronous in one direction and edge-synchronous
in the other seems going too far to ease a particular implementation.
It is quite common today to use GMII as an interconnect between equipment
without ever going to a physical layer. This technique allows one to have
an interface between chips that scales from low distance/low cost
(GMII/XGMII) through a midpoint (CX/XAUI) to high distance/high cost
(TX/LX/SX/etc).
We should encourage and support such use of Ethernet components.
-Simon Sabato
-Intel Corporation
-----Original Message-----
From: Jonathan Thatcher [mailto:Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx]
Sent: Wednesday, September 06, 2000 5:56 PM
To: 'Sanjeev Mahalawat'; HSSG_reflector (E-mail)
Subject: RE: XGMII Clocks
Sanjeev,
> I do not think this is specific to XGXS layer.
> It applies (or can be applied) to any
> layer that attaches to XGMII.
You mean like the RS or the MAC layer???
I know, you mean any layer below the XGMII layer. But, I interpret: "has a
high-rate clock it can divide down to get precise phase positioning of the
sample point" to mean that any layer below the XGMII MUST HAVE a high-rate
clock it can divide down....
Is this a reasonable requirement? I can think of implementations where there
might be a chip between the XGMII interface and the chip that has a PLL.
Should these be excluded?
jonathan
> -----Original Message-----
> From: Sanjeev Mahalawat [mailto:sanjeev@xxxxxxxxx]
> Sent: Wednesday, September 06, 2000 4:57 PM
> To: Jonathan Thatcher
> Cc: stds-802-3-hssg@xxxxxxxx
> Subject: RE: XGMII Clocks
>
>
> Jonathan
>
> I do not think this is specific to XGXS layer.
> It applies (or can be applied) to any
> layer that attaches to XGMII.
>
> Thanks
> -Sanjeev
>
>
> At 04:04 PM 09/06/2000 -0700, you wrote:
> >
> > All,
> >
> > It must be remembered that the XGXS (XAUI) interface is
> optional. I do not
> > believe that it can be depended on to provide any XGMII
> signal that is
> > required when there is no XGXS.
> >
> > jonathan
> >>
> >> -----Original Message-----
> >> From: Joel Dedrick [mailto:Joel_Dedrick@xxxxxxxxxxxxxx]
> >> Sent: Wednesday, September 06, 2000 1:54 PM
> >> To: hfrazier@xxxxxxxxx; stds-802-3-hssg@xxxxxxxx
> >> Subject: RE: XGMII Clocks
> >>
> >> All:
> >>
> >> I'd like to add my voice to those including Sanjeev who
> suggest that the
> >> right solution to this problem is not to try to bandaid a
> source-centered
> >> clock solution which is nearly impossible for the MAC to
> generate correctly
> >> anyway. Source centered DDR clocking in the absence of a
> higher-rate clock
> >> to use as a phase reference, requires generating fixed
> delays in order to
> >> place the clock at the desired point in the setup/hold
> window. However, no
> >> delay is fixed in CMOS - they vary over some factor larger
> than 2:1 over
> >> process and temperature, never mind the effects of duty
> cycle variation.
> >> Better to let the MAC do what's easy -- transmit a clock
> which is nominally
> >> timed like any other data bit, and let the XGXS, (which
> has a high-rate
> >> clock it can divide down to get precise phase positioning
> of the sample
> >> point) sort out where to sample the data.
> >> In the reverse (toward the MAC) direction, source centered
> clocking is
> >> appropriate. The XGXS can precisely place the sample
> clock using a divided
> >> down XAUI baud clock, making the MAC side trivial. In
> other words, solve
> >> this problem on the end of the link where the best tools
> are available.
> >> This solution probably obviates the need for differential
> clocks, since it
> >> removes much bigger sources of clock to data uncertainty,
> but I wouldn't
> >> object if others feel we should go differential as an option.
> >> I plan a presentation next week to elaborate on this idea.
> >>
> >> Regards,
> >>
> >> Joel Dedrick
> >> PMC-Sierra
> >
> >
> >
>