[ibis-macro] Re: clock_times .... yet again

  • From: Scott McMorrow <scott@xxxxxxxxxxxxx>
  • To: twesterh@xxxxxxxxxx
  • Date: Wed, 14 Apr 2010 16:47:48 -0400

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
www.sisoft.com

-----Original Message-----
From: 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
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] On Behalf Of Muranyi, Arpad
Sent: Wednesday, April 14, 2010 10:29 AM
To: msteinb@xxxxxxxxxx; Dmitriev-Zdorov, Vladimir
Cc: 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] 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

---------------------------------------------------------------------
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




--
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:

  1. Home
  2. ibis-macro
  3. Archive
  4. 04-2010