Arpad,
I am interested in your frequency domain work here...
Do the Laplace pole/zero locations vary significantly based on the DC bias
point? If yes, then it seems you are attempting to compare a "small-signal"
equivalent with a "large-signal".
I am reading that you created an equivalent circuit that attempts takes into
account these different bias's, however I didn't think that was possible in
general. Is there a standard procedure to synthesize a circuit given
multiple small signal equivalents? The reason this seems difficult is
because in the time domain, the "small-singnal" model would need to be
changing between the biases in a (perhaps complex) manner.
Basically I am asking how you "morphed" the small-signal equivalent over
time to account for biases.
Chris
-----Original Message-----
From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com]
Sent: Tuesday, March 27, 2001 8:55 AM
To: 'wqzhang@avanticorp.com'; ibis-users@eda.org
Subject: RE: about ibs model's ac analysis
Wenqing,
Your observation is true, but not totally. It is true that the
IV curves of IBIS models are made with .DC or .TRAN mode. This
can only provide a frequency independent impedance (or R) for a
given operating point (voltage). However, IBIS models also have
a parameter called C_comp, which is a primitive way of introducing
some AC characteristics. This C_comp is typically in parallel
with the IV curve's non linear impedance (R), so the overall effect
is basically a parallel RC circuit. With the new feature of C_comp
being split into four parts the situation can get a little more
complicated, but in an AC analysis sense this is still pretty simple.
Now, I agree that this simple RC circuit is not very sophisticated
for a frequency domain analysis. However, in this initial
implementation the emphasis should not be on the buffer's AC accuracy.
The IBIS open forum is already working on improvements to the
specification which will enable us to make more accurate AC models
also (IBIS-X) in the future.
Currently, frequency domain analysis in Signal Integrity Engineering
of digital products (such as computer boards) is used primarily to
detect problems with the characteristics of the interconnects. In
some cases it is desirable to include the driving or terminating
impedances of the buffers and receivers in the AC analysis. When
we have nothing but IBIS models available, it would be useful to be
able to this with the B-elements. However crude it may be, it is
still better than nothing.
On the other hand, since I am working on this issue now, I have discovered
that a MOSFET transistor is actually not all that complicated in terms
of frequency domain analysis. I can replace the transistor with a
one-port equivalent (as if I was looking into it from the die pad)
using a transfer function with two or three terms in the (numerator
and) denominator or with a few poles. (I tried this with the pole/zero,
and the Laplace elements in HSPICE).
I found a problem, though. I ran a pole/zero analysis to find the
poles (and zeroes) of such a one port of a MOSFET. (It didn't have
zeroes). I ran this at multiple DC bias points to be able to include
voltage dependencies. Then I made an equivalent circuit using
voltage dependent resistors and capacitors, and ran a time domain
simulation to see whether the step or natural response of this
equivalent circuit will give me the same result as the original
MOSFET. Well, it DOESN'T! I tried to look for mistakes etc...,
but the only conclusion I get is that the .AC and the .TRAN models
of the MOSFET are not the same in HSPICE, and that is where the
difference comes from. I would like someone interested in this
to verify it for me.
Now, the philosophical question is this: The above story tells us
that the transfer function of a MOSFET is different for the AC and
TRAN modes in HSPCIE. Should they not be the same? If they are
different, my AC analysis will not give me the same picture of what
my system does compared with a TRAN analysis. Is that right?
Arpad Muranyi
Intel Corporation
=================================================================
Received on Tue Mar 27 10:36:10 2001
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:53:47 PDT