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