Mike
Alright, you're quite correct about gaussian noise, except from the ref
clock, however, Bang-Bang CDR's are not quite as simple as you make
them out to be. In operation a bang-bang CDR can have some fairly high
jitter due to loop response time. 0.25 UI pp in this case with a PRBS7
and SJ.
Mike Steinberger wrote:
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:
Mike
We'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:
Mike
For 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 Steinberger
Cc: fangyi_rao@xxxxxxxxxxx; scott@xxxxxxxxxxxxx;
ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: clock_times .... yet again
Mike,
I question the practical
relevance of your concern about missing or
duplicated waveform points at the edge of an eye diagram.
Perhaps the brief answer is that superimposing disconnected or
overlapped waveform pieces may cause distortions of the jitter PDF that
accumulates at eye edges. I'm not ready to discuss the numbers but the
approach 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 PM
To: 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
has
been
"the standard way of building the
eye histogram from Rx output is not
defined in details and could be implementation specific"
I 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?
Mike S.
Dmitriev-Zdorov, Vladimir wrote:
Mike,
We are talking about different things. My point was that the spec
should
be definite enough about what is
a correct meaning and usage of clock
times.
You are saying that since you do a specific type of simulation
successfully, there is no reason to worry about the accurate
definition.
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 to
formally define the standard way of doing this or remain silent on
this
point thus leaving the
possibility that the result is implementation
dependent?
The best I can figure out from the spec and our discussion so far is
this:
"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 the
histogram if the clock times are non equidistant"
or
"the standard way of building the eye histogram from Rx output is not
defined in details and could be implementation specific"
Vladimir
-----Original Message-----
From: Mike Steinberger [mailto:msteinb@xxxxxxxxxx] Sent: Wednesday,
April 14, 2010 11:35 AM
To: 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 want
to
consider the case of an odd/even
receiver architecture. As you well know, the IBIS AMI API is based on
the assumption that there is a
single
data path, and yet we routinely
and successfully use IBIS AMI to model
receivers that have two or four
data paths. In such cases, the
waveform
in 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 built
up
from segments of waveform that
come from different parts of the
circuit
altogether.
This all reproduces measured data quite well, so long as the switch in
waveform 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 waveform
in
your 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
--
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
|