[ibis-macro] Re: Clock Times - The FINAL WORD
- From: <fangyi_rao@xxxxxxxxxxx>
- To: <wkatz@xxxxxxxxxx>, <vladimir_dmitriev-zdorov@xxxxxxxxxx>, <msteinb@xxxxxxxxxx>, <scott@xxxxxxxxxxxxx>
- Date: Thu, 15 Apr 2010 16:47:04 -0600
Scott and Walter;
Thanks for your effort of clarifying the clock tick definition.
Fangyi
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Thursday, April 15, 2010 10:11 AM
To: RAO,FANGYI (A-USA,ex1); vladimir_dmitriev-zdorov@xxxxxxxxxx;
msteinb@xxxxxxxxxx; scott@xxxxxxxxxxxxx
Cc: twesterh@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: Clock Times - The FINAL WORD
Fangyi, Vladimir, Mike, Scott, Todd, etal...
Scott and I agreed to a change to clarify that the clock ticks returned
from Rx GetWave are defined as the time of the decision point in CDR
minus bit_time/2. Where bit_time is passed as a constant to the DLL in
the AMI_Init call. This was the original intent of the authors of AMI,
and has been the practice used in developing AMI models. The words
"clock period" will no longer be in the AMI specification, and therefore
will no longer need a definition. I believe that this clarification
removes all ambiguities on exactly what the model needs to return in
both the waveform and clock times array.
I will remind everyone of an e-mail ("An AMI Overview") that I sent to
this reflector on October 10, 2009. It concluded:
"A fundamental principle of AMI modeling is that every EDA platform
(both software and hardware) will give the same results when presented
with the same Analog-Channel impulse response, the same AMI model
conditions, and the same input stimulus pattern. Each EDA platform may
differ on how its sets the Tx and Rx AMI model conditions, the stimulus
pattern, how it creates the Analog-Channel impulse response, and how it
processes the resulting outputs."
This statement has been made repeatedly and discussed repeatedly. I am
under the assumption that this is also agreed to be most, if not all,
members on this committee and within IBIS in general. If anyone does
object to this statement they should come forward now, or forever hold
their peace! So far, the standard has meticulously avoided any
statements on how EDA tools shall process the resulting output, other
then how the output of the Tx model needs to be passed to the input of
the Rx model.
Walter Katz
303.449-2308
Mobile 720.333-1107
wkatz@xxxxxxxxxx
www.sisoft.com
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]On Behalf Of
fangyi_rao@xxxxxxxxxxx
Sent: Thursday, April 15, 2010 12:21 PM
To: vladimir_dmitriev-zdorov@xxxxxxxxxx; msteinb@xxxxxxxxxx;
scott@xxxxxxxxxxxxx
Cc: twesterh@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: clock_times .... yet again
Hi, Vladimir;
I am not sure I fully understand your statement, but I guess your idea
is that the "risk of error" is higher when two consecutive sample points
are closer than when they are further. Intuitively this makes sense.
Note that the situation involves two consecutive events. It can't be
described by BER which is the probability of a single event. To describe
this type of risk we need probability of two events. We need to define
the probability of the second event given the first event happening at
certain prior time. Something similar to the two-point correlation
function.
Fangyi
From: Dmitriev-Zdorov, Vladimir
[mailto:vladimir_dmitriev-zdorov@xxxxxxxxxx]
Sent: Wednesday, April 14, 2010 6:37 PM
To: RAO,FANGYI (A-USA,ex1); msteinb@xxxxxxxxxx; scott@xxxxxxxxxxxxx
Cc: twesterh@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: clock_times .... yet again
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:
