Mike,
The illustration for the problem was just a simplified example,
I know there are "better" algorithms to calculate clock_times
more accurately. But there is no guarantee for what the AMI
model maker will use in their DLL.
The reason this seems to be an issue is that the waveforms which
are passed in and out of the DLL have no time vectors, only
voltage vectors. It is assumed that the time points are located
at the sampling rate.
| 3.1.2.1 impulse_matrix
|
| 'impulse_matrix' is the channel impulse response matrix. The impulse values
| are in volts and are uniformly spaced in time. The sample spacing is given
| by the parameter 'sample_interval'.
As a consequence, the EDA tool works with a time table of its
own, while the AMI model will calculate another time table for
itself. This is where the discrepancy I illustrated in my
previous message can come from.
Arpad
====================================================================
-----Original Message-----
From: Mike Steinberger [mailto:msteinb@xxxxxxxxxx]
Sent: Wednesday, June 17, 2009 6:14 PM
To: Muranyi, Arpad
Cc: IBIS-ATM
Subject: Re: [ibis-macro] Re: Problem with IBIS-AMI clock_times definition
Arpad-
Thanks for the clarification. It helps me understand the context of your
question, although it leaves me wondering how it is that you came to
tackle the problem you appear to be tackling.
In particular, you seem to be assuming that the EDA platform needs to
calculate the same clock ticks as the model, and somehow the two
calculations are supposed to agree. In point of fact, I don't remember
anything in the IBIS AMI spec which even mentioned having the EDA
platform calculate any clock ticks, much less place any requirement on
such a calculation. Furthermore, the receiver model is expected to
contain information about the clock recovery that the EDA platform could
not possibly have, and the receiver model expresses that information in
the form of clock ticks. That's the only way that the EDA platform gets
to find out about the behavior of the clock recovery algorithm in the
first place.
You quite correctly and clearly demonstrate that two algorithms which
mathematically should give the same result in fact do not. For the
particular calculation you describe, I use yet another algorithm which
yields even more precise results. In fact, I've used the same algorithm
in at least two very different programming languages.
At a higher level, you remind us of the sad fact that in the EDA
business, we're attempting to use a mechanism that's inherently
quantized in time, space, and amplitude (a digital computer running a
sampled data analysis) to create the illusion of results one would get
from a continuous World. It can be a thankless task when our customers
point out that the illusion didn't quite work.
Mike S.
---------------------------------------------------------------------
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