Re: Avoiding Double Counting

Text item:

Syed,

I have read the replies you got so far, and they are all correct. However,
there is one other reason that I didn't see mentioned.

When I first started experimenting with these I-V curves, my goal was to do them
in such a way, that GND bounce and/or Vcc droop could be modeled correctly if
desired. The problem goes as follows:

Consider an I-V curve for a device driving low (the same is also true for high
state, but I am not going to address that here). If you sweep it from -Vcc to
2*Vcc, you get basically three regions in the I-V curve. First you are
measuring the GND clamps, which are in the range of -Vcc to 0 V. Then the
pulldown transistor, between 0 V to Vcc, and above Vcc the power clamp. In
CMOS, the GND clamp usually comes from the parasitic diode in the pulldown FET,
but the power clamp comes from the parasitic diode of the pullup transistor.

Now, if you modulate the GND or Vcc voltage in a simulation due to SSO noise,
the knee voltages of these clamps should also move around with respect to their
corresponding supply voltages. If you had a single I-V curve, this would not be
possible. This was the real reason I choose to separate them the way they are
done now.

Of course, one might argue, that the separation could have been done by the
simulator tool after reading in the curves from the IBIS model ("give me raw
data" approach). But even in that case, we would have to use ON curves and
3-stated curves in the IBIS models. This method would work too, if done
correctly. I guess I was just trying to make it easier on the tools (or make
sure that this is being done right) when I decided to separate things during
model generation.

In the case of the output only buffers, this separation is not as straight
forward, because we do not have a 3-stated curve that we could easily subtract
from the ON curves. With some extra work, however, it would be possible to
identify each of the clamps in the I-V curves, and knowing the saturation
current of the pulldown or pullup transistor, it would be possible to reverse
engineer a 3-stated curve for the output only devices also. This would then
enable the modeler to generate models similar to the I/O models, with
independent I-V curves for the clamps. The question is, is there a benefit to
go through all this math to do that? Also, are there unusual devices out there
with which this method falls apart?

I guess, IBIS doesn't prohibit the output buffers from being modeled this way,
but for the sake of simplicity, when I have an output only model, I generate
"combined" curves and do not use the clamp curve sections.

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

IBISfans:

Got a question about double counting of clamp data(Output models).

I believe simulators combine the Pullup(pu) and Power Clamp(pc)
data and also Pulldown(pd) and GND Clamp(gc). That is why both
pu and pd V/I table should not contain pc and gc information.

This is also why, pu and pd data can be non-monotonic and once
the clamp data is combined, the data becomes monotonic.

If the above statements are true, why not just take pu data
with the pc data included and simply put 0.0mA on the pc V/I
table. Take pd data with the gc data included and leave 0.0ma
for the gc V/I table.

If this can be done then Model providers who are creating models
from actual bench measurements, do not have to go thru the pains
of doing V/I table subtraction. A DC sweep on an enabled output
structure gives you the combination of the output stage + the clamp
structures.

It seems that we go thru too much data crunching and Simulators
simply connect the two tables anyway.

Possible I am missing something very important here. Pls comment.

Regards,
Syed
National Semiconductor Corp.

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: huq@rockie.nsc.com
Subject: Avoiding Double Counting
To: ibis-users@vhdl.org
Message-Id: <9611210130.AA08834@rockie.nsc.com>
From: huq@rockie.nsc.com (Syed Huq)
Date: Wed, 20 Nov 96 17:30:43 PST
Received: from kural by rockie.nsc.com (4.1/SMI-4.1)
     id AA08834; Wed, 20 Nov 96 17:30:43 PST
Received: from lightning-gw.nsc.com by nsc.nsc.com (5.65/1.34) with SMTP
     id AA15304 for ibis-users@vhdl.org; Wed, 20 Nov 96 18:07:59 -0800
Received: from nsc.nsc.com by natsemi-bh.nsc.com via smap (V1.3)
     id sma013763; Wed Nov 20 18:08:59 1996
Received: (from uucp@localhost) by natsemi-bh.nsc.com (8.6.12/8.6.11) id SAA1381
1 for <ibis-users@vhdl.org>; Wed, 20 Nov 1996 18:09:03 -0800
Received: from natsemi-bh.nsc.com (natsemi-bh.nsc.com [204.163.202.66]) by vhdl.
vhdl.org (8.7.3/8.7.3) with SMTP id SAA23631 for <ibis-users@vhdl.org>; Wed, 20
Nov 1996 18:19:15 -0800 (PST)
Received: from vhdl.vhdl.org (vhdl.vhdl.org [198.31.14.3]) by mailbag.jf.intel.c
om (8.8.3/8.7.3) with ESMTP id SAA27620; Wed, 20 Nov 1996 18:15:09 -0800 (PST)
Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com [134.134.248.4])
by relay.jf.intel.com (8.8.2/8.7.3) with ESMTP id SAA27253; Wed, 20 Nov 1996 18:
12:35 -0800 (PST)
Return-Path: owner-ibis@vhdl.vhdl.org
Received on Fri Nov 22 11:58:21 1996