[ibis-macro] Re: clock_times .... yet again
- From: "Dmitriev-Zdorov, Vladimir" <vladimir_dmitriev-zdorov@xxxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 14 Apr 2010 09:13:50 -0600
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
Other related posts:
