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

  • From: Mike Steinberger <msteinb@xxxxxxxxxx>
  • To: ibis-macro@xxxxxxxxxxxxx
  • Date: Thu, 13 Jan 2011 16:34:15 -0600

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:

  1. Home
  2. ibis-macro
  3. Archive
  4. 01-2011