[ibis-macro] Re: BIRD-124: Dependency tables - question?
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Mon, 17 Jan 2011 09:17:26 -0800
Mike,
This is exactly why a buffer control setting (register) referring
to signal swing (in voltage) is wrong or close to useless. The
actual signal swing will always depend on the loading conditions,
as in a voltage divider. Of course, the lower the buffer impedance
and the higher the load impedance is, the smaller the variation in
the actual signal swing will be between the loaded vs. unloaded
conditions, but since we want to have matched impedances to reduce
reflections, the buffer and load impedances are pretty close to
equal in our applications. This makes the loaded vs. unloaded
signal swings quite different. This is why referring to drive
current (instead of signal swing) makes a lot more sense in describing
the buffer's drive strength.
Referring to my previous message, this is what will also shift the
bias point of the buffer. So I would tend to disagree with you that
I was "...going off the rails pretty early in your [my] discussion. So
the rest of your [my]
conclusions are not valid.".
In light of your last message, the only thing I can see differently
now is that you are suggesting to select a buffer model from the
Dependency Table based on its register setting, not its actual voltage
swing. On the other hand, I was talking about actual voltage swings,
the two of which may be quite different based on the loading conditions.
As a response to Kukal's email, you wrote the following:
"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."
I can see how the swing setting (in the register) changes the bias point
because the buffer's impedance is changing with that swing setting. But
you also said that the bias point changes the output impedance of the
buffer. This has nothing to do with the register setting, this is a
non-linear I-V relationship, just like in good old IBIS. Since the bias
point is also determined by the load (not only the register setting), I
would conclude that your model selectors would also need to include this
effect, which they apparently are not, or if they do, they do it through
the model selector mechanism, which is a static selection that cannot
possibly involve the effects of the load impedance. This is what I was
commenting on in my previous message.
Thanks,
Arpad
========================================================================
===
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger
Sent: Monday, January 17, 2011 8:45 AM
To: Dmitriev-Zdorov, Vladimir
Cc: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: BIRD-124: Dependency tables - question?
Vladimir-
Perhaps I should have been more precise when referring to "swing". There
are two closely related but distinct concepts:
1. Swing: The peak to peak differential voltage measured at the output
of a driver.
2. Swing: A register field in a driver's configuration address space
that is used to adjust the output amplitude of the driver.
- This register field usually either modifies the bias point of the
output stage or enables/disables independent output stages.
You're referring to definition #1 and I was referring to definition #2.
Let's apply a different name to definition #2. Let's call it "swing
configuration".
With respect to definition #1, your comments are correct. The actual
output amplitude is a function of both the load impedance and the driver
output impedance.
The comment I was making was with respect to swing configuration (#2).
Driver output impedance is a function of swing configuration, but is not
significantly affected by load impedance.
It's important to specify the correct value for the driver output
impedance not just because it's necessary to calculate the correct
output swing, but because it's necessary to calculate the correct
reflections for a range of possible interconnect networks. This affects
the waveform shape every bit as much as it does the amplitude,
especially considering that the load impedance at high frequencies can
be very different from the load impedance at DC. Supplying the driver
output impedance via a dependency table is a simple, flexible and
effective way to achieve this goal.
Cheers.
Mike S.
On 01/15/2011 04:25 PM, Dmitriev-Zdorov, Vladimir wrote:
Mike,
When you are talking about output driver impedance and load impedance,
do you mean the differential component only of both, differential and
common?
I can imagine the driver in which the output impedance measured
differentially does not depend on the differential load (or dependence
is small). The example you provided is perfect. However, what if the
common mode load impedance can be anything between 25 Ohm and infinity?
As you mentioned:
> The common mode output voltage does need to be defined, as it does
affect output swing by perhaps as much as 20%
Just trying to understand. Doesn't the common mode impedance of the load
affect the common mode output voltage? Then, the common voltage affects
the swing, the swing affects the output differential impedance?
Vladimir
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx on behalf of Mike Steinberger
Sent: Thu 1/13/2011 2:34 PM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: BIRD-124: Dependency tables - question?
Arpad-
You're going off the rails pretty early in your discussion. So the rest
of your conclusions are not valid.
The bias point of the output transistors in a driver is affected only
minimally by the load impedance. That effect can be safely ignored in
most designs, and is clearly not a factor in AC coupled links.
We've run the SPICE decks for a lot of different drivers for a lot of
different swing settings and several different load impedances, and this
is what we see: The differential output impedance typically is about 100
ohms for low swing settings, going down to around 70 ohms (or lower) at
high swing settings. The common mode output voltage does need to be
defined, as it does affect output swing by perhaps as much as 20%;
however the load impedance has only a negligible effect on the output
impedance of the driver.
When the swing of a driver is set, it's set internal to the driver. In
many cases, the swing is set by a tail current source supplying a
differential output pair. The current supplied by the tail current
source sets the bias current for the output transistors. That bias
current pretty much directly determines the output impedance of the
transistor. The output impedance of the driver transistors usually ends
up in parallel with other, fixed circuit elements such as pull-up
resistors, and all of these elements in parallel determine the output
impedance.
What typically happens is that to produce higher output swings, the bias
current is increased, with the result that when the driver transistor
pulls down to a lower voltage, making it behave more like a triode and
less like a current source. That's why the output impedance goes down.
If you think something else is happening, then please show me the data.
Mike S.
On 01/13/2011 04:03 PM, Muranyi, Arpad wrote:
>
> 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:
