| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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