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

Re: 20 / 100 ppm




Hi all,

      IMHO.....maybe it is a latency issue. Speaking in general terms, FIFOs
are used to accomodate for the frequency variations of 20/100 ppm which
add latency.....FIFO thresholds are set accordingly.
So, the ppm number directly translates to FIFO size(based on the max size
of frame) which in turn translates to the maximum latency allowed.

Rahul Bhushan
IC Design Engineer
STMicroelectronics Inc.
Nepean ON Canada.

benny.christensen@xxxxxxxxx wrote:

> Hi all
>
> Maybe, this is still one of these paperwork artisfact, that nobody knows how
> these numbers get into a standard - and people forget the past - but the
> numbers exist even without any sane explanations.
>
> Jugnu,
>
> THe frequency accuracy has nothing to do with the jitter of the device.  The
> ppm figure is typical covering the accuracy of the oscillator frequency
> (over temperature and supply voltage ranges including ageing).
>
> Furthermore, in the receiver, the ref.clk is only used during acquisition of
> the VCO frequency.
>
> Benny
>
> > -----Original Message-----
> > From: Jugnu Ojha [mailto:jojha@xxxxxxxxxxxxxxxxxxx]
> > Sent: 9. maj 2001 02:30
> > To: 'pat_thaler@xxxxxxxxxxx'; benny.christensen@xxxxxxxxx;
> > stds-802-3-hssg@xxxxxxxx
> > Subject: RE: 20 / 100 ppm
> >
> >
> >
> > Folks,
> >
> > Although I'm not an expert on this issue, I can propose some reasoning
> > behind some of the cost statements being made.  Presumably,
> > clock recovery
> > should be easier with a lower-jitter signal (20 ppm), since
> > the signal is
> > effectively cleaner (i.e., you should need a lower-Q
> > resonator - another way
> > of saying the resonator doesn't need to be as robust against jitter).
> > Basically, a cleaner signal relaxes the requirements on the
> > receiver.  Now,
> > this should only matter much if it makes the difference
> > between having an
> > integrated resonator or a discrete one - the latter would
> > increase costs
> > associated with packaging, yield loss, etc.
> >
> > Regards,
> > Jugnu
> >
> > Jugnu J. Ojha, Ph.D.
> > Technical Advisor, Optical Networking
> > Caspian Networks Inc.
> > (408) 382-5213
> > fax:  (408) 382-5588
> > jojha@xxxxxxxxxxxxxxxxxxx
> >
> > -----Original Message-----
> > From: pat_thaler@xxxxxxxxxxx [mailto:pat_thaler@xxxxxxxxxxx]
> > Sent: Tuesday, May 08, 2001 3:01 PM
> > To: benny.christensen@xxxxxxxxx; stds-802-3-hssg@xxxxxxxx
> > Subject: RE: 20 / 100 ppm
> >
> >
> >
> > Benny,
> >
> > The pointer adjustment mechanism can adjust for rate
> > differences of over 100
> > ppm. Generally, an SDH/SONET network has an alarm threshold
> > that sets an
> > alarm off if adjustment is happenning that often. The alarm
> > threshold is
> > normally settable and can be set to not go off at 100 ppm,
> > but the usual
> > default would go off. The arguments I have heard against 100 ppm are:
> >
> > Since the SDH/SONET/OTN specs only require tolerance of 20 ppm,
> > implementations may not tolerate 100 ppm even though the
> > basic mechanism
> > does.
> >
> > 100 ppm will make alarms go off.
> >
> > Clock recovery cost for 20 ppm is cheaper than for 100 ppm
> > and 20 ppm clocks
> > cost the virtually the same as 100 ppm clocks. It is not
> > obvious to me why
> > this would be the case, but it is an assertion some people
> > are making. Those
> > who favor 100 ppm make the opposite assertion.
> >
> > Regards,
> > Pat
> >
> > -----Original Message-----
> > From: Christensen, Benny [mailto:benny.christensen@xxxxxxxxx]
> > Sent: Tuesday, May 08, 2001 1:04 AM
> > To: stds-802-3-hssg@xxxxxxxx
> > Subject: RE: 20 / 100 ppm
> >
> >
> >
> > Hi all
> >
> >
> > Just a comment on the 20 / 100 ppm clock accuracy discussion.
> >
> > As far as I recall from my mind, the 20 ppm (SDH/SONET) spec,
> > is due to the
> > limited amount of pointer justification. As I understand, the
> > SDH framer can
> >
> > only adjust +/-8 bit (a byte) pr. two frames (maximum) (the pointer
> > adjustment is indicated by inverting the even or odd bits of
> > the pointer,
> > giving a error prone majority decision), so this sets the
> > limitation on
> > maximum clock difference that the framer can handle before
> > experiencing a
> > buffer under/overrun.
> >
> > The situation for 10GE is a little different as one has the
> > idle characters
> > to insert or delete in order to account for a slight
> > difference in clock
> > frequencies. THis may be regarded as the equivalent to
> > pointer processing in
> > SDH framers.
> >
> > There is normally not any problems with the ref.clk at the RX side. At
> > least, the GIGA 10 Gb/s CDR devices have a 500 ppm (or 2000
> > ppm) auto-lock
> > range detection circuit, which ensures a reliable lock conditions.
> >
> > Experimentally, I found that the PLL acquisition/capture
> > range is up to
> > about 20 MHz. This is mainly set by the PLL bandwidth of the
> > CDR, which is
> > minimum 4 MHz (set by the jitter tolerance criteria). Even
> > when the closed
> > loop PLL gain drops to 0.1 (at 40 MHz frequency offset) there is still
> > sufficient gain to pull the VCO into lock.
> >
> >
> >
> > Benny
> > --------------------------------------------
> >   llllllll   ii     llllllll     llllll
> > ll                ll           ll      ll
> > ll    llll   ll   ll    llll   llllllllll
> > ll      ll   ll   ll      ll   ll      ll
> >   llllllll   ll     llllllll   ll      ll
> >
> > GIGA, an Intel company
> > Benny Christensen, M.Sc.E.E, Ph.D.
> > Mileparken 22, DK-2740 Skovlunde, Denmark
> > Tel: +45 7010 1062, Fax: +45 7010 1063
> > e-mail: benny.christensen@xxxxxxxxx, http://www.giga.dk
> >
> >
> >
> > > I have yet to see an explanation as to why a 100 PPM clock
> > > recovery system
> > > is more expensive than a 20 PPM clock recovery system.  If
> > > you use the
> > > argument set by the legacy SONET standards body, the
> > > receivers for 10GbE
> > > would be less expensive if the clock were specified at 20
> > > PPM.  I have yet
> > > to hear from any of the component vendors to support that
> > > argument.  All of
> > > the component vendors seem to believe that the SONET/SDH version is
> > > slightly higher in cost.
> > >
> >