Subject: RE: BIRD #61 - Function or not to function, that is the question. ..

From: "Muranyi, Arpad" <[email-masked]>
Date: Wed, 8 Sep 1999 10:32:39 -0700

Matt,

Thanks for your comments.  I tend to agree with you for the most part, but
we can't
ignore some other aspects either.  This is what makes it so hard for me to
decide
what would be better.

In an ideal world, your assumption about the model maker knowing his/her
parts the best
is correct.  However, when I you look at some of the IBIS models that are
released,
I wonder whether the person who made it even knows what an IV curve is.
This is very
sad, but true, and unfortunately it is the result of companies putting IBIS
model
making on the lowest priority levels.  Now, if we have such levels of
difficulties
just getting people to understand how to make Vcc relative IV curves, or how
to avoid
double counting of the clamp currents, etc., I have doubts that we will see
a lot of
good and/or usable models based on transfer functions.

I don't know if you were sarcastic in your last sentence or not, but I see
your point,
if it is difficult enough, people may be forced to understand what they are
doing,
and as a consequence the job of IBIS model making may be assigned to
"smarter" people.
However, this may result in a backlash, i.e. fewer models, or more bad
models.

So, even though I believe that using (transfer) functions would allow better
and more
accurate models, I am afraid that it may not be the most beneficial change
if all
other factors are considered.  Of course, the new method would not have to
exclude the
old method, so we could still introduce the functions in IBIS for the
"pros", but at
the same time we will have to go easy on it to keep (usable) models
coming...

Arpad Muranyi
Intel Corporation
============================================================================
=========

-----Original Message-----
From: Matthew Flora [mailto:[email-masked]]
Sent: Thursday, September 02, 1999 9:02 AM
To: [email-masked]
Subject: Re: BIRD #61

Arpad,

> If we go with functions to characterize input behavior, the model maker
> will have to generate the coefficients, or even the function itself.  In
> this case the simulator may turn into a dumb number cruncher.

Personally, I have no problem with turning the simulator into a dumb number
cruncher.  There would still be plenty of ways to differentiate tools
(speed,
price, usability, completeness, platform support, etc., etc.)

I assume that the model maker is the most informed of anyone on the actual
behavior of the component.  Therefore, I would further assume that an
equation
generated by the model maker would be more accurate than a generic equation
fitted by an EDA tool.

I realize this increases the burden on the model maker, but hopefully the
same
equation would be applicable to a whole family of parts (with perhaps minor
modifications for each part).  If this were true then the "cost" of
developing
the base equation could be amortized across the whole part family.

(I also realize that adding support for equations to IBIS could be a large
undertaking.)

I myself have no experience with equation based models, so I don't have a
feel
for their impact on simulation times relative to table driven simulation,
nor
do I have a feel for the odds of equations being incorrect or incomplete.
However, I am optimistic that adding equations to IBIS might stem the growth
of IBIS into an ever more complicated standard that only an "expert" can
use.

Regards,
Matthew Flora
IBIS Open Forum Postmaster
(425) 869-2320 PH
(425) 881-1008 FAX
[email-masked]
HyperLynx, 14715 NE 95th Street, Redmond, WA 98052 USA