Subject: Non Monotonic Drivers

From: [email-masked] (MR RONALD J CHRISTOPHER)
Date: Wed, 30 Aug 1995 16:13:59 EDT

-- [ 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

---

From: Will Hobbs <[email-masked]>
Date: Wed, 30 Aug 95 16:20:00 PDT

Text item: 

Ron,

I am OK with making it part of the second half of the 9/15 meeting. This 
discussion would be even better handled at one of our face to face IBIS summits,
though your message indicates enough urgency that it probably can't wait until 
the next one, which will likely be in December '95, or January '96.  The 
reflector has over a hundred names, however, so I seriously doubt you'll see 
full participation from reflector people.  Bob Ross and I will discuss how much 
time to set aside for it, but a full hour seems both too short and too long-- 
too short to reach a consensus and too long in relation to other things on the 
agenda, such as better package models. How many drivers have non-monotonic 
behavior as part of their basic design?  It is not an overwhelming percentage.

An alternative is a 3 hour meeting, with the entire third hour devoted to this 
subject.

My preference is to get more technical meat into the reflector discussions and 
set aside ~1/2 hour in the regular portion of the 9/15 meeting for the verbal 
discussion.

Other opinions?

Will

Will Hobbs,

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

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

Subject: Non Monotonic Drivers
To: [email-masked], [email-masked]
From: [email-masked] (MR RONALD J CHRISTOPHER)
Date: Wed, 30 Aug 1995 16:13:59 EDT
odigy.com (8.6.10/8.6.9) with SMTP id QAA29598; Wed, 30 Aug 1995 16:03:52 -0400
Received: from inetgate.prodigy.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
     id AA18216; Wed, 30 Aug 95 13:13:42 PDT
Received: from vhdl.vhdl.org by aurora.intel.com (5.65/10.0i); Wed, 30 Aug 95 14
:24:25 -0700
Received: from aurora.intel.com by ichips.intel.com (5.64+/10.0i); Wed, 30 Aug 9
5 14:24:56 -0700
Received: from ichips.intel.com by relay.jf.intel.com with smtp
     (Smail3.1.28.1 #2) id m0snud0-000txaC; Wed, 30 Aug 95 14:24 PDT

---

From: [email-masked] ( Bob Ross)
Date: Wed, 30 Aug 95 17:21 PDT

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: Arpad Muranyi <[email-masked]>
Date: Thu, 31 Aug 95 08:35:00 PDT

Text item: 

To all,

I think we should keep this topic (non-monotonic stuff) whithin the IBIS Open 
Forum and not take it outside.  Though not many might be interested in this 
subject today (even thogh I question that), it has surfaced enough times that 
all participants involved in the meetings should hear the discussion.  I also 
feel that this is another major area (besides broader package descriptions) 
which IBIS 3.0 might have to address.

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

Will Hobbs,

Ron Christopher

Subject: Non Monotonic Drivers
To: [email-masked], [email-masked]
From: [email-masked] (MR RONALD J CHRISTOPHER)
Date: Wed, 30 Aug 1995 16:13:59 EDT
odigy.com (8.6.10/8.6.9) with SMTP id QAA29598; Wed, 30 Aug 1995 16:03:52 -0400
Received: from inetgate.prodigy.com by vhdl.vhdl.org (4.1/SMI-4.1/BARRNet)
     id AA18216; Wed, 30 Aug 95 13:13:42 PDT
Received: from vhdl.vhdl.org by hermes.intel.com (5.65/10.0i); Wed, 30 Aug 95 13
:20:06 -0700
Received: from hermes.intel.com by relay.jf.intel.com with smtp
     (Smail3.1.28.1 #2) id m0snyer-000twvC; Wed, 30 Aug 95 18:43 PDT