[ibis-macro] Re: clock_times .... yet again
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: <msteinb@xxxxxxxxxx>, "Dmitriev-Zdorov, Vladimir" <vladimir_dmitriev-zdorov@xxxxxxxxxx>
- Date: Wed, 14 Apr 2010 08:28:52 -0700
If that is the case, the spec should state that...
The point is that if we don't say it, people are
not going to know what to do with themselves when
they see a negative time number...
Arpad
===================================================
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger
Sent: Wednesday, April 14, 2010 10:25 AM
To: Dmitriev-Zdorov, Vladimir
Cc: ibis-macro@xxxxxxxxxxxxx
Subject: [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
---------------------------------------------------------------------
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:
