Scott-Please consider that most CDR loops generate their output using a phase selector driven by a reference clock, usually through a PLL. The phase selector moves by at most one phase step in a clock cycle. Thus, the period of an individual clock cycle at the output of the CDR loop can vary by at most one phase step from the period of the reference clock. The period of the reference clock itself has a Guassian variation; however, other than that small effect, the period varies exactly between nominal reference clock period, reference clock period plus one phase step, and reference clock period minus one phase step. The circuit design allows no other possibilities.
So the bottom line is that the period of an individual clock cycle at the output of a CDR loop can only vary by one phase step plus a variation in the reference clock period. For most designs, that's a lot less than the variation you've described, much smaller than the sample interval used in most simulations, and too small to significantly affect the performance estimate.
Mike S. Scott McMorrow wrote:
MikeWe're speaking of the same thing. My numbers are in substantial agreement with Vladimir's. If you measure a CDR you will find that the jitter distribution is Gaussian.Scott Mike Steinberger wrote:Scott-You're still addressing the jitter distribution rather than the period of an individual clock cycle. Vladimir's data was more to the point and is in general agreement with the information I have.You should also know that the PDF of an individual clock cycle at the output of most CDR loops does not resemble a Gaussian at all, except in the sense that there is a very small amount of Gaussian phase that comes from the reference clock. Think about the actual circuit design of most CDR loops and you'll see what I mean.Mike S. Scott McMorrow wrote:MikeFor a well-designed CDR the jitter distribution is gaussian with a 0.007 to 0.01 UI sigma. This is +/- 0.05 UI over a 10-12 confidence interval. Over 10+12 bits you will see a minimum period of .95 UI and a maximum period of 1.05 UI. On top of this other deterministic jitter components will be convolved.Scott Mike Steinberger wrote:Scott-You've addressed peak to peak jitter, but that's not the question at hand. Peak to peak jitter is the total deviation of a clock with respect to some reference clock. That deviation is typically built up over a number of clock cycles, however, and does not address the period of an individual clock cycle with respect to the reference clock period. What you've been focusing on is the time between a clock tick value and the time the data is actually sampled. That's affected by the period of the individual clock cycle and not some deviation built up over many clock cycles.Can you please give us a probability density function for the period of an individual clock cycle with respect to the reference clock period?Thanks. Mike S. Scott McMorrow wrote:Todd,pk-pk jitter for good CDRs is designed to be around +/- 0.05 UI at a 10^-12 confidence interval. Deterministic jitter transfer and multiplication in the CDR loop will be added on top of this. CDR jitter can easily approach +/- 0.1 UI at a 10^-12 confidence interval under stress testing.+/-10% is a reasonable number. Shortest period is 0.9 UI. Longest period is 1.1 UI.Scott Todd Westerhoff wrote:Vladimir, What is the magnitude of the effect you're talking about? Todd. ________________________ Todd Westerhoff VP, Software Products SiSoft 6 Clock Tower Place, Suite 250 Maynard, MA 01754 (978) 461-0449 x24 twesterh@xxxxxxxxxx www.sisoft.com -----Original Message----- From: ibis-macro-bounce@xxxxxxxxxxxxx[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Dmitriev-Zdorov,Vladimir Sent: Wednesday, April 14, 2010 4:06 PM To: Mike SteinbergerCc: fangyi_rao@xxxxxxxxxxx; scott@xxxxxxxxxxxxx; ibis-macro@xxxxxxxxxxxxxSubject: [ibis-macro] Re: clock_times .... yet again Mike,I question the practical relevance of your concern about missing orduplicated waveform points at the edge of an eye diagram. Perhaps the brief answer is that superimposing disconnected oroverlapped waveform pieces may cause distortions of the jitter PDF that accumulates at eye edges. I'm not ready to discuss the numbers but theapproach does not seem technically clean. In particular, it cannot correctly account for peak to peak jitter. Vladimir -----Original Message-----From: Mike Steinberger [mailto:msteinb@xxxxxxxxxx] Sent: Wednesday, April 14, 2010 1:51 PMTo: Dmitriev-Zdorov, Vladimir Cc: fangyi_rao@xxxxxxxxxxx; scott@xxxxxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx Subject: Re: [ibis-macro] Re: clock_times .... yet again Vladimir-The short answer is that your second statement is correct and always hasbeen"the standard way of building the eye histogram from Rx output is notI question the practical relevance of your concern about missing or duplicated waveform points at the edge of an eye diagram. It is certainly mathematically possible that there could be missing or duplicated waveform samples at the edge of an eye diagram. When this happens, how will it affect the results of the analysis? And if it doesn't affect the results of the analysis, is it worth discussing?defined in details and could be implementation specific"Mike S. Dmitriev-Zdorov, Vladimir wrote:Mike, We are talking about different things. My point was that the specshouldbe definite enough about what is a correct meaning and usage of clocktimes. You are saying that since you do a specific type of simulation successfully, there is no reason to worry about the accuratedefinition.Or did I take it wrong?Any abstract EDA tool gets a long waveform and clock times output from Rx DLL. This is to be used to create eye "histograms". Do we need toformally define the standard way of doing this or remain silent onthispoint thus leaving the possibility that the result is implementationdependent?The best I can figure out from the spec and our discussion so far isthis: "EDA tool will use the portion of the waveform from tick_time_N to(tick_time_N+1UI) to fill the eye histogram. It is allowed that some portions of the Rx output waveform will be duplicated or missed in thehistogram if the clock times are non equidistant" or"the standard way of building the eye histogram from Rx output is notdefined in details and could be implementation specific" Vladimir -----Original Message-----From: Mike Steinberger [mailto:msteinb@xxxxxxxxxx] Sent: Wednesday, April 14, 2010 11:35 AMTo: Dmitriev-Zdorov, Vladimir Cc: fangyi_rao@xxxxxxxxxxx; scott@xxxxxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx Subject: Re: [ibis-macro] Re: clock_times .... yet again Vladimir-If you want to worry about missing or duplicated data, you might wanttoconsider the case of an odd/even receiver architecture. As you well know, the IBIS AMI API is based on the assumption that there is asingledata path, and yet we routinely and successfully use IBIS AMI to modelreceivers that have two or four data paths. In such cases, thewaveformin each data interval is the waveform at the decision circuit whose decision is actually going to be used for that data bit. Thus, the receiver model output waveform and the resulting eye diagram is builtupfrom segments of waveform that come from different parts of thecircuitaltogether.This all reproduces measured data quite well, so long as the switch inwaveform segments always occurs at the edge of the eye. Mike S. Dmitriev-Zdorov, Vladimir wrote:But here is a minor technical problem: if you do this way, and the clock times are not equidistant, then some portions of the waveforminyour histogram are counted twice and some could be missing. This is another Pandora box: what's a definition of an eye histogram built from waveform and non-equidistant clock times?Vladimir---------------------------------------------------------------------IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/ IBIS Macro reflector: //www.freelists.org/list/ibis-macro To unsubscribe send an email: To: ibis-macro-request@xxxxxxxxxxxxx Subject: unsubscribe-- Scott McMorrow Teraspeed Consulting Group LLC 121 North River Drive Narragansett, RI 02882 (401) 284-1827 Business (401) 284-1840 Fax http://www.teraspeed.com Teraspeed® is the registered service mark of Teraspeed Consulting Group LLC
--------------------------------------------------------------------- IBIS Macro website : http://www.eda.org/pub/ibis/macromodel_wip/ IBIS Macro reflector: //www.freelists.org/list/ibis-macro To unsubscribe send an email: To: ibis-macro-request@xxxxxxxxxxxxx Subject: unsubscribe