[ibis-macro] Re: clock_times .... yet again
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <scott@xxxxxxxxxxxxx>, <twesterh@xxxxxxxxxx>
- Date: Wed, 14 Apr 2010 17:27:33 -0400
Scott,
You are correct, ?clock period? was never defined, so lets define it. I
propose:
?Clock Period is defined as having the same value as the bit_time value
passed to the AMI_Init function as specified in section 3.1.1 on page 185 of
IBIS 5.0.?
I base this definition on the understanding that we had in May 2007 when the
wording was agreed to by two IC Vendors and at four interested EDA Tool
vendors, and by the number of AMI models that are currently being delivered
with this assumption, and the number of EDA Vendor tools that also make this
assumption. As you have most eloquently pointed out, any other definition of
Clock Period is wrought with introducing potential errors.
Walter
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 Scott McMorrow
Sent: Wednesday, April 14, 2010 4:48 PM
To: twesterh@xxxxxxxxxx
Cc: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: clock_times .... yet again
Todd
The problem currently exists that the current specification, and all known
implementations are at odds. The spec itself is quite ambiguous, since the
term "clock period" was never defined.
" The clock times are the times at which clock signal at the output of the
clock recovery loop crosses the logic threshold.It is to be assumed that the
input data signal is sampled at exactly one half clock period after a clock
time."
As such, it has been "assumed" to be the nominal UI period. However, if
that is the case, then it is impossible simultaneously for clock_times to
both be "the times at which the clock at the output of the clock recovery
loop crosses the logic threshold", and "that the input data signal is
sampled at exactly one half clock period after a clock time." If nominal UI
is added to the phase locked clock edge in the clock recovery loop, the
sample point will be wrong almost every time.
The other possible interpretation is that one half clock period refers to
the instantaneous clock period. This is, in fact, logically consistent, and
meets all specification requirements. Unfortunately, that was not the
interpretation that was chosen by early implementers. The solution that all
existing implementations have chosen to use violates the spec, by
calculating the actual input decision circuit sampling point, and from this
point a "synthetic" clock tick - that appears 1/2 the nominal UI before the
sample point - is what is output from the DLL in clock_times.
All implementations currently violate the specification. However, all
implementations are consistent in the way in which they violate the
specification, which is good. To correct this, I propose to amend the spec
to document the actual usage model. Once we accept this then the issue of
negative clock times occurs, since the CDR is not phase aligned with the
received waveform, until after acquisition. Now, we can argue about whether
this is helpful, useful, or practical, however, it is the logical outcome of
what has become the De-facto implementation standard.
As for your assumption about the CDR, it is probably based on a belief that
the only meaningful information to be gleaned from an AMI model is
processing of the waveform. Another area of interest to us are the dynamics
of the CDR itself. Since there is no requirement that the CDR be in lock to
output clock_times, it is, in fact, highly useful to perform stochastic
processing of the clock alone. If the CDR is modeled faithfully, we can use
the AMI interface to perform some extremely interesting performance and
failure mode studies. Being able to simulate the CDR from a time-zero
steady-state free-running condition, and not have to set this up by
initializing the simulation with excessively long run-length sequences,
would be extremely valuable in characterizing the CDR quickly. If I were
designing the CDR model, I might want to initialize it with a random
free-running frequency (within the bounds of it's operating characteristics
and reference clock), and a random phase relationship to the incoming
waveform stream. But hey, that's just me.
To answer your final question, I want AMI models to have the ability to send
back clock_times during startup, and when it goes out of lock. I also want
the ability to exclude the startup condition. It seems to me that
IgnoreBits can be used for both purposes, since it tells the simulator when
the CDR is locked and equalization adaptation algorithms have been trained.
But the simulator can optionally choose to observe waveforms and clocks
before this has occurred. Both methods are valuable tools.
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® is the registered service mark of
Teraspeed Consulting Group LLC
Todd Westerhoff wrote:
All,
I'm confused about the practical probability of having clock times
returned that are less than zero.
The clock times are always referenced to time zero in the simulation, are
they not?
Therefore, the ONLY symbol that could EVER return a clock time less than
zero would be the FIRST symbol in an entire simulation run. Correct?
I make the assumption that a model's CDR doesn't return clock times until
it has locked onto the incoming data. I just don't see how that is going
to happen on the first symbol. Ever.
Am I missing something? Or do other not share the assumption that the
model won't return clock data until the CDR is locked? I also assume that
the simulator will ignore all clock and waveform data less than the
IGNORE_BITS value.
Are these assumptions the discussion we should be having?
Thanks,
Todd.
________________________
Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@xxxxxxxxxx <mailto:twesterh@xxxxxxxxxx>
www.sisoft.com <http://www.sisoft.com>
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[ mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, April 14, 2010 11:35 AM
To: ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: clock_times .... yet again
To make this topic even more interesting, think
about the -1 used as the termination value for
the vector. We picked a negative number because
we thought time will always be >= 0. what if
someone makes a decision in an IF statement that
checks for >= 0, instead of = -1 to find the end
of the vector and the first time comes in as a
number that is between -0.5UI and 0?
Arpad
==================================================
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[ mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Wednesday, April 14, 2010 10:29 AM
To: msteinb@xxxxxxxxxx <mailto:msteinb@xxxxxxxxxx> ; Dmitriev-Zdorov,
Vladimir
Cc: ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-macro] Re: clock_times .... yet again
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>
[ 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 <mailto: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>
[ mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger
Sent: Wednesday, April 14, 2010 8:13 AM
To: scott@xxxxxxxxxxxxx <mailto:scott@xxxxxxxxxxxxx>
Cc: fangyi_rao@xxxxxxxxxxx <mailto:fangyi_rao@xxxxxxxxxxx> ;
ibis-macro@xxxxxxxxxxxxx <mailto: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 <mailto: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>
[ 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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto: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
Teraspeed® is the registered service mark of
Teraspeed Consulting Group LLC
Other related posts:
