[ibis-macro] Re: BIRD-124: Dependency tables - question?
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Thu, 13 Jan 2011 14:03:07 -0800
Mike,
Aside from the usefulness of the Dependency Table, there is
a pretty fundamental technical problem here.
You say that the most critical application of the Dependency
Table is the driver impedance selection because the impedance
of the driver changes with the bias point. (This basically
means that the driver model is not linear, which I will come
back to later). However, the bias point of a driver depends
on the load impedance connected to the driver. The problem
with selecting different impedance models using a model selector
mechanism is that the controlling input to this model selector
doesn't know what the load is on the driver. It is just a
blind selection without actually solving the circuit operating
point. The circuit's operating point can change drastically
depending on what kind of termination is used (parallel, or series)
and what the termination voltage and resistance values are. It
also depends on whether the channel has series AC decoupling
capacitors. None of this information is considered when the
selection is made with the model selector (with or without the
Dependency Table), so the results of the selection may end up
being very inaccurate.
An analogy is a simple voltage divider. Consider a Thevenin
voltage source and resistor "driving" a load resistor. How
can you solve for the correct voltage between the two
resistors without knowing the load resistance?
In the non-linear case this is even complicated further because
the solution of the voltage divider is not just an algebraic
equation.
If you say that the driver impedance changes due to the bias
voltage, you are talking about an I-V curve which is not a
straight line. When you make a different linear model at
different bias points, you are basically making a linearized
model at the various points of the I-V curve. This is what
a small signal AC analysis does in SPICE without the user
having to go through a model selector mechanism. But this is
also what can be done with our good old non-linear I-V curve
based IBIS [Model]s.
I wonder why are we then proposing linear S-parameter based
buffer models with a bunch of highly inaccurate model selectors,
when the I-V curve based model would do the same much more
accurately automatically, without manual selections?
The partial answer to this question is that an I-V curve describes
the impedance as a function of voltage, but S-parameters describe
the impedance as a function of frequency. It seems that we would
like to have both. I wonder if there is a way to combine these
two into a single representation...
Arpad
===================================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger
Sent: Thursday, January 13, 2011 9:00 AM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: BIRD-124: Dependency tables - question?
Kukal-
There are several useful applications for dependency tables; we do quite
often use the application you mention It's more useful than you
imagiine. The most critical application, however, is setting driver
impedances.
As you may know, the output impedance of a driver typically changes with
the swing setting. That is, changing the swing setting changes the bias
point, which changes the output impedance of the transistors. Therefore,
as we do state in Opal(TM), both the algorithmic and the analog models
need to know what the swing setting is. As a matter of good software
engineering, it would be best if both models got their information from
a single user input.
One could imagine a number of ways to solve this problem, but dependency
tables are a particularly simple and flexible solution.
Mike S.
On 1/13/2011 2:11 AM, Taranjit Kukal wrote:
Hi,
The dependency tables would be useful only if we want to keep same
AMI-code (dll) and just change the dependency outside of the code using
.ami file.
However, I do not see this as common use-model - I would assume that all
such dependency should be handled inside of c-code (Algorithmic...) and
that we should avoid overloading of .ami file such tables. AMI-code
should be able to handle such dependency by coding the right values for
dependent parameters based on Key parameters in ami file.
Please let me know if I am missing a use-case where this cannot be
handled inside the dll.
rgds
..kukal
Taranjit Kukal | Product Engineering Architect
P: 91 120 3984000 www.cadence.com <http://www.cadence.com/>
Other related posts:
