Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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 
> >
> >
> >
>