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

Mike,

Which version of HSPICE are you referring to?  As far as I know
there is no way in HSPICE to use the results of a .measure statement
as input to any other element, because HSPICE does things in two
passes.  1) simulate, 2) process the .measure statements.  Am I
missing something?

Regarding the AMS language performance issues, you could be right
with the things you say.  However, the last VHDL-AMS workgroup I
attended had an interesting discussion on exactly this subject,
in connection with the need for a $table_model (Verilog-AMS)
equivalent.  The discussion revolved around whether this can or
should be done through packages, or the language itself.  There
was a strong push from some of the vendors who attended to make
it a language feature because the speed improvement that would
bring.

In short, I believe that if and when we run into performance
issues, they can be addressed either by improving the language(s)
or by tool vendors finding really smart and clever ways of coding
it.

Of course, being programming languages, the programmer must also
know what they are doing (putting the least amount of instructions
into the most frequency executed sections of the model).  In order
to achieve this, good programming environments (IDE) are extremely
important and I haven't seen to many of them around yet for AMS.

Arpad
---------------------------------------------------------------------





-----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