[ibis-macro] Re: clock_times .... yet again
- From: "Dmitriev-Zdorov, Vladimir" <vladimir_dmitriev-zdorov@xxxxxxxxxx>
- To: "Mike Steinberger" <msteinb@xxxxxxxxxx>, "Scott McMorrow" <scott@xxxxxxxxxxxxx>
- Date: Wed, 14 Apr 2010 15:54:43 -0600
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
>
> Teraspeed(r) 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
Other related posts:
