RE: [IBIS] *-AMS solves all of IBIS problems?

From: Tom Dagostino <tom_at_.....>
Date: Mon Apr 04 2005 - 14:19:13 PDT
There was a concept that we used to use when I worked at Tektronix, it was
the concept of "conservation of agony".  A good example is trying to make an
ADC twice as fast is as difficult as trying to double its resolution.

The same kind of conservation applies to the advanced languages.  IBIS works
very well as a simple driver receiver modeling language in its original 2.1
version.  Many people have used it successfully as it was intended.  As the
world become more complex the effort required to make IBIS more robust
increased significantly.  As IBIS's ability to accurately model advanced
behaviors its simulation time has increased.  *-AMS is going to have the
same kinds of issues.  Yes, we can develop AMS models that perform as well
as IBIS models using the same complexity of an IBIS model if we are willing
to live with those limitations.  But as we try to get to the detail that
people expect of SPICE, we are going to see increased model complexity,
increase simulation times, increased model development cost/time and
increase difficulty in understanding how the model works.  SPICE works as
well as it does because of the complexity of the description, every single
element that has any possible affect on the performance of the circuit has a
place in the SPICE description of that buffer.  We pay for that in
simulation time.  If the expectation is that an AMS model will perform
exactly the same as the SPICE description under all conditions then there is
going to have to be the same level of complexity in the AMS model as in the
SPICE model.

The trade-off that we need to think about is what is good enough for the
application at hand.  Many people will find an IBIS 2.1 or 3.2 model will
have excellent performance in the problem they are trying to solve.  Others
will need the ability of describing effects that SPICE offers.  AMS models
will have to be designed for the level of need required to model the buffer
of interest.  It is not good enough to show an AMS model replacing an IBIS
2.1 model and saying, "hey, it works".  Nor is there any sense in going back
and replacing old IBIS models with new AMS model offering the same
performance.

So far the AMS offering to the SI community has been "here is a technology
that will solve all of the problems with IBIS and SPICE".  So far it has
been a technology.  What is needed is a solution.  A solution is something
that can be applied to most of the problems users encounter without having
to "roll your own".  Example models, tools to help make models, analysis of
what kinds of effects that need to be modeled and what is not needed all
need to be presented to the community.

Tom Dagostino
Teraspeed Labs
13610 SW Harness Lane
Beaverton, OR 97008
503-430-1065
http://www.teraspeed.com
tom@teraspeed.com

Teraspeed Consulting Group LLC
121 North River Drive
Narragansett, RI 02882
401-284-1827

Teraspeed is the registered service mark of
Teraspeed Consulting Group LLC

-----Original Message-----
From: owner-ibis@eda.org [mailto:owner-ibis@eda.org]On Behalf Of Mike
LaBonte
Sent: Monday, April 04, 2005 1:47 PM
To: 'ibis'
Subject: RE: [IBIS] *-AMS solves all of IBIS problems?


I think I see where Scott is coming from. The lines of AMS code that call
hard-coded primitives will simulate very quickly. The lines that call
interpreted instructions, table lookups and equations will simulate
exceedingly slowly. The overall performance will depend on the mix of these.
It can potentially cause an AMS model with relatively few lines to simulate
more slowly than a complex HSPICE model with more lines.

For illustration imagine an HSPICE circuit with a good number of .measure
statements and many equation-style controlled sources that use the .measure
outputs. My experience is that this can be horribly slow. An AMS model might
look like that. Analog simulators are able to optimize convergence for
circuits built only from primitives. The rational approximations used to
iteratively home in on the matrix values for the next time step are well
known. Simulators are less able to do this with more flexible language
elements.

The key to AMS performance may lie in using as few as possible of the
general purpose language constructs that make it so flexible. But for many
people those constructs might be the easiest to use. To make a fast AMS
model one may have to "be the simulator". But no one said it would be easy.

Mike

________________________________

From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Scott
McMorrow
Sent: Monday, April 04, 2005 3:27 PM
To: Muranyi, Arpad
Cc: ibis
Subject: Re: [IBIS] *-AMS solves all of IBIS problems?


Arpad,

See my comments in blue:

scott


Muranyi, Arpad wrote:

	Syed, Scott,

	I renamed that ugly subject line of mine... and would like to
	respond to this quick quote from Scott:



		...that the implied assumption that AMS modeling will
somehow solve
		all of our IBIS modeling problems is sorely mistaken.



	I will take that blame on myself, because I feel quite optimistic
	about AMS these days, and may have said things that come across
	that way.

	I would like to ask Scott, please give some examples for why not.
	Or can I take your next sentence as an example?



Thus far, all of the "correlations" between *-AMS and either HSPICE or
measurements have been rather simplified models.  Quite frankly, when you
take a look at the Altera correlation, it ain't that close to measurement
either, and it's not clear whether it is the interconnect modeling and
simulation that is at fault, the power delivery modeling, or the device
modeling.  We've found not just a few SerDes drivers which operate quite a
bit differently than even their HSPICE models of just the driver would
predict, when transmitting long differential data streams.  We suspect that
the differences between modeling and measurement occurs because of lack of
package power delivery modeling, and integration of this  into the driver
model.  Once you add the full power delivery path and a quad-SerDes into the
model, will the results be that encouraging?  I hope so. However, I am on
record as having misgivings. Personally, I think that correlations of *-AMS
should start at this level of complexity, so that a fully correlated
solution is shown, before delving into model order reduction techniques to
speed  up performance.
..


			Interaction between the silicon and that pesky
passive
		interconnect must be dealt with simultaneously, if we are to
believe
		that our simulation results have true high-fidelity to
measured
		results.



	Why would this not be solvable by writing models with *-AMS?
	The way I see it, this is really just up to the model writer
	what they characterize and how it is written up in the *-AMS
	model.  It doesn't seem to be a language limitation to me.
	Am I missing something?


You are not missing a thing. I believe that *-AMS can be used to model
anything.  The question is whether it will be competitive with HSPICE in
performance once all of the imporatant details (gate modulation, feedback,
power starvation, resonances, frequency dependent power delivery, etc ...)
are modeled.  This is the unresolved question.  My gut tells me no, since
*-AMS is designed to be a more general language.  I will be happy to learn
that I am wrong.


	Arpad
-----------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a request to ibis-request@eda.org.
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993

-----------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or email a request to ibis-request@eda.org.
|
|IBIS reflector archives exist under:
|
|  http://www.eda.org/pub/ibis/email_archive/  Recent
|  http://www.eda.org/pub/ibis/users_archive/  Recent
|  http://www.eda.org/pub/ibis/email/          E-mail since 1993
Received on Mon Apr 4 14:22:22 2005

This archive was generated by hypermail 2.1.8 : Mon Apr 04 2005 - 14:22:43 PDT