[ibis-macro] Re: BIRD-124: Dependency tables - question?

  • From: "Tom Dagostino" <tom@xxxxxxxxxxxxx>
  • To: <msteinb@xxxxxxxxxx>
  • Date: Mon, 17 Jan 2011 11:58:25 -0800

Mike

 

Like I said I assumed it was CML and I assumed there were internal 50 Ohm
pullups in the drivers.  What I could not understand was your comment about
the load on a CML driver having any affect on the internal bias points of
the driver.  My mental model of a CML drive is a collection of current
sources that are switched back and forth.  I'm not sure how internal bias
points are changed.  The current sources are turned on or off depending on
the configuration and the output stage just switches them between the two
sides.  Or is my model wrong?

 

Regards,

 

Tom Dagostino

Teraspeed Labs

13610 SW Harness Lane

Beaverton, OR 97008

503-430-1065

tom@xxxxxxxxxxxxx 

www.teraspeed.com 

 

Teraspeed Consulting Group LLC

121 North River Drive
Narragansett, RI 02882

401-284-1827

www.teraspeed.com  

 

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger
Sent: Monday, January 17, 2011 11:39 AM
To: tom@xxxxxxxxxxxxx
Cc: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: BIRD-124: Dependency tables - question?

 

Tom-

CML is the circuit configuration I referred to in my previous example,
though I did tacetly assume pull-ups in the driver because that's what I
usually see.

Thanks for the question.
Mike S.

On 01/17/2011 01:30 PM, Tom Dagostino wrote: 

Mike

 

What kind of driver technology are you referring to in your example here?  I
would have assumed CML?

 

Regards,

 

Tom Dagostino

Teraspeed Labs

13610 SW Harness Lane

Beaverton, OR 97008

503-430-1065

tom@xxxxxxxxxxxxx 

www.teraspeed.com 

 

Teraspeed Consulting Group LLC

121 North River Drive
Narragansett, RI 02882

401-284-1827

www.teraspeed.com  

 

From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Mike Steinberger
Sent: Monday, January 17, 2011 10:57 AM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: BIRD-124: Dependency tables - question?

 

Arpad-

Every circuit node has a bias point. Some of the important circuit nodes are
at the output of the driver, and other important circuit nodes (not directly
visible from the IBIS model) are internal to the driver.

You're referring exclusively to the circuit nodes external to the driver.
There, the bias point is set by the biasing internal to the driver, and may
also be affected by a _DC_ common mode termination voltage and _DC_ load
impedance external to the driver, depending on the specific circuit design.
This _DC_ bias point must be set correctly when characterizing the driver,
and the assumption underlying the (linear) IBIS-AMI model is that that is
the bias point that will be set in the actual circuit.

The circuit nodes directly affected by the driver's swing configuration are
typically internal to the driver. They are not directly affected by the load
impedance. Yet it is the bias point of these internal nodes that have the
largest effect on the output impedance.

I'm also not sure where you're going with your comments about reflection
coefficient. To be sure, we want to have matched impedances, as you say, but
unfortunately we don't always achieve that, especially at high frequencies.
We don't want to base a modeling strategy on a set of assumptions we can't
be sure are valid. The assumptions we are currently using are sufficient to
produce accurate results, presuming that an accurate value is supplied for
the driver output impedance. That's where the dependency tables come in.

Mike S.

On 01/17/2011 11:17 AM, Muranyi, Arpad wrote: 

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: