Bird #8, Monotonicity

From: Will Hobbs <Will_Hobbs@ccm.hf.intel.com>
Date: Tue Feb 01 1994 - 10:36:40 PST

From: Kellee Crisafulli, HyperLynx Inc. To:fellow IBIS members

At the last meeting it was brought up by Arpad at Intel that the monotonic
specification of V/I data may not be clear enough in the present version of the
specification. It would appear that we did not assign this a BIRD
and never finished documenting it! I have started this BIRD by documenting what
was decided at the 1993 summit meeting.

*****************************************************************************
Buffer Issue Resolution Document (BIRD)

BIRD ID#: 8
ISSUE TITLE: Specification of V/I data monotonicity REQUESTOR:
                         Kellee Crisafulli, HyperLynx Inc.
DATE SUBMITTED: 29 January 1994 DATE REVISED:
DATE ACCEPTED BY IBIS OPEN FORUM: {will be filled in when accepted}

******************************************************************************
STATEMENT OF THE ISSUE:
Statements have been made at various meetings specific to V/I data and
monotonicity. This information has not been added to the specification. It is
therefore the intent of this BIRD to add a monotonicity statement to the version
2.0 IBIS specification.

I searched all the IBIS minutes and found the following two IBIS minutes
relating to montonicity:
------------------------------------------------------------------------------
from meeting Nov 5, 1993

We engaged in a discussion on monotonic behavior. There are two aspects -to be
dealt with.
1) How should we deal with output buffers that exhibit non-monotonic behavior
(and in what situations does this occur)
2) Must data be entered in the IBIS file monotonically?

1)
Non-monotonic buffer behavior: Arpad asked, "Do we require monotonic behavior
in curves?" If this is a requirement, the parser must check for monotonicity.

Jon Powell said that customers want to model non-monotonic parts. Non-monotonic
behavior can result from slow feedback designed to prevent parts from melting;
thus is is more of a DC phenomenon than an AC phenomenon. Does this pose a
convergence problem for some simulators? Is a DC representation of the curve
acceptable for some devices? Due to DC current limiting, DC measurements may
imply non-monotonic behavior that would never actually occur under real
switching conditions. How do we measure in an AC manner instead of DC manner?

Behavior that is nonmonotonic due to feedback goes into the controlled slew rate
discussion, modeling the dynamic characteristics of device. For IBIS to be
useful, it must deal with negative resistance regions.

2)
Monotonic data entry: We felt that in IBIS tables, voltage values should be
monotonically rising or falling, but that current values may change. The
parser should check whether the data is good, but it shouldn't restrict the type
of data. A BIRD against the parser should be written at some point to add
checks for this in rev 2.0. No specific AR owner was identified.

-----------------------------------------------------------------------------
From the 1993 Summit minutes:
There are several defined buffer types (input, output, I/O, tri-state, open
drain), which drives what information you collect. Collection of data from
measurement is a decomposition problem, of trying to sort out the effects of
clamps from buffers etc. The companies with whom Bob has worked (Zeelan and
Interconnectix) do this decomposition with software. One problem is selecting
measurement regions with abnormal behavior, such as non-monotonic behavior
caused by device switching or "jumps" in the ESD protection during sweeps.
Their software does some filtering of data to eliminate false abnormal behavior.
They can also filter for monotonic behavior.

Monotonicity, General Discussion
--------------------------------
We clarified that one axis of data representation should be monotonic, such as
the voltage axis on the V/I curve, but that we could not require that the other
axis be monotonic, since we were modeling real components whose nature may not
be monotonic.
------------------------------------------------------------------------------
******************************************************************************
STATEMENT OF THE RESOLVED SPECIFICATIONS:

(The proposed changes start on the 20th line after 'Keywords:' and continue for
4 lines. Note: An '*' is used to denote the changed lines)

|==============================================================================|
| Keywords: [Pulldown], [Pullup], [GND_clamp], [POWER_clamp] |
| Required: Yes, if they exist in the device |
| Description: The data points under these keywords define the V/I curves -of |
| the pulldown and pullup structures of an output buffer -and the|
| V/I curves of the clamping diodes connected to the GND -and the|
| POWER pins, respectively. |
| Usage Rules: In each of these sections the first column contains the |
| voltage value, and the three remaining columns hold the |
| typical, minimum, and maximum current values. The four |
| entries, Voltage, I(typ), I(min), and I(max) must be placed on |
| a single line and must be separated by at least one white |
| space or tab character. |
| All four columns are required under these keywords, however |
| data is only required in the typical column. If minimum |
| and/or maximum current values are not available, the reserved |
| word "NA" must be used. "NA" can be used for currents in the |
| typical column, but numeric values MUST be specified for the |
| first and last voltage points on any V/I curve. Each V/I |
| curve must have at least 2, but not more than 100, voltage |
| points. |
* At least one axis of the data (voltage or current) is -required|
* to be monotonic. For example if the voltage is monotonic and |
* increasing, each seqential voltage point must be larger than |
* the previous value. |
| Other Notes: It should be noted that the V/I curve of the [Pullup] and the |
| [POWER_clamp] structures are 'Vcc relative', meaning that the |
| voltage values are referenced to the Vcc pin. The voltages in |
| the data tables are derived from the equation: |
| Vtable = Vcc - Voutput |
| Therefore, for a 5V component, -5 V in the table actually |
| means 5 V above Vcc, which is +10 V with respect to ground; |
| and 10 V means 10 V below Vcc, which is -5 V with respect to |
| ground. Vcc-relative data is necessary to model a pullup |
| structure properly, since the output current of a pullup |
| structure depends on the voltage between the output and Vcc |
| pins and not the voltage between the output and ground pins. |
| Note that the [GND_clamp] V/I curve can include quiescent |
| input currents, or the currents of a 3-stated output if so |
| desired. |
|------------------------------------------------------------------------------|

******************************************************************************
ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:
I reviewed the previous discussions and recorded the results of the summit.
******************************************************************************
ANY OTHER BACKGROUND INFORMATION:
The interest at the summit seemed to be to make the data more human readable. As
the approach proposed at the summit doesn't seem to have any particular
advantages to simulators. (Have I missed something?)

The original intention I had was to require the data be monotonic on both axes.
This would make it easy for all simulators to handle the data. If the data has
multivalue points, i.e. it is multistable, it could be difficult to assure that
all simulators can find a stable DC operating point, and that they always switch
properly. We have modified how the HyperLynx simulator handles non-monotonic
data to insure that this problem will not occur. Is this a problem for any of
the other simulators like SPICE?

On the other hand, at least one simulator company representative felt that it is
imperative to allow non-monotonic data on one axis to properly represent the
effects of some devices.

The IBIS_CHK program must also be modified to test for this condition.
******************************************************************************
Received on Tue Feb 1 10:35:32 1994

This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:28 PDT