Todd,
We saw that after one call (with say 1,000 bits apiece) we've got 1000
meaningful clock times, where the last value was approximately tx =
999*Tbit. Then, after the next call we had 999 increasingly larger clock
times, but the 999-th remained unmodified in memory, so that the
expected should be about 1,000*T-bits larger. No terminating '-1'.
Technically, it is easy to detect non-monotonic behavior and stop
reading the clocks, but this is not expected. With such output, the
available interpretations are: bug in the DLL or CDR failure, or both.
My suggestion would be to always have the # or meaningful clock time
equal to the number of bits simulated with GetWave() call (or not having
them at all), otherwise, the flow becomes ambiguous and quite difficult
to follow. In some earlier discussions it was also allowed to have the
n+1-th clock time repeated as the first value in the output of the new
GetWave call. This would lead to another non-strict monotonic behavior.
How the tool would recognize if the last clock time is to be repeated or
GetWave simply produces more clock times than bits simulated in this
particular call?
Syntax is not enough, as was mostly the case with previous IBIS
standards. In the past, IBIS file containing the model description did
not "algorithmically" interact with EDA tools, but AMI models do. This
requires more detailed definition for the correct flow. Not only the
model/software should not crash, but we all should know what is expected
content of input/output to produce meaningful results.
Vladimir
-----Original Message-----
From: Todd Westerhoff [mailto:twesterh@xxxxxxxxxx]
Sent: Monday, March 29, 2010 11:32 AM
To: Dmitriev-Zdorov, Vladimir
Cc: scott@xxxxxxxxxxxxx; Mike Steinberger; wkatz@xxxxxxxxxx; Muranyi,
Arpad; ibis-macro@xxxxxxxxxxxxx
Subject: Re: [ibis-macro] Re: FW: Question on clock_times
Vladimir,
What do you mean by monotonicity issues with clock ticks? Do you the
values of time don't continue to increase?
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
On Mar 29, 2010, at 10:07 AM, "Dmitriev-Zdorov, Vladimir"
<vladimir_dmitriev-zdorov@xxxxxxxxxx
> wrote:
As a matter of fact, more than half of all AMI models that we have
seen
so far had more or less serious issues with clock ticks - way of
generation, consistency, monotonocity, unnecessary granulation making
them multiples of sample interval, etc.
This is an indication that we need to better specify what is the right
unambiguous behavior, not just syntaxically correct but the one that
allows model creator to reach their simulation goal provided that they
(and EDA tool) comply with the standard
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Scott McMorrow
Sent: Monday, March 29, 2010 10:44 AM
To: Mike Steinberger
Cc: wkatz@xxxxxxxxxx; Muranyi, Arpad; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: FW: Question on clock_times
Mike,
I submit that the AMI specification defines a functionally flawed
system, and an ambiguous specification. That AMI simulation can
occur
in spite of this is interesting, but not sufficient for a EIA
specification.
Scott
Mike Steinberger wrote:
Scott-
I submit that the existing AMI specification defines a syntax which
has enabled a number of _EDA_ _vendors_ to develop AMI simulation
as a
system. That was our goal.
Mike S.
Scott McMorrow wrote:
Mike
Great. Now we're on the right track. How do we get back to a
specification that functionally does what I want as a user? Quite
frankly, the original developers of the AMI specification failed to
develop a decent functional model for AMI simulation as a system.
This has lead to major issues that, in my opinion, need to be
resolved going forward.
best regards,
Scott
Mike Steinberger wrote:
Scott-
Walter has asked me to answer 2., and I'm pleased to do that.
The short answer to 2. is:
The EDA platform does _not_ know whether a given model has a CDR or
not, and has no direct way to determine that one way or another for
certain.
You may think that if the model returns clock ticks, then the model
has a CDR; but even that's not true. The first Tx model SiSoft
published outputs clock ticks because we wanted to exercise that
feature of the AMI interface; but you know by looking at the code
that there's no CDR in there.
Todd tried to assert a simple fact that people have somehow failed
to embrace:
As long as the model meets the stated software interface
definition,
it is the EDA platform's responsibility to respond appropriately.
What the preceding discussion has quite correctly demonstrated is
that it's possible for a model to do something nonsensical and yet
be compliant with the software interface definition. This is an
instance of the classic distinction between syntax and semantics.
The fact of the matter is that all one can expect from any software
interface definition is that it unambiguously defines the _syntax_
of the interface. While one may also make some attempt to focus the
_semantics_ of the information crossing the interface, the
semantics
should not be so tightly constrained as to unduly limit the
possibilities. As a standards organization, we struggle with this
challenge daily, and there are no simple or complete answers.
What this means for the software developer, and especially the EDA
platform developer, is the software must take the most sensible
course of action when, not if, it gets syntactically correct but
semantically nonsensical data.
The rock is elated.
Mike S.
Scott McMorrow wrote:
I have several questions regarding clock ticks, Walter
1. Why would you say that it is "highly unlikely" that a clock
tick
does not occur during a getWave call? I'd think that the
startup
behavior of a PLL would be such that one would want to filter
out the initial invalid clock ticks until the PLL has locked.
The alternative would be to output the actual stream of
garbage
clock ticks produced by the CDR before lock occurs.
2. Assuming that it is perfectly valid for getWave to return -1
in
the 1st position for both a device with a CDR and without a
CDR,
how is a device with CDR and one without CDR distinguished by
the EDA platform?
3. What is the desired clock_ticks behavior if the CDR goes out
of
lock during waveform processing, considering that this is
quite
possible for cases where S/N is extremely low and/or
noise/jitter pushes the device beyond compliance limits.
* Output the modeled clock ticks
* Output -1 until lock occurs
--
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
