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