[ibis-macro] Re: clock_times .... yet again
- From: "Dmitriev-Zdorov, Vladimir" <vladimir_dmitriev-zdorov@xxxxxxxxxx>
- To: "Mike Steinberger" <msteinb@xxxxxxxxxx>
- Date: Wed, 14 Apr 2010 09:31:39 -0600
Mike,
As I see you understand the logical problem, but appeal to 'no practical
significance'.
My suggestion is honestly explain this in the spec to avoid
misunderstanding.
Vladimir
-----Original Message-----
From: Mike Steinberger [mailto:msteinb@xxxxxxxxxx]
Sent: Wednesday, April 14, 2010 9:25 AM
To: Dmitriev-Zdorov, Vladimir
Cc: ibis-macro@xxxxxxxxxxxxx
Subject: Re: [ibis-macro] Re: clock_times .... yet again
Vladimir-
You put your finger at the center of the problem when you said
> If we decide that starting from zero is of great practical importance
I assert that starting a simulation from zero with a fraction of a
symbol, with the expectation that any useful performance information can
be derived from that fraction of a symbol, has no practical significance
whatsoever. I invite anyone to present numerical data from a practical
problem that proves me wrong.
Mike S.
Dmitriev-Zdorov, Vladimir wrote:
> Mike,
>
> The purpose of the spec is to provide unambiguous definition of what
the
> clock times are and how they should be used to process the eye. Not
only
> this is needed for existing EDA and IC vendors who already support AMI
> models of create them, but also for those who will.
>
> In defining the meaning of the clock times we discussed two
incompatible
> cases:
>
> - clock times indicate where clock signal at the output of the clock
> recovery loop crosses the logic threshold
> - clock times are effective sample times minus 0.5 nominal UI
>
> It appears that previous spec included both above statements and
> therefore was misleading. Yesterday we decided that we'll follow the
> second definition and therefore the first statement should be excluded
> or modified.
>
> Now, it appears that the requirement that clock times start from
> non-negative number (another statement in the spec) necessitates that
> the first effective sample point (as well as others) is larger than
0.5
> nominal UI that does not make sense. With probability 0.5 this is
wrong.
>
> You are asking about numbers to prove that this conflict is not
> significant. Here is the number: in half of possible cases the
statement
> does not agree with physics. I agree that in any practical case we
have
> hundred of ways to avoid the conflict. But when it comes to
> specification, we need logical consistency. Anything that causes
> questions like this should be clarified.
>
> If we decide that starting from zero is of great practical importance
> and since we understand the problem, let's honestly state:
>
> - from above definition (for clock times) and the fact that effective
> sample point may occur anywhere at time>=0, it follows that the first
> clock time is >= -0.5 UI (nominal). However, for convenience of
> implementation, we decided that we'll always start this value from
> non-negative number.
>
> Vladimir
>
>
>
> -----Original Message-----
> From: ibis-macro-bounce@xxxxxxxxxxxxx
> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger
> Sent: Wednesday, April 14, 2010 8:13 AM
> To: scott@xxxxxxxxxxxxx
> Cc: fangyi_rao@xxxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
> Subject: [ibis-macro] Re: clock_times .... yet again
>
> Scott-
>
> I agree with Fangyi. In my opinion, you're attempting to make
> distinctions that at best have no practical significance. Such
> distinctions do not serve the needs of the users of this standard. If
> you think these distinctions have practical significance, then I
suggest
>
> you start by presenting concrete data that demonstrates their
> significance.
>
> Mike S.
>
> Scott McMorrow wrote:
>
>> Fangyi,
>>
>> This problem occurs because of the definition in the specification
>> agreed upon by the the committee, and those who have already
>> implemented the standard. This is not my problem, this is a
>> consequence of a poorly thought out specification. There would have
>> been no issues if the true instantaneous UI were used, instead of a
>> contrived nominal UI, or if the sample point were returned, instead
of
>>
>
>
>> the clock times. Since the committee has chosen a less rigorous
>> approach, the consequence is the possibility of calculating a clock
>> time that is less than zero. The corrected sample point will still be
>> greater than zero.
>>
>> Maybe the specification should require that the calculated sample
>> point be greater than zero. That is in line with the specification
and
>>
>
>
>> does not require a special case either in the EDA platform or AMI
>> model to process.
>>
>> regards
>>
>> Scott
>>
>>
>> fangyi_rao@xxxxxxxxxxx wrote:
>>
>>> Hi, Scott;
>>>
>>> For each tick, EDA tools will use waveform from (tick_time-UI/2) to
>>> (tick_time+UI/2) to fill the eye histogram. If tick_time < UI/2, a
>>> portion of the waveform does not even exist. Ignore_Bits can be used
>>> to deal with the situation you described, or the model can choose to
>>> not return the first few ticks (missing ticks).
>>>
>>> Let's make the clock tick definition simple: clock tick is used for
>>> AMI models to instruct EDA tools where to center the eye. This is
all
>>>
>
>
>>> what EDA tools care about.
>>>
>>> Regards,
>>>
>>> Fangyi
>>>
>>> *From:* ibis-macro-bounce@xxxxxxxxxxxxx
>>> [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] *On Behalf Of *Scott
>>>
> McMorrow
>
>>> *Sent:* Tuesday, April 13, 2010 5:08 PM
>>> *To:* IBIS-ATM
>>> *Subject:* [ibis-macro] clock_times .... yet again
>>>
>>> Fellow AMI travelers
>>>
>>> In the specification for clock_times is the statement:
>>>
>>> "The clock times are referenced to the start of the simulation (the
>>> first AMI_GetWave call). *The time is always
>>> greater or equal to zero.*"
>>>
>>> According to the discussion today, it has been agreed that all known
>>> implementations of AMI dlls calculate the correct sample time and
>>> then calculate clock_times as sample_times minus 1/2 the nominal
>>> clock period. If this is truly the case, then there is a problem.
>>>
>>> During startup the CDR is free-running, with no defined phase
>>> relationship to the received data. In order to model this, the
period
>>>
>
>
>>> of the CDR would be set to it's free-running period, and the phase
of
>>>
>
>
>>> the CDR would need to be randomly initialized at INIT. The location
>>> of the receiver sample point is then random within the first UI data
>>> window, as it is in reality. No matter what the Tx does, there will
>>> generally be a free-running sample occuring with no phase
>>> relationship to anything, until the first received differential
>>> transition occurs. If the first value of clock_times is calculated
as
>>>
>
>
>>> receiver sample time minus 1/2 the nominal clock period, then
>>> clock_times can take any value from -0.5 UI to +0.5 UI.
>>>
>>> The specification should be clarified to state that:
>>>
>>> The clock times are referenced to the start of the simulation (the
>>> first AMI_GetWave call). *The time is always
>>> greater or equal to -0.5 nominal clock periods or symbol UI.*"
>>>
>>>
>>> best regards,
>>>
>>> Scott
>>>
>>>
>>> --
>>> 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
>>>
>> --
>> 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
>
> ---------------------------------------------------------------------
> 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
>
>
---------------------------------------------------------------------
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:
