Keep the sample count as an integer, then use a single floating point multiplication to multiply by the sample interval to generate each floating point time value. The integer arithmetic has no round-off error, and there's only one floating point operation. Mirabile dictu and Bob's your uncle.
If 32 bits isn't large enough to count all the samples you have in mind, then create a double precision integer (e.g., 64 bits), increment that, and perform the floating point multiplication. That means you have to write some bit twiddling functions to perform the arithmetic functions. I think those bit twiddling functions would make a good homework assignment for an introductory programming course, since it would require an understanding of binary arithmetic, provide practice with bit-wise logical operations, and force a deeper understanding of the relationship between integer and floating point variables in the programming language.
Mike S. Muranyi, Arpad wrote:
Mike, Thanks again for your reply. You understood my problem statement correctly. I some times call this "simulator induced jitter effect". You are probably correct that an accurate clock time calculation technique may be a very basic skill, but I don't think we can assume that everyone knows it. I have to ask the question again: "who writes these algorithms"? In the case of EDA tools, I would think the answer is fairly obvious, programmers should be computer science experts whose basic skills should include such knowledge. However, in the case of AMI model authors I am not sure I could answer this question that easily. I would tend to think that since AMI models may be written mostly by IC vendors, their authors may be circuit and/or system designers, whose basic skills may be in different areas. For these reasons I would suggest that we should add at least one example to the section in the AMI specification where the clock_times argument is explained to show the reader how to calculate it properly. We could perhaps add a second example to show how ***not*** to do it. After all, we do have examples in the specification, and since this is a non proprietary "ordinary skill of the art", it wouldn't give away anyone's competitive secrets. I think this is an important enough issue to be placed into the IBIS-AMI specification vs. a separate cookbook document or white paper to help model makers in making useful models. Talking about examples, I just looked at the Tx model in the SiSoft Toolkit http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20080523/sisoft/SiSoft_IBIS-AMI_Eval_Toolkit_v2_10.zip and found this code: //Compute the response. clock_dx = 0; for( indx = 0; indx < wave_size; indx++ ) { if( wave_in[ indx ] * self->last_in < 0 ){ clock_times[ clock_dx++ ] = gw_time + (indx-0.5)*self->sample_interval; } ... } ... gw_time += wave_size*self->sample_interval; which doesn't strike me as the "programming technique that ... preserves the full floating point precision at all times". Shouldn't we, the experts, set a better example for the less experienced people who are looking for guidance when they read this code (and may even end up using it in their own models by cutting and pasting), especially if this is such a basic and easy thing to do? Thanks, Arpad ==============================================================-----Original Message-----From: Mike Steinberger [mailto:msteinb@xxxxxxxxxx] Sent: Thursday, June 18, 2009 11:32 AMTo: Muranyi, Arpad Cc: IBIS-ATM Subject: Re: [ibis-macro] Re: Problem with IBIS-AMI clock_times definition Arpad-Thanks for the further explanation. Now I see your point. What you're saying is that since the clock ticks are generated according to the receiver model's internal time reference, the EDA platform may use the clock ticks to trigger the display of the eye diagram, and if the EDA platform does so, it will interpret the clock ticks according to its own time reference. If the two time references differ, then the eye diagram will be affected accordingly, resulting in an eye diagram that may be shifted in time or smeared along the time axis. Nothing will break, but the results will be more pessimistic than they would have been had the two time references been identical.There is a simple programming technique that many programmers know about that will avoid these problems altogether because it preserves the full floating point precision at all times. This programming technique does not happen to be either of the ones you gave as examples. As far as I'm concerned, this technique is so basic that it falls under the old patent application phrase "person with ordinary skill in the art". If either the model developer or the EDA developer does not happen to know/use this or an equivalent technique, then you're quite right that the results will suffer accordingly.In other words, you're quite right that it's possible for either the model developer or the EDA developer to get this calculation wrong. However, IMNSHO, there's no excuse for it.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
--------------------------------------------------------------------- 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
