Re: Non Monotonic Drivers

Ron:

I am planning to put a Monotonicity discussion on the September 15, 1995
meeting at 9 AM. I would estimate that it should take about 20 minutes as
a soft limit, unless you have a more detailed agenda to follow for
that discussion.

Our normal methodology is to use the telephone meetings to introduce
topics or to discuss issues with respect to solid proposals (BIRDs).
Normally a substantial amount of discusson is done on the reflector.

So if you would like, you can start the process at this time by telling
is specifically (1) What you mean by monotonicity (VI tabless?), (VT tables?).
(2) What is the specific concern with respect to IBIS? (3) What are
your concerns with respect to simulation of IBIS models? (4) Is there
a class of devices which exhibits frequent non-monotonic behaviour?

I would like to point out that monotonicity has been discussed extensively
in the past and there are several statements and warning messages documented
in IBIS Version 2.1 that were produced as a result of this discussion.
There has been further discussion that pullup or pulldown tables which
have non-monotonic behavior region can be combined with the clamping
tables to produce an overall monotonic response. Simulators usually have
no problem with this situation, even though the parser will issue a warning
message.
 
I would further like to clarify that IBIS itself as a data file for a model
allows including non-monotonic data. It tabulates the raw data based on
measurement or simulation. Warning messages do alert the user that
some simulators may encounter numerical problems when processing the
non-monotonic data.

So the perception by a foundry that IBIS requires only monotonic data is
wrong. We need to get to the real issue or concern.

Bob Ross,
Interconnectix, Inc.

> -- [ From: Ron Christopher * EMC.Ver #2.10P ] --

> Will Hobbs,

> I recommend a teleconference call be set up just on this subject. One
> suggestion would be the first hour of your 9/15 meeting, or it could be
> a separate teleconference call, but all those participating on the
> reflector must be committed to be present.

> I see in the discussion insufficient user request to justify the
> necessary study, but I also see a whole foundry not supporting IBIS
> because of this problem. This seems inconsistent. Users can get
> around the problem today with SPICE models and NDA agreements, but this
> will not be adequate as reuse and interoperability of signal integrity
> tools increases.

> Ron Christopher
Received on Wed Aug 30 17:26:05 1995