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 1993Received on Mon Apr 4 13:47:49 2005
This archive was generated by hypermail 2.1.8 : Mon Apr 04 2005 - 13:49:44 PDT