Mike,
Thanks for your reply. I apologize, but I didn't describe
the problem correctly. It seems that the question I should
have asked revolves around how the clock_tick values are
calculated. The DLL may have one algorithm, and the EDA
tool may have another algorithm. Due to round off errors
the two values may end up being different. Since the AMI
spec doesn't describe how to calculate these clock times,
we could have many different results.
Here is a little code to illustrate how rounding can
destroy synchronization between the tool's clock times
and the DLL's clock times.
Suppose that the bit rate is 1/1e9 and sample interval
is 1/100 of it.
The code below illustrates two possible scenarios of
incrementing time. Here, "sum1" is incremented every
sample point, but "sum2" is incremented by much larger
intervals, which are 4e9 * sample interval or 4e7 bits
long.
Look at the printed output. Even after the first pass
of external cycle (one call to GetWave), the two clocks
become different by more than two bit intervals!
double bit_rate = 6e9;
double bit_interval = 1.0/bit_rate;
double dt = bit_interval / 100;
double sum1, sum2;
unsigned long k1, k2, k2max = 4000000000;
sum1 = sum2 = 0.0;
for(k1=4000000000; k1--; )
{
sum2 += k2max * dt; // one type of time incrementation
for(k2=k2max; k2--; k2)
sum1 += dt; // second type of time incrementation
printf("sum1=%22.16le\n sum2=%22.16le\n sum1-sum2=%22.16le\n\n\n",
sum1, sum2, sum1 - sum2);
}
Printed output:
sum1=6.6666670157251419e-003
sum2=6.6666666666666662e-003
sum1-sum2=3.4905847570015913e-010
(sum1-sum2)/bit_interval = 2.0943508542009548e+000
sum1=1.3333334233994281e-002
sum2=1.3333333333333332e-002
sum1-sum2=9.0066094859952983e-010
(sum1-sum2)/bit_interval = 5.4039656915971790e+000
sum1=2.0000001452263421e-002
sum2=1.9999999999999997e-002
sum1-sum2=1.4522634241009857e-009
(sum1-sum2)/bit_interval = 8.7135805446059145e+000
sum1=2.6666668670532561e-002
sum2=2.6666666666666665e-002
sum1-sum2=2.0038658961329947e-009
(sum1-sum2)/bit_interval = 1.2023195376797968e+001
Arpad
=========================================================
-----Original Message-----
From: Mike Steinberger [mailto:msteinb@xxxxxxxxxx]
Sent: Tuesday, June 16, 2009 11:44 PM
To: Muranyi, Arpad
Cc: IBIS-ATM
Subject: Re: [ibis-macro] Problem with IBIS-AMI clock_times definition
Arpad-
We ran into this problem as well; however, the problem wasn't due to the
inherent accuracy of a double precision number, but rather due to the
number of significant places to which we output the number when we wrote
it to a file. You can demonstrate this with IBIS_AMI_test. When you run
more than a million bits or so, the waveforms start looking like
hieroglyphics.
A double precision number in IEEE standard format, which is what we're
talking about here, has approximately sixteen significant decimals
places to its mantissa, derived from a 48 bit mantissa. At 1ps
resolution, that's enough decimal places to simulate ten thousand
seconds of time, or in other words more than two hours of simulated
time. Seems like that ought to be enough for most purposes.
Mike S.
Muranyi, Arpad wrote:
Hello AMI experts,
We stumbled on an interesting problem with the definition
of the clock_times parameter in the GetWave function. This
is what the spec says:
| Vector to return clock times. 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.
The problem is that this variable uses a type double. If
you run a few million bits, it will work, but when we run
hundreds of million bits or more, the double precision number
runs out of decimal digits to give an accurate time resolution
for the clock ticks. This can turn into huge errors in the
eye diagram and related curves.
We would have been better off if we would have defined this
value as a relative number with respect to an ideal clock
tick time, kind of like a error term to be used as a
correction value.
Has anyone ran into this problem yet?
I would suggest to fix the AMI spec, because this seems to
be a fairly serious problem.
Thanks,
Arpad
===============================================================
---------------------------------------------------------------------
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
