|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
From: Danielle Lemay [mailto:dlemay@xxxxxxxxxxxxxxxxx]
Sent: Wednesday, September 06, 2000 6:00 PM
To: Joel Dedrick; hfrazier@xxxxxxxxx; stds-802-3-hssg@xxxxxxxx
Subject: RE: XGMII ClocksDo we want to require presence of the XGXS to fully implement the XGMII ?I was hoping the two would be independent.thanks,Danielle-----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
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.