Re: Source centered vs source sync
Boaz,
My initial point on this thread was to point out a problem with the
"process" rather than any technical difficulty. My point was that a
P802.3ae vote resulted in a technical change for no apparent benefit and
a possible delay in early products implementing the XGMII.
Your latest discussion appears to re-invent the XGMII to a greater
extent. Three XGMII decisions were made in New Orleans:
1) Change to HSTL levels normalized to 1.8 V from SSTL_2 at 2.5 V
2) Change from Source-Centered to Source-Synchronous clocking
3) Decision for no change to single, single-ended DDR clock @ 156.25 MHz
I stand by these decisions. I don't support a movement to reverse any of
the decisions, or double the clock frequency. What we have is workable
and will disappear in due time.
Best Regards,
Rich
--
Boaz Shahar wrote:
>
> Rich,
> I do not agree.
> I'm thinking that the change (Moving from Source Centered to Source
> Synchronous) forces designs to use CMOS Delay Elements that were not needed
> before.
>
> First, even if what you say was true, then for those designs which are using
> 312.5 internal clock, creating a Source-Centered timing is very simple and
> does not require any type of Delay-Element (And this is true for the MAC/RS
> layer or even the 10GBASE-R PCS with direct XGMII, so that the optional
> nature of the XAUI/XGXS is not relevant here).
>
> Second, I think that 312.5 design is simpler and with lower complexity than
> 156.25 design. This is because of two reasons: 1. Most of ASIC design tools
> are built to work with a SINGLE clock edge (Typically rising) and 2. Using a
> single edge 156.25 clock means wider architecture in terms of conductors and
> metals, and more area.
>
> The change enforces the designs to use Delay Element. Either on the board,
> or in the silicon. If it is on the silicon it creates a yield problem,
> because of the big variance (x3) from best case to worst case delays. If its
> on the board, its another device with value which is depending on XGMII
> length, Board trace and physical structure.
>
> (I may be true that for 156.25 designs you need the delay elements anyway)
>
> I think that the real question here is: Is there any objection to go back to
> the original proposal:
> http://grouper.ieee.org/groups/802/3/ae/public/jul00/frazier_1_0700.pdf
>
> Boaz
>
> > -----Original Message-----
> > From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
> > Sent: Thursday, September 28, 2000 7:26 AM
> > To: HSSG
> > Subject: Re: Source centered vs source sync
> >
> >
> >
> > Boaz,
> >
> > I'm assuming that you "usually don't" have a 2X internal clock in the
> > XGMII, XAUI/XGXS aside since it's optional. The only reason
> > for having a
> > 2X internal and 1X external (i.e. DDR) XGMII clock would be
> > if EMI were
> > the primary concern. I believe that EMI is actually a
> > secondary concern.
> > Therefore, a source-centered clocking scheme requires delay
> > elements at
> > the transmitter and source-synchronous requires delay elements at the
> > receiver. PVT dependence is applicable to the respective
> > delay elements,
> > further complicating the problem. This is why I view the recent change
> > as six of one, half dozen of the other. The change only moves the
> > problem and forces everyone to change both their Rx and Tx
> > I/O buffers.
> >
> > P.S. The PCB trace can be a delay element as well as Curt
> > Berg suggests.
> >
> > Boaz Shahar wrote:
> > >
> > > Hi,
> > > I absolutely agree.
> > >
> > > I would like to add that you do not need to use
> > buffers/delay elements in
> > > order to create the Source Centered clocking scheme,
> > because in the source
> > > you usually have 2x internal clock which allows you to create the
> > > Delay-Shift in an accurate and process independent manner.
> > >
> > > Boaz
> > >
> > > > -----Original Message-----
> > > > From: Devendra Tripathi [mailto:tripathi@xxxxxxxxxxx]
> > > > Sent: Tuesday, September 26, 2000 7:51 PM
> > > > To: stds-802-3-hssg@xxxxxxxx
> > > > Subject: Source centered vs source sync
> > > >
> > > >
> > > >
> > > > Hi,
> > > >
> > > > One problem I found in implementing source synchronous design
> > > > is that we need
> > > > to adjust timing by inserting buffers. When worst case to
> > > > best case ratio
> > > > of delays
> > > > are high, this becomes a tough problem to solve (especially
> > > > when available
> > > > time is
> > > > a few ns). In centered clock case, this does not become a
> > > > problem. There may be
> > > > still buffers in clock/data paths but they track each other
> > > > under various
> > > > conditions.
> > > > To take example of FC vs. GMII timings, I have found GMII
> > > > timings (which are
> > > > source sync.) much difficult to implement compared to FC
> > > > (which is source
> > > > centered).
> > > >
> > > > Regards,
> > > > Tripathi.
> > > >
> > > >
> > > > At 01:25 AM 9/26/00 -0700, you wrote:
> > > > >stds-802-3-hssg@xxxxxxxx
> > > >
> > > > Best Regards,
> > > >
> > > > Devendra Tripathi
> > > > Vitesse Semoconductor Corporation
> > > > 3100 De La Cruz Boulevard
> > > > Santa Clara, CA 95054
> > > > Phone: (408) 986-4380 Ext 103
> > > > Fax: (408) 986-6050
-------------------------------------------------------
Richard Taborek Sr. Phone: 408-845-6102
Chief Technology Officer Cell: 408-832-3957
nSerial Corporation Fax: 408-845-6114
2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
Santa Clara, CA 95054 http://www.nSerial.com