Help, need feedback:

Hello IBIS world,

I sent this message out last Tuesday to both IBIS reflectors, as well as
all of the contacts at North Carolina State University, and have still
recieved no response from anyone. I believe there is a serious problem
with the s2ibis program algorythm, where they appear to fudge SPICE
results in order to have (more proper looking?) waveforms. I believe that
they may have done this as a improper work-around for the reason that SPICE
does not seem to properly model the inherent CMOS diodes correctly. They
extrapolate data for the pull-down and pull-up curves, instead of
calculating it from the full range of I/V data that SPICE produces.
I am not trying to repremand NCSU for this, as in all
other respects this seems to be an excellent tool for producing IBIS V1.1
files from SPICE. I am still questioning if I am interpreting this
correctly, and I really need some feedback from the IBIS community on this.

As the ANSI/EIA-656 homepage endorses the use of s2ibis, and it seems
that it may very well be a commonly used tool for producing IBIS files,
I would think that this might have caught SOMEBODY'S attention...

> From scotts Tue Nov 5 16:25:12 1996
> To: ibis@vhdl.org, ibis-users@vhdl.org
> Subject: Serious s2ibis problem?
> Cc: jem, whauff, mbs@ncsu.edu, paulf@ncsu.edu, slipa@eos.ncsu.edu
> Content-Length: 2882
>
> Hello IBIS folk:
>
> We've been trying to figure out why s2ibis produces a Pull-down (and
> Pull-up) curve that is VERY different from our self-produced
> tables (from SPICE), in particular at voltages from Vcc to 2*Vcc.
> This led me to the FAQ under the /man directory of S2IBIS. Here,
> I found:
>
> QUESTION (6): "How does s2ibis generate tables?"
>
> ANSWER:
> s2ibis uses the following scheme for determining what tables
> need to be generated for a particular pin:
> 0) For POWER, GND, and NC ...
>
> --snip--
>
> 3) For each I/O or 3-state pin...
>
> --snip again--
>
> -> pulldown(-5->0):subtract the associated ground clamp table from
> the pulldown table
>
> -> pulldown(0->Vcc): just use the pull-down table as simulated
>
> -> pulldown(Vcc->2*Vcc):extrapolate using the point at
> Vcc and the point five points before Vcc in the pulldown table
>
> A similar explanation is provided for pulldown table generation.
> My questions are: WHY DO THEY OPT FOR EXTRAPOLATION WHEN THEY HAVE
> ALL THE DATA NESSESSARY IN THE SPICE OUTPUT FILES?
> WHY ISN'T THE TRI-STATE DATA SUBTRACTED FROM THE
> ENTIRE VOLTAGE RANGE?
>
> After reviewing all of the files that are created (and left) by
> s2ibis, I found that it creates V/I tables (***from -Vcc to 2*Vcc***)
> for an I/O in: 1)Tri-state (un-enabled) conditions, 2)Pull-up conditions,
> and 3)Pull-down conditions.
>
> In searching through all of the IBIS documentation I could find, the best
> explanation for how to produce proper Pull-down and Pull-up curves (for
> either SPICE sim data or real data) was in the V2.1 Spec., under
> "Other Notes:" of the [Pulldown], [Pullup], [GND Clamp], [Power Clamp]
> Keyword section:
>
> ... The clamp curves of an input or I/O buffer can be measured
> directly with a curve tracer, with the I/O buffer 3-stated.
> However, sweeping enabled buffers results in curves that are
> the sum of the clamping curves and the output structures.
> Based on the assumption outlined above (which makes sense), the pull-up
> and the pull-down curves of an IBIS model must represent the DIFFERENCE
> of the 3-stated and the enabled buffers curves. (Note... ...)
> This requirement enables the simulator to sum the curves, without the
> danger of double counting, and arrive at an accurate model in both the
> 3-stated and enabled conditions. ...
>
> This explanation seems good for producing V1.1 tables as well (and
> perhaps just didn't make it into documentation until the V2.1 Spec).
>
> So:
> Why does s2ibis not subtract the ***Tri-state (un-enabled)*** data
> from the entire range of both pull-down and pull-up data to derive the
> corresponding [Pulldown] and [Pullup] tables? Instead, it appears that it
> takes EXTRA steps to produce seemingly innacurate tables... Is this a
> serious mistake with s2ibis, or are am I missunderstanding something.
> Thanks ahead for all feedback.
>
> Regards,
> -Scott Schlachter
> Design Engineering
> Actel Corporation
> Sunnyvale, CA
>
Received on Thu Nov 7 11:29:37 1996