Re: Help, need feedback:

Scott, Arpad, Michael, Alan and IBIS committee:

I apologize for not jumping in sooner on this issue since, as you have
probably observed, I have been jumping in on other issues. I do need
to add some clarification because the particular algorithms in question
were based, in part, on some long discussions with me and Steve.

First, however, I need to clarify that NSCU has and continues to do
an excellent job in developing and supporting s2ibis - BEYOND reasonable
expectations. The utilities are complicated because they are designed
to cover all or nearly all of the IBIS Version 1.1 and 2.1 functionality.
NCSU has no responsiblity to provide user support. If anything, that
is our responsibility - the user community. The ibis-users@vhdl.org
is an excellent mechanism to raise questions and concerns. Syed Huq
has volunteered to track the techical issues and problems that are
expected to occur.

I want to elaborate on one comment that Alan made concerning addition
of clamp curves over specified ranges. I believe most behavioral
simulators do LINEAR EXTRAPOLATION beyond the voltage end-points of
data contained in the I/V tables. Thus ALL tables are considered
to extend from -infinity to +infinity based on the last TWO data
points. Spice simulators may also allow for EXTENSIONS beyond
the table voltage ranges by using just the LAST data point. These
differences were one reason why IBIS initially opted to specify
a large range (-Vcc to 2Vcc) of operation so users would not be
surprized by the two different methods of analysis in the -Vcc to 0
and Vcc to 2Vcc ranges. Technically the [Gnd Clamp] and [Power
Clamp] tables should also have been both specified from -Vcc to 2Vcc.
In practice, the [Gnd Clamp] tables and [Power Clamp] tables typically
have a value of nearly "0" and a SLOPE of nearly "0" at the IBIS
specified range point of Vcc. So the models will function nearly
the same in all simulators. You are allowed to specify tables
beyond the IBIS mandated minimum ranges. Internal Pullup "resistors"
and Pulldown "resistors" in ASICs require extended tables to support
all simulators. So if a pullup resistor exists, its effects should
be capured in the [Power Clamp] table extending from -Vcc to 2Vcc.

Simulators should add the [Power Clamp] and [Gnd Clamp] currents together
at ALL voltage points (whether these are from extensions or linear
extrapolation). This summation should define the total I/V characteristic
of an Input or an output in the 3-stated mode. These currents are added
to the [Pulldown] currents at the low state, and to the [Pullup] currents
at the high state to form the composite I/V characteristic seen at these
two states throughout the entire -Vcc to 2Vcc range.

As Michael pointed out, the algorithm is for more effient behavioral
modeling. Scott is correct in noting that the mathematical subtraction
definition is not implemented. This is one case where, for very
apparent reasons, the mathematically pure implementation is inferior
to a practical numerical implementation. Take, for example, the
[Pulldown] table. A low state sweep of the output between Vcc and 2Vcc
will eventually pick up the clamp diode from about Vcc+.7. Both
the [Power Clamp] and [Pullup]+[Power Clamp] data that is extracted
both may converge to the same VERY large values (particularly if the
diode resistance is not handled fully according to recent reflector
discussions). The mathematically correct implementation is to
simply subtract the two tables, even if the results converge to 0
as a result of numerically subtracting two large values to get
a small value. Thus a Linear Extrapolation method was chosen to
comply more with the real behavior for the range from Vcc to 2Vcc.
Plus, the [Pulldown] table really does not have to be too accurate
here because (1) when the output is in the low state, you are really
not going to force it to above Vcc in practice, and (2) while this
is a simulator algorithm dependent issue, I do not expect any
transition algorithm from low to high state or high to low state
to depend upon extremely accurate points beyond Vcc or below Gnd.

I personally would have preferred the same extrapolation algorithm
to apply to the [Pulldown] table region between -Vcc to 0. We
compromised on this and used the mathematically pure subtraction
of tables to be in technical compliance with the IBIS Version 1.1
Specification. You see the effects of this in many public s2ibis
generated [Pulldown] tables showing the currents folding back to
"0" at -Vcc. Fortunately, the [Gnd Clamp] dominates, and the
summation of currents is monotonic. Most simulators can either
process the non-monotonic portion of the [Pulldown] table and
translate it into monotonic data, or can do the summation of the
two tables and see only the monotonic result during analysis.

Scott, I commend you for your perceptive and detailed concern on
what appeared to be an algorithm defect. The discussion with you
and Arpad and others on the the nature of the diode resistance gave
me insite as to why some Spice models may have large diode currents.

Best Regards,
Bob Ross
Interconnectix
 

> Date: Thu, 7 Nov 96 11:18:38 PST
> From: scotts@actel.com (Scott Schlachter)
> Message-Id: <9611071918.AA02423@ricky.sun_net>
> To: ibis@vhdl.org, ibis-users@vhdl.org
> Subject: Help, need feedback:
> Cc: jem@ricky.actel.com, whauff@ricky.actel.com, mbs@ncsu.edu, paulf@ncsu.edu,
> slipa@eos.ncsu.edu
> Status: RO

> 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 Fri Nov 8 16:22:25 1996