RE: Source centered vs source sync
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
> > >
>
> --
>
> Best Regards,
> Rich
>
> -------------------------------------------------------
> 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
>
>