MORE S2IBIS COMMENTS

Steve,

Thanks for your April 1 response. Here are some responses:

(1) There are two types of information that you need to run S2IBIS and
to produce completed models within the commented [Pin] mapping portion.
The "model_type SPICE_NODE ramp_time input_pin [enable_pin] ..." line
contains information for CONTROLING THE SIMULATION of a particular
Spice run. Thus vih and vil are the PULSE parameter levels FOR SPICE,
and NOT for the [Model]. Extending this for more PULSE parameter
rise time and fall time control with "tr" and "tf" is good for
generality. In my opinion it is probably worth it to add the complication
at this time. However, this is low priority for me since I think your
default of 0.1ns seems like a good choice. This actually opens the
door for other extensions (RS for source impedance for inputs, some load
control (50 ohms, Vcc volts, etc) even though IBIS has some "rigid"
guidelines in this area - there may be real world practical considerations
or convergence considerations which "force" a departure to still produce
an acceptable mode. I would be comfortable defering this matter until
later.

(2) The second type of information which we are currently unable to
enter automatically are some required and optional parameters under
[Model]. In this category, would be the some CONTROL information which
your are currently putting into the model:
     Polarity
     Enable
based on the Spice model provided. This is technically correct provided you
are using a model which correctly has this information with the correct
polarities. This is often the case. For signal integrity analysis,
the polarity details may not be important because the LOGIC details are
not considered. The threshholds are tested at both limits regardless of
the logic Input polarity, and the Output is usually pulsed both direction
without being concerned which transition comes first. Consequently some
Spice models may be suitable for analysis for several outputs without forcing
the unnecessary overhead of putting in the Spice models. For example,
the 74F240/241/244 have output polarity and enable polarity variations, with
the 241 having both an Active-high and Active-low enable pin. In practice,
you may want to use one Spice model for all of the components.

My suggestion is NOT to insert Polarity and Enable based on the supplied
configuration. Instead, I suggest you create an appropriate convention
that allows this information to be entered under user control. This
convention will also apply to the Optional and Required IBIS Version 1.1
parameters of Vinl, Vinh, and C_comp as well. For example, suppose we
use "**" (and anyone may have better idea than this) as the ADDITIONAL TEXT
PARAMETERS, then the format for a 74F240 input may be:

*[Pin] signal_name model_name R_pin L_pin C_pin
* 1 G_BAR EN_MODEL
* Input 101 1 0. 3.
**Vinh = 2.0
**Vinl = 0.8
**C_comp 5pF 3pF 7pF
* 2 A0 0 IN_MODEL
* Input 100 1 0. 3.
**Vinh = 2.0
**Vinl = 0.8
**C_comp 5pF 3pF 7pF

The ** lines would be printed with the Input [Model]

Similarily,
  .....
* 18 YA0_BAR TRI_MODEL
* 3-state 102 2.0e-8 2 1
**Polarity Inverting
**C_comp 7pF 5pF 9pF
* 19 .....

Here we choose not even to include Enable in the model. Futhermore, the
Spice model used may have "forced" the "Non_Inverting" Polarity.

(3) Regarding alpha-numeric pins, IBIS already restricts the pin
"numbers" to "5 characters" or less, so you are alright for DOS
compatiblity. The maximum PGA numbering I think is 4 characters, e.g.
A1 ... Z24 (I and O are typically omitted) and then AA1 .. AAnn BB1 .. BBnn
and so forth.

(4) At some point, your output could adopt a format with comment lines
such as the models provided by Intel. I would not object to a different
format for differentiation if you want to make improvements. I think
it is alright for a fixed format, but an option would be to allow
the "comment" lines and text to be included in some manner along with
the [Model] ADDITIONAL TEXT PARAMETER of comment (2) above.

Happy Easter
Bob Ross
Interconnectix, Inc.
Received on Sat Apr 2 18:47:16 1994