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: >> //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: >> //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 >> >> >> >> >> > > > -- Steve Weir Teraspeed Consulting Group LLC 121 North River Drive Narragansett, RI 02882 California office (866) 675-4630 Business (707) 780-1951 Fax Main office (401) 284-1827 Business (401) 284-1840 Fax Oregon office (503) 430-1065 Business (503) 430-1285 Fax http://www.teraspeed.com This e-mail contains proprietary and confidential intellectual property of Teraspeed Consulting Group LLC ------------------------------------------------------------------------------------------------------ Teraspeed(R) is the registered service mark of Teraspeed Consulting Group LLC ------------------------------------------------------------------ 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: //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: //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