[ibis-macro] Re: Problem with IBIS-AMI clock_times definition
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 18 Jun 2009 11:00:36 -0700
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 AM
To: 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
Other related posts:
