IBIS List Email Archive: S2IBIS COMMENTS

From: Bob Ross <bob@icx.com>
Date: Fri Apr 01 1994 - 12:21:39 PST

To IBIS Community:

I thought for visibility I would post Steve's response to some recent feedback
I provided him regarding my testing of the S2IBIS program with PSpice. Most
of my prior discussions related to my own trials and tribulations (and
failure to read the documentation) in getting the program running. Overall,
excellent progress is being made. Note that the partitioning problem of
clamping data and pullup and pulldown data that we discussed today relate
to this program as well.

Bob Ross,
Interconnectix, Inc.

Subject: RE:S2IBIS FEEDBACK
Date: Fri, 01 Apr 94 12:48:49 EST
Status: R

Bob:

Thank you *very* much for your excellent help! You are quite right
about the erroneous voltage ranges in the Pullup and Power_clamp tables.
I got this right in the unix version, but when I modified s2ibis to
deal with SPICE 3 and PSPICE, I had to rewrite the output handling
section. As you know, the IBIS spec requires these tables to be
handled differently. The voltage in the table is really Vcc-Voutput.
In Version 0.1, the SPICE output is handled the same way for all
tables, so these two tables are totally screwed up now. I can not
find anything in the IBIS 1.1 spec regarding the partitioning problem.
I think I understand your explanation below, but I will wait until I
get your papers before I try to fix the program.

Regarding vil, vih, etc: this is why I wanted you guys who are
actually going to use s2ibis to try it out. I can easily tailor this
to work the way you want. For instance, instead of

model_type SPICE_NODE ramp_time input_pin [enable_pin] etc...

the pindata line for (generic) outputs could include input ramp data
such as vih, vil, tr, tf, etc. and look more like:

model_type SPICE_NODE ramp_sim_time vil vih tr tf input_pin [enable_pin] etc...

Please let me know if this seems like a reasonable approach, or better
yet, if you can suggest a better approach.

Regarding the alpha-numeric name thing. I ran the example using
cc22 in place of node 22 in the SPICE deck (including on pin 8's pindata
line) and all worked well. Did you perhaps change the 8 to cc22 as well?
I guess the IBIS spec does not explicitly require that pins be integers, but I
thought that's what it meant. s2ibis currently requires integer pin names
but I could change that easily enough. It is only important (for DOS compatibility)
that the pins have less than six characters. Please let me know if you think
I should allow alphanumeric pin numbers.

Regarding using the same model for several pins: Sorry about that, it's dead
easy for s2ibis to do. I put the hooks in to do it, I just forgot to implement
them because all of my test files have only one pin with any given model name.

I will wait until we straighten out some of these problems before I put
anything new on vhdl.org.

Once again, thank you very much for your effort and help!

Steve

Message-Id: <9403312037.AA14543@icx.com>
 To: slipa@eos.ncsu.edu
 Subject: S2IBIS FEEDBACK
 
 Steve,
 
 I have done a few tests and am beginning to understand more the program.
 Here are some comments to date on the PSpice version on DOS:
 
 (1) I just noticed that in the original and preview versions, the [Pullup] &
 [Power_clamp] table voltages extend incorrectly from 10V to 5V using
 your example. This may be related to the suspiciously low rise and
 fall ramp voltages and results. This may be a problem only in the
 PSpice version???
 
 (2) One application I tried was to use the same output model for
 several pins. The result was to produce several identical output
 model files rather than to recognize that the simulation has already
 been done. IBIS_CHK flags as an error models of the same name. In
 constructing a [Pin] file, you would normally have sets of identical
 models.
 
 (3) There may be confusion about the vil and vih parameters. I initially
 viewed them as methods to set the [Model] Vinh = 2.0 and Vinl = 0.8 (for
 TTL) values (or corresponding CMOS Input levels of approximately 1.5 and 3.5V).
 In my opinion the insertion of such values is a "virtual" requirement for
 proper input timing analysis, although making them required fell through
 the cracks when IBIS Version 1.1 was drafted.
 
 S2IBIS does not insert Vinh and Vinl because vil and vih is for a
 different purpose - specifing the low and high state input voltages for
 low and high output states. The documentation needs to indicate that
 the input pulse amplitudes are also controlled by vih and vil. Typically
 Data Books give ranges such as 0 to 3 V for TTL (5 V supply) for input
 pulses and these are useful. A refine (which is debatable) is to also
 insert a 25 Ohm series resistance in the ru and rd models at the input
 to represent a typical terminated pulse generator used in specification.
 This would be the case if you are basing models from measurements and
 want to resimulate the setup.
 
 I would like a separate, optional method to insert Vinh and Vinl in the
 [Model] in some future release.
 
 (4) Regarding C_comp, this is an underspecified parameter that rarely
 appears in data books. The TI ABT data book contains Ci and Co values
 for the die which would be C_comp values for Input and Output or I/O
 models. The supplied values are reasonable estimations (often under
 specified voltage conditions) of the non-linear capacitance reactance
 one would really observe, and what on gets when the device models with
 Cjo are used with Spice. IBIS supports only a fixed, constant value.
 For higher speed devices, typical values range from about 3 to 10 pF.
 While this is a crude estimate, it is still useful when the IBIS model
 is used in Signal Integrity AND Timing analysis. Therefore, an
 extension to the program would be to allow this parameter to be inserted
 as a specified value for each [Model]. Normally Output and I/O models
 will have larger C_comp values than Input models.
 
 (5) Regarding alphanumeric pin designation, I get an error in your sample
 model when is insert pin cc27 in place of pin 8. It accepts pin aa25
 in place of pin 3 although the resulting file did not capture the output
 model name. Also, the resulting *.spi files used 0 as the pin extension
 rather than the alphanumeric designation.
 
 Steve, I am really enjoying working with the program and expect to be
 supplying you more feedback. Some of what I am reporting appear to be
 bugs. The rest is to make to program in full compliance with IBIS Version 1.1
 including most if not all the optional specifications and to make the S2IBIS
 program of production versus prototype quality. I still remain very
 impressed with what you have produced. I hope this helps.
 
 Bob

Date: Thu, 31 Mar 94 19:32:48 PST
>From: bob ( Bob Ross)
To: slipa@eos.ncsu.edu
Subject: MORE S2IBIS FEEDBACK
Status: R

Steve,

I got the BIPOLAR F244 model working after finally getting the Input and
Enable polarities sorted out.

Here are some more comments.

(1) Regarding the [GND_clamp] and [Pulldown] tables, there apprears to
be a general partitioning problem. For Output type models, the [Gnd_clamp]
currents are added to the [Pulldown] currents, so in producing a [Pulldown]
model for the voltages extending into the clamping regions, the [Gnd_clamp]
and [Pulldown] currents must be partioned so that the combination of
currents produces the currents you get with Spice simulations. I am
sending you copies of a handwritten presentation I gave at the IBIS Forum
in November, 1993 which shows some aspects of the "partitioning" problem.

The same comments apply for CMOS models, but the partitioning strategy
is different.

I am also sending you a copy of my F244 model and one that was produces as
an example. There are other problems with the F244 model previously noted.

(2) Another suggestion is to put in detection routines to sense the
existence or non-existence of clamps. Even though large tables are
provided, the [Power_clamp] does not really exist in the model provided.

Bob
Received on Fri Apr 1 13:05:23 1994

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