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

RE: XGMII Clocks

Title: RE: XGMII Clocks
Both the XGMII and the XGXS/XAUI are optional interfaces and may be implemented in a manner such that they are independent.  The XGXS is being architecturally structured as a means to extend the reach between a 'MAC' device and a 'PHY' device.  Although it is shown that XGMII exists on one side and XAUI exists on the other side, this is only an architectural representation for the means of developing a standard.  If the 'MAC' and 'PHY' devices only provide a XAUI, that doesn't mean they require XGMII internally in the devices.  Likewise, if the devices only provide XGMII, they don't have to use a XAUI. See the following presentation for representation of various possible implementations:
These are not the full set of possible implementations.  It should be noted that what the standard is focused on is the ability to comply with whatever interfaces the implementer chooses.  The only required compliant interface is at the MDI.  All other interfaces in the standard are optional and compliance with them is based upon the implementer's discretion.
-----Original Message-----
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 Clocks

Do we want to require presence of the XGXS to fully implement the XGMII ?
I was hoping the two would be independent.
-----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.


Joel Dedrick