Subject: Re: Help, need feedback:

From: Arpad Muranyi <[email-masked]>
Date: Thu, 07 Nov 96 12:10:00 PST

Text item: 

Scott,

I can't comment on the s2ibis program.  I just wanted to correct you in saying 
it is not that SPICE doesn't model the diodes correctly, it is the people using 
SPICE who do not bother using some of the SPICE parameters to model the diodes 
correctly.

Arpad
===============================================================================

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...

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***.

Cc: [email-masked], [email-masked], [email-masked], [email-masked],
        [email-masked]
Subject: Help, need feedback:
To: [email-masked], [email-masked]
From: [email-masked] (Scott Schlachter)
Date: Thu, 7 Nov 96 11:18:38 PST
.7.3/8.7.3) with SMTP id LAA26229; Thu, 7 Nov 1996 11:29:37 -0800 (PST)
Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.c
om (8.8.2/8.7.3) with ESMTP id LAA16705; Thu, 7 Nov 1996 11:25:24 -0800 (PST)
Received: from mailbag.jf.intel.com ([email-masked] [134.134.248.4])
by relay.jf.intel.com (8.8.2/8.7.3) with ESMTP id LAA08511; Thu, 7 Nov 1996 11:2
2:50 -0800 (PST)
Return-Path: [email-masked]

---

From: [email-masked] (Scott Schlachter)
Date: Thu, 7 Nov 96 13:51:28 PST

Arpad,

I consider the fact that in order to have SPICE model the correct diode
resistance with a MOS transister that you have to "trick" it by either
attaching a unidirectional resistor to the drain, attaching a resistor 
between the bulk and the drain, or negating the 
inherent diode all together and using an attached discrete component, 
that there is a fault with the SPICE simulator (or rather just an 
incomplete model). (Of the above, we are still experimenting as to which
will provide the most accurate to the real device).
  
No big deal, as through your help and others, we now have ideas for some 
possible workarounds,
but the SPICE manual did not provide any discussion on this, and listed
no apparent way of including the correct vertical resistance associated
with the diode (instead it just includes the lateral drain resistance 
associated with the current path through the transistor).  So, I don't
think that the users of SPICE are to be blamed so quickly on this point,
but more rather the limmitations to modeling the inherent diode 
associated with MOS transistors in SPICE (why don't they provide for 
a vertical resistance parameter that would be associated with the diode
instead of the drain (or source) resistance?).  From our observations
so far, just a adding a few ohms of additional resistance in the form of 
a resistor between the bulk and source has a very significant effect to the 
IBIS table, specifically in the regions that the diodes start to clamp
(between -Vcc to 0V, and Vcc to 2*Vcc). 
-Scott Schlachter

>it is not that SPICE doesn't model the diodes correctly, it is the people using>

---

From: Arpad Muranyi <[email-masked]>
Date: Thu, 07 Nov 96 14:12:00 PST

Text item: 

Scott,

You are right.  At the level of detail you are after SPICE seems to be lacking. 
What I was referring to was when SPICE modelers don't even go to the extent of 
using the available drain, source, etc resistance parameters yielding currents 
in the range of 1.0e+22 Amps at 1 V of forward bias.

Arpad
================================================================================

Arpad,

Subject: Re: Help, need feedback:
To: [email-masked], [email-masked], [email-masked]
From: [email-masked] (Scott Schlachter)
Date: Thu, 7 Nov 96 13:51:28 PST
.7.3/8.7.3) with SMTP id OAA28224; Thu, 7 Nov 1996 14:01:21 -0800 (PST)
Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.c
om (8.8.2/8.7.3) with ESMTP id NAA28684; Thu, 7 Nov 1996 13:59:10 -0800 (PST)
Received: from mailbag.jf.intel.com ([email-masked] [134.134.248.4])
by relay.jf.intel.com (8.8.2/8.7.3) with ESMTP id NAA08467; Thu, 7 Nov 1996 13:5
6:36 -0800 (PST)
Return-Path: [email-masked]

---

From: [email-masked] ( Bob Ross)
Date: Fri, 8 Nov 96 16:07 PST

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 [email-masked]
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

> Message-Id: <[email-masked]>
> Status: RO

> > From scotts Tue Nov  5 16:25:12 1996
> > Subject: Serious s2ibis problem?
> > Cc: jem, whauff, [email-masked], [email-masked], [email-masked]
> > 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
> >