Bob,
Even though Ian is correct, the real reason is TRANSIENT. As it was
pointed out earlier, the clamp currents are static, i.e. they are not
changing while the buffer is 3-stated, driving high or low. Now, think
how do you go from a 3-stated condition to driving low, for example.
You need to add something to the always present clamp currents to get
to the IV curve that is the SUM of the clamps and the pulldown device.
However, you have to add this extra driving current gradually, governed
by either the ramp, or Vt curve. It is fairly easy to scale the difference
curve during this transition time while adding it to the constant clamp
curves.
If you, say, made a model with a clamp curve, and a SUM curve, as you
proposed, you would have to find a way to cross-fade the two during
this transition in such a way that the clamping portion would remain
constant during that time. I am not sure if you can do that easily.
Of course, the fundamental question is how much should the model maker,
or the tool do. It would be easier on the model maker to just generate
easy IV curves and let the tool do the subtraction and then summation.
The same way, it would have been easier to just describe all IV curves in
a ground relative manner and let the tool do the conversions. When we
wrote the spec I was pushing for the difference curves and the Vcc
relative pullup and power clamp curves to make sure that the tools
use them correctly. The neat thing about Vcc relative IV curve is that
they lend themselves to be used directly (easily) in situations when
power and ground bounce, return path, and power delivery are of interest.
These are big buzzwords in some circles today, yet many simulators are
still not able to deal with them correctly, BECAUSE they are ground
referenced for everything, even the pullup IV curves. (Can you imagine
a pullup transistor, who's current comes from the ground pin?)
Another reason I was pushing for these types of IV curves was that I
had a behavioral model in HSPICE using controlled sources and it was
easier to use them if the IV curves were in this form. I felt that
if it was easier to do it that way in HSPICE with the controlled
sources, it should also be easier in other tools.
In retrospect I feel that yes, we could have made it easier on the model
maker. We would have been able to avoid all these questions and confusions.
But, I believe we would have had even more and bigger "tool differences",
opening the door for endless arguments and explanations on which tool
is doing things right or wrong. Which one would you have preferred? I
honestly don't know which situation would have been better.
I hope this helps to clarify your questions.
Arpad
=========================================================================
-----Original Message-----
From: Ian Dodd [mailto:idodd@cadence.com]
Sent: Friday, July 07, 2000 8:08 AM
To: Haller, Robert
Cc: 'Mike LaBonte'; ibis-users@eda.org
Subject: Re: Subtracting clamp curves from pull-up/down curves
Bob,
I think there are two obvious reasons for keeping the clamps separate:
1. It was intended that models be usable for a range of supply voltages
with the pull-up and power clamps tracking with the supply voltage
and the pull-down and ground clamps tracking with the ground rail.
This was also the rational for referencing the former to the supply voltage.
2. Separating the clamps from the pull-up/down allows modeling of
high/low/tristate
for devices that support these modes.
Recent feedback has indicated that the characteristics of many devices
change
markedly with supply voltage, so using an IBIS model for a supply voltage
other than at which it was designed, can give inaccurate results
Ian Dodd
Cadence Design Systems
"Haller, Robert" wrote:
>
> Mike,
> Not trying to play devil's advocate, but I have always wondered
> why the model maker has to subtract the clamps out, then the software
vendor
>
> puts the clamps back in ? Why not just have syntax (in IBIS) for a pullup
> and pulldown model WITH the clamp ? Thus reducing everyone's work ?
>
> My old (internal) simulator and models were defined this way (IV curves
> included clamps)
> and it seemed a lot easier. We could feed bench data from a curve tracer
(or
> semiconductor analyzer)
> directly into the model without any math, and when you looked model curves
> they were intuitive.
> I know its probably now water over the dam, but I was just wondering....
>
> regards,
> Bob
>
> Cereva Networks
> 100 Locke Drive
> Marlboro MA. 01752
> Phone: 508-486-9660 X 3365
> FAX: 508-486-9661
> Email: rhaller@cereva.com
>
> -----Original Message-----
> From: Mike LaBonte [mailto:mikelabonte@cadence.com]
> Sent: Friday, July 07, 2000 8:28 AM
> To: ibis-users@eda.org
> Subject: Re: Subtracting clamp curves from pull-up/down curves
>
> Stephen,
>
> Arpad's reply indicates that both clamp curves are indeed subtracted
> to produce pullup and pulldown curves. I can verify the other side of
> your question; that simulators (at least Cadence SPECCTRAQuest)
> re-combine the curves as follows:
>
> low state: pulldown + powerclamp + groundclamp
> high state: pullup + powerclamp + groundclamp
>
> So the clamps are never disabled (unless Submodel is used).
>
> Mike LaBonte
> Cadence
>
> Stephen Nolan wrote:
> >
> > Hello IBIS gurus,
> >
> > When creating a model for a three-state device, it is necessary to
> subtract the
> > clamp curves from the pull-up/down curves to avoid double counting, as
the
> EDA
> > tool adds the clamp-curves back in to the pull-up/down curves to obtain
> the
> > devices output charactersitics in the enabled state. Right so far?
> >
> > The question is this, do you only subtract the corresponding clamp curve
> from
> > the related pull-up/down curve, or do you subtract BOTH clamp curves
from
> each
> > pull-up/down curve?
> >
> > For example, if I am creating the pull-down curve, do I subtract only
the
> > ground-clamp curve, or do I subtract both the power-clamp and
ground-clamp
> > curves? Does the EDA tool add only the ground-clamp data back in, or
does
> it add
> > both curves back in?
> >
> > --
> > Regards,
> > Stephen M. Nolan
Received on Fri Jul 7 08:56:17 2000
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:53:47 PDT