RE: "non-monotonic" warning in IBIS checker

From: Dunbar, Tony <Tony_Dunbar@mentorg.com>
Date: Mon Apr 10 2000 - 18:04:28 PDT

Sherri,

The reason for the warning is that the current in the reported column (typ,
min, or max) of the reported table ([Pullup], [Pulldown], etc.) changes
"direction". For example, say it is increasing in +ve value generally in the
table when, suddenly, the next line shows a lower value of current. The next
line after that may continue this change in direction or it may go back to
the +ve trend it had before. Either way, the data is non-monotonic - and
that CAN BE bad (see below). It should not TYPICALLY occur in any model and,
if it does, the model manufacturer should warn you about it in the file
header (just to be nice, you know). Thankfully, it most often occurs at the
extremes of the tables, away from the typical operating region where the
simulator should not need to wander. If it is in these regions, you can, as
a temporary workaround, remove that data (despicable behavior, I hear the
purists say - and I agree, but read on). You will often find that one column
of a model will go bad first, then the other columns go bad within a few
lines of the first one. Be careful, however, to not chop out too much so
that you encroach to close to the typical operating range. Either simply
truncate the table at the last good line or cut out the bad and put a new
last line in with a current equal to that in the last good line - simple
truncation should be fine. The temporary workaround should only be used for
as long as it takes to shame your IBIS model manufacturer to either repair
the model or explain the validity of the non-montonic data.

Generally speaking, testing the monotonicity of a table on its own is not
representative of how the data is used by an IBIS simulator, so it may not
be reporting a true non-monotonicity. I think you'll find, however, in most
cases it is. A simulator will actually use a summation of ALL of the
currents from the typ, min or max column from all of the tables - pullup,
pulldown and the clamp tables - at any one point in time. So, simple linear
interpolation on just one table may not suffice. Most reported cases will be
real since the sudden change in the "bad" table is usually big enough to
outweigh the contribution from the other tables.

The data can be bad for the simulator because, in the minor case, it could
pass through almost or totally unnoticed by you, causing no hiccup to the
simulator function. The simulator results may then be inaccurate and this is
worse for you than it is for the simulator. In a more extreme case, it could
cause the simulator to fail to converge as the nodal currents suddenly don't
"add up" - well, they will but nowhere near where the simulator expects
them. From the user perspective, though infuriating, this could be the
better case - I would sooner have a simulator error than be fooled by wrong
simulator results.

Ignoring non-monotonic data can be risky - the parser is putting you in
control of how risky you want to be. Either way, don't overlook bringing
this to the attention of the model manufacturer to either explain it or fix
it.

Regards,
Tony

-----Original Message-----
From: Shaghayegh Azgomi [mailto:sazgomi@yahoo.com]
Sent: Monday, April 10, 2000 7:17 PM
To: ibis-users@eda.org
Subject: "non-monotonic" warning in IBIS checker

Hi,
I have a question regarding IBIS models. When I try
to use IBIS checker to verify the models IBIS models
(Hyperlynx simulator) I get warning messages regading
to 'non-monotonic' nature of some signals. Some of
the warning are as following such:

Pulldown Maximum data is non-monotonic
Pulldown typical data is non-monotonic
Power clamp Minimum data is non-monotonic
 and so on.

I want to know what is the reason for
this'non-monotonic' warning? Do we need to be worry
about it? Would it effect simulation ? How we can
expalin this warning?

Best regards,
Sherri
sazgomi@yahoo.com

__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
Received on Mon Apr 10 18:12:41 2000

This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:53:46 PDT