Re: Interpretation of Minimum/Maximum data in IBIS

Text item:

Andy, and all IBIS gurus,

If you read the spec carefully, you will find the following in the
data derivations methods section:

| The optional [Temperature] keyword will contain the temperature
| which causes or amplifies the slow, weak conditions in the "min" column
| and the temperature which causes or amplifies the fast, strong
| conditions in the "max" column. Therefore, the "min" column for
| [Temperature] will contain the lowest value for bipolar devices (TTL
| and ECL) and the highest value for CMOS devices. Default values
| described later are assumed if temperature is not specified.

So your statement below is not completely true (for CMOS).

At the same time, I think the spec needs to be fixed, because there is no such
thing as {Temperature] keyword, only [Temperature Range], yet the comments use
the first one in several occasions.

I don't have the time to comment on the rest of your message...

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

This is a request for clarification. The IBIS spec is a very
perplexing document. I have a ton of problems with it, and one of
these days, when I can find the time, maybe I will list some of them.

Regarding minimum/maximum data, is the following supposed to be
correct?

For the V/I data under the [Pulldown], [Pullup], [GND Clamp], and
[POWER Clamp] keywords, the "min" column always represents the "slow,
weak" extreme and the "max" column always represents the "fast,
strong" extreme of device performance.

Likewise, for the [Ramp], [Rising Waveform], and [Falling Waveform]
sections, the "min" column always represents the same "slow, weak"
extreme and the "max" column always represents the same "fast, strong"
extreme of device performance. Thus, the computed dV/dt_* value in the
"min" column ought to be the smallest (slowest) of the three, and the
one in the "max" column should be the largest (fastest).

Under [Rising Waveform] and [Falling Waveform] keywords, V_fixture_min
always represents the fixture load voltage used to collect the data in
the "min" column, and V_fixture_max always represents the voltage used
for the data in the "max" column. The spec doesn't say this, but I
think it is the only meaning that makes sense.

For the [Package] keyword, the "min" column always represents minimum
resistance, minimum inductance, and minimum capacitance values; and
the "max" column always represents maximum values. There is no
implied relationship between these values and the device performance
(fast/slow/strong/weak).

For the [Rgnd], [Rpower], [Rac], and [Cac] keywords, the "min" column
always represents minimum resistance and minimum capacitance values;
and the "max" column always represents maximum values. There is no
implied relationship between these values and the device performance
(fast/slow/strong/weak).

For the C_comp sub-parameter under the [Model] keyword, the "min"
column always represents minimum capacitance values; and the "max"
column always represents maximum capacitance. There is no implied
relationship between these values and the device performance
(fast/slow/strong/weak).

For the [Temperature Range] keyword, the "min" column always
represents the lowest junction temperature for device operation, and
the "max" column always represents highest junction temperature.
There is no implied relationship between these values and the device
performance (fast/slow/strong/weak).

For the [Voltage Range] keyword, the "min" column always represents
the lowest operating voltage for device operation, and the "max"
column always represents the highest voltage. There is no implied
relationship between these values and the device performance
(fast/slow/strong/weak) (although I know of no device whose speed
does not vary in the same direction as the voltage).

For the [Pullup Reference], [Pulldown Reference], [POWER Clamp
Reference], and [GND Clamp Reference] keywords, the "min" column
always represents the values associated with the "min" columns in the
[Rising Waveform], [Falling Waveform], and [Ramp] sections; and the
"max" column always associates with the "max" columns in those
sections. Thus, the values in the "min" columns must be the ones that
cause the "slow, weak" extreme, and the values in the "max" columns
must correspond to the "fast, strong" extreme.

So, how well did I do?

I know that one or two of these are likely to cause some discussion.
I see, for example, that s2ibis2 apparently treats the [Temperature
Range] keyword differently; but the way I wrote it above, is the way I
read it in the spec. (I'm not sure that it matters in that case
anyway, because as far as I can tell, [Temperature Range] is only
there for reference ... what would a simulator ever do with it?)

Regards,
Andy Ingraham

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: Interpretation of Minimum/Maximum data in IBIS
Apparently-To: ibis-info@vhdl.org, ibis@vhdl.org
Cc: ibis-info@vhdl.org, ingraham@wrksys.ENET.dec.com
To: ibis@vhdl.org
From: Andy Ingraham 07-May-1997 1214 <ingraham@wrksys.ENET.dec.com>
Date: Wed, 7 May 97 12:21:06 EDT
Received: from wrksys.enet; by us8rmc.enet; Wed, 7 May 97 12:21:06 EDT
Message-Id: <9705071620.AA20126@us8rmc.bb.dec.com>
Received: from wrksys.enet by us8rmc.bb.dec.com (5.65/rmc-17Jan97)
     id AA20126; Wed, 7 May 97 12:20:54 -0400
Received: from us8rmc.bb.dec.com by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV)
     id MAA14230; Wed, 7 May 1997 12:21:25 -0400 (EDT)
Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by server
.vhdl.org (8.8.5/8.8.3) with ESMTP id JAA01745; Wed, 7 May 1997 09:36:07 -0700 (
PDT)
Received: from server.vhdl.org (vhdl.vhdl.org [198.31.14.3])
          by ormail.intel.com (8.8.4/8.8.4) with ESMTP
       id JAA06870; Wed, 7 May 1997 09:45:33 -0700 (PDT)
Received: from ormail.intel.com by relay.hf.intel.com with smtp
     (Smail3.1.28.1 #2) id m0wP9s9-000qDNC; Wed, 7 May 97 09:47 PDT
 
Received on Wed May 7 11:52:19 1997