Re: XGMII Clocks
Jonathan,
I believe that when Sanjeev says "layer that attaches to XGMII" he means
the "XGMII interface logic". Using the example of XAUI/XGXS, the purpose
of the XGXS is to define the "XAUI interface logic". It is true that the
XAUI interface logic is significantly more complex that that of the
XGMII.
The intended purpose of Sanjeev's response is to suggest a way to reduce
XGMII clock jitter, regardless of whether the XGMII clock is
single-ended or differential and DDR or standard rate (2X DDR). The
specific method is to perform precise phase positioning in much the same
way that the XGXS's clock recovery function does. In this case, you're
adding clock recovery to the XGMII. I believe that XGMII clock recovery
is implementation dependent and not a standards issue.
Best Regards,
Rich
--
Jonathan Thatcher wrote:
>
> 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
-------------------------------------------------------
Richard Taborek Sr. Phone: 408-845-6102
Chief Technology Officer Cell: 408-832-3957
nSerial Corporation Fax: 408-845-6114
2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
Santa Clara, CA 95054 http://www.nSerial.com