[SI-LIST] Re: Majic Fbaud/1667 for CDR bandwidth

Is it really the responsibility of the outer PLL loop or the fast response 
inner phase interpolator to adjust for your symbol change ?

-----Original Message-----
From: si-list-bounce@xxxxxxxxxxxxx
[mailto:si-list-bounce@xxxxxxxxxxxxx]On Behalf Of Vinu Arumugham
Sent: Tuesday, September 16, 2008 4:13 PM
To: steve weir
Cc: Steve Waldstein; si-list@xxxxxxxxxxxxx
Subject: [SI-LIST] Re: Majic Fbaud/1667 for CDR bandwidth


 
Steve,

I am referring to "phase jumps" created by XAUI CJPAT like patterns on
an interconnect with resonance. Standards like CEI recommend
coding/scrambling schemes to reduce the probability of such patterns.

Imagine a horizontal line through the middle of the eye.
C----R-c---r----C

R-C is the eye opening with random patterns.
C-C is the eye opening for a clock pattern (low ISI, wide opening but
offset from R-C because of resonance)
c is the optimal sampling position for the clock pattern
r is the optimal sampling position for the random pattern

Tracking speed affects the number of bit times needed to move from r to
c. A "lone pulse" after a clock like pattern can cause a failure because
the CDR does not have enough transitions/time to get back from c to r.

For an interconnect without resonance:
C---R---r---R---C
R-R is the eye opening with random patterns.
r is the optimal sampling position for all patterns.

Thanks,
Vinu

steve weir wrote:
> Vinu that premise sounds questionable to me.  I think any  resonance
> that causes substantial movement in the timing estimate must by
> definition move the associated data.  As long as the PLL is properly
> damped ( many are not ) the wide bandwidth loop should track much
> better and exhibit a lower error rate than a norow loop.
>
> Steve
> Vinu Arumugham wrote:
>> Steve,
>> Regarding, "generally in a CDR scheme we want to track at as high a
>> rate as we can.", there is at least one situation where tracking at a
>> high rate can degrade performance.
>> When an interconnect has a resonance that causes pattern dependent
>> prop. delay variations, a clock like pattern can drag the sampling
>> point away from the middle of the eye. When the data pattern changes
>> back to random, one can encounter errors. With fast tracking one
>> would need shorter clock-like sequences to   trigger this failure.
>> With a scrambled data stream and a CDR that only reacts to long
>> clock-like sequences, the probability of such errors can be reduced
>> below the BER of interest.
>>
>> Thanks,
>> Vinu
>>
>> steve weir wrote:
>>> Steve, generally in a CDR scheme we want to track at as high a rate
>>> as we can.  We can dump the results into an elastic store and then
>>> use a second PLL with a lower rate to smooth out the bumps for
>>> reading out the elastic store and/or forwarding.
>>>
>>> I don't know why XAUI has such a tall ratio.  Either there is some
>>> break in the 8b/10b pattern possible, or it seems to be about 50
>>> times taller than it needs to.
>>>
>>> Steve.
>>> Steve Waldstein wrote:
>>>
>>>> Steve,
>>>>
>>>> Thanks for your answer but I'm still a little perplexed. In a PLL
>>>> the loop
>>>> bandwidth typically wants to be about a factor of 10 lower than the
>>>> transition density in the reference clock to the PDF. But pushing the
>>>> bandwidth lower will allow a noiser (more jitter) reference clock
>>>> at the
>>>> expense of seeing increased VCO jitter. The opposite it true where
>>>> you use a
>>>> higher loop bandwidth to clean up the VCO but you suffer from clock
>>>> noise
>>>> passing through the loop bandwidth that causes output jitter.
>>>>
>>>> I'm sure there is a similar analogy for the CDR. A lower loop
>>>> bandwidth
>>>> should produce a cleaner recovered clock but makes the loop less
>>>> agile to
>>>> data changes. A higher loop bandwidth makes the loop more agile but
>>>> produces
>>>> more jitter on the output.
>>>> Lets use an example for discussion. XAUI has Fbaud = 3.125 Gb/s and
>>>> 8b/10b
>>>> (or 10Q) encoded. Yet its corner frequency is set at 3.215/1667 =
>>>> 1.87 MHz.
>>>> Is this because XAUI want to recover a clock and recreate it to
>>>> some kind of
>>>> PPM accuracy similar its input spec of +/- 100 PPM? I know SONET had
>>>> repeaters in it where the clock recreation was important but on
>>>> most serial
>>>> links that's not the case. So since you said Fbaud/30 was typically
>>>> sufficient to recover the day why burden the receiver with such a
>>>> narrow
>>>> loop bandwidth?
>>>> Is it really related to the fact that at +/- 100 PPM one skip is
>>>> inserted
>>>> every 5000 symbols so the 1667 provides margin to this by a factor
>>>> of 3?
>>>>
>>>> I've also seen calculation that predict the jitter of a sinusoidal
>>>> modulation of the carrier that relate to the equivalent PPM. It the
>>>> corner
>>>> really set to handle this type of issue? And not ability to recover
>>>> the
>>>> data?
>>>>
>>>> I know these are a lot of questions but your answer doesn't help
>>>> understand
>>>> why these standards have chosen such a low loop bandwitch.
>>>>
>>>> Steve W.
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: si-list-bounce@xxxxxxxxxxxxx
>>>> [mailto:si-list-bounce@xxxxxxxxxxxxx] On
>>>> Behalf Of steve weir
>>>> Sent: Sunday, September 14, 2008 10:38 PM
>>>> To: Steve Waldstein
>>>> Cc: si-list@xxxxxxxxxxxxx
>>>> Subject: [SI-LIST] Re: Majic Fbaud/1667 for CDR bandwidth
>>>>
>>>> Steve the loop B/W has to do with:
>>>>
>>>> The available repetitive data rate.
>>>> Reasonable phase / gain margin for the loop filter.
>>>>
>>>> Each of the various data transmission standards are different in
>>>> the way that they can mess up a CDR, with the net result that many
>>>> standards need very tall ratios between Fbaud and Fcorner.
>>>> Basically, you can easily achieve very stable operation by setting
>>>> Fcorner = Frepeat / 5.  With some care you can set it to Frepeat /
>>>> 3, where Frepeat is the guaranteed lowest repetitive full 1-0
>>>> cycle.  For a pure 8B/10Q coded link, Fcorner can be as high as
>>>> Fbaud / 30 and work well.
>>>> As Chris Cheng has bemoaned, TIE and jitter in general both get
>>>> worse with taller ratios as the VCO drifts ( or is disturbed by
>>>> things like PDN noise ) over more bit intervals without the benefit
>>>> of corrective feedback.
>>>>
>>>> Steve.
>>>>
>>>> Steve Waldstein wrote:
>>>>
>>>>> I know many serial specifications place the corner frequency of a
>>>>> CDR at
>>>>> Fbaud/1667. I also know that the FC-MJSQ discusses how this was
>>>>> shifted
>>>>>
>>>> from
>>>>
>>>>> the Fbaud/2500 established for SONET. What I can't find is a good
>>>>>
>>>> discussion
>>>>
>>>>> on how to set CDR loop bandwidth for new serial specification. It
>>>>> appears
>>>>> there's some relation the desired frequency accuracy or ppm but
>>>>> haven't
>>>>> found a good derivation.  Can anyone provide a good reference
>>>>> relating to
>>>>> choosing loop bandwidth based on desired output jitter or what
>>>>> ever else
>>>>> helps set this corner frequency.
>>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>>
>>>>>
>>>>> Steve
>>>>>
>>>>> __________________________________
>>>>>
>>>>> Steve Waldstein
>>>>>
>>>>> E-mail: swldstn@xxxxxxxxx
>>>>>
>>>>> Mobile: (207) 749-6260
>>>>>
>>>>> Home:  (207) 885-0594
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------
>>>>> To unsubscribe from si-list:
>>>>> si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject
field
>>>>>
>>>>> or to administer your membership from a web page, go to:
>>>>> http://www.freelists.org/webpage/si-list
>>>>>
>>>>> For help:
>>>>> si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field
>>>>>
>>>>>
>>>>> List technical documents are available at:
>>>>>                 http://www.si-list.net
>>>>>
>>>>> List archives are viewable at:
>>>>> http://www.freelists.org/archives/si-list
>>>>> or at our remote archives:
>>>>>         http://groups.yahoo.com/group/si-list/messages
>>>>> Old (prior to June 6, 2001) list archives are viewable at:
>>>>>          http://www.qsl.net/wb6tpu
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>
>

------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field

or to administer your membership from a web page, go to:
http://www.freelists.org/webpage/si-list

For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field


List technical documents are available at:
                http://www.si-list.net

List archives are viewable at:
                http://www.freelists.org/archives/si-list
or at our remote archives:
                http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
                http://www.qsl.net/wb6tpu




This email and any attachments thereto may contain private, confidential, and 
privileged material for the sole use of the intended recipient. Any review, 
copying, or distribution of this email (or any attachments) by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender immediately and permanently delete the original and any copies of this 
email and any attachments thereto.
------------------------------------------------------------------
To unsubscribe from si-list:
si-list-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field

or to administer your membership from a web page, go to:
http://www.freelists.org/webpage/si-list

For help:
si-list-request@xxxxxxxxxxxxx with 'help' in the Subject field


List technical documents are available at:
                http://www.si-list.net

List archives are viewable at:     
                http://www.freelists.org/archives/si-list
or at our remote archives:
                http://groups.yahoo.com/group/si-list/messages
Old (prior to June 6, 2001) list archives are viewable at:
                http://www.qsl.net/wb6tpu

Other related posts: