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
