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

RE: XGMII Clocks


I do not think this is specific to XGXS layer. 
It applies (or can be applied) to any 
layer that attaches to XGMII. 


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