[ibis-macro] Re: clock_times .... yet again
- From: "Dmitriev-Zdorov, Vladimir" <vladimir_dmitriev-zdorov@xxxxxxxxxx>
- To: <fangyi_rao@xxxxxxxxxxx>, <msteinb@xxxxxxxxxx>, <scott@xxxxxxxxxxxxx>
- Date: Wed, 14 Apr 2010 19:36:40 -0600
Let's think about the following. We know that clock times can be easily
transformed into sample times. Assume that the distance between adjacent sample
times is smaller or larger than 1UI, for example, it is 0.8UI or 1.2UI. Also
imagine that waveform (between sample points) may cross the threshold not in
the middle, but with some 'jitter' of about certain 15ps rms (for now, we don't
care about the origin of this jitter). How do you think, this type of jitter -
with the same extected absolute rms - is more dangerous when the distance
between adjacent sampling points is 0.8UI or 1.2UI? It seems the risk of
inaccurate sample is higher when sampling points are closer. This should affect
BER. What about the approach we have?
________________________________
From: fangyi_rao@xxxxxxxxxxx [mailto:fangyi_rao@xxxxxxxxxxx]
Sent: Wed 4/14/2010 3:23 PM
To: Dmitriev-Zdorov, Vladimir; msteinb@xxxxxxxxxx; scott@xxxxxxxxxxxxx
Cc: twesterh@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: clock_times .... yet again
Hi, Vladimir;
Thanks for correctly pointing out the waveform overlapping problem in
peak-peak (p-p) jitter measurement which I overlooked previously. I'd
like to share my view of the situation and comments are welcome: To
rigorously measure peak-peak jitter you need to use uniform sample times
when constructing the eye. With uniform sample time you will have to
throw away the effect of sampling variation/jitter on BER. Between p-p
jitter and BER, I will choose BER and make sure it is correctly
calculated because it's more critical in high speed designs.
Regards,
Fangyi
-----Original Message-----
From: Dmitriev-Zdorov, Vladimir
[mailto:vladimir_dmitriev-zdorov@xxxxxxxxxx]
Sent: Wednesday, April 14, 2010 2:55 PM
To: Mike Steinberger; Scott McMorrow
Cc: Todd Westerhoff; RAO,FANGYI (A-USA,ex1); ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: clock_times .... yet again
Yes, perhaps we are interested in how much the difference T(n) - T(n-1)
could be different from nominal UI. I checked one of our 'good behaving'
Rx DLLs and found this to be about 2% on 1e6 bits. But, at higher rate
this number is at 4%. And finally we need to talk about probabilities at
or below 1e-12 otherwise we'll get the correct simulation results only
when the jitter is small.
I'm surprised that we need to prove that this issue is important. Should
it be instead the other way: can the implementers prove that this issue
is always insignificant?
-----Original Message-----
From: Mike Steinberger [mailto:msteinb@xxxxxxxxxx]
Sent: Wednesday, April 14, 2010 3:41 PM
To: Scott McMorrow
Cc: Todd Westerhoff; Dmitriev-Zdorov, Vladimir; fangyi_rao@xxxxxxxxxxx;
ibis-macro@xxxxxxxxxxxxx
Subject: Re: [ibis-macro] Re: clock_times .... yet again
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 <http://www.teraspeed.com/>
>
> Teraspeed(r) is the registered service mark of
> Teraspeed Consulting Group LLC
>
Other related posts:
