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