First, what is AMS behavioral modeling?
I define it as “a set of user-defined equations that decribe the terminal behavior of a component”. [Without “user-defined” in there, it would apply to every SPICE model]. When some people talk about behavioral modeling, they immediately start talking about AMS languages. It’s the equivalent of talking about the English language in a discussion of the latest John Grisham book. Important for its creation, but irrelevant to the content.
Behavioral modeling is simply a technique for creating a model – one arrow in the modeler’s quiver. Another technique is Macromodeling – the use of previously defined blocks to create a new block. A superb example of macromodeling is the well-known Boyle-Solomon op amp model  that simply puts together SPICE elements based on a deep, thorough understanding of the op amp’s structure and behavior.
AMS designers are comfortable with macromodeling, because it uses interconnected building blocks just like a typical schematic – it is a straightforward extension of what they do every day.
Behavioral Modeling, on the other hand, requires learning that damn language and developing a set of equations. It is intimidating for at least 3 reasons:
- AMS designers are not linguists, they are primarily superb assemblers of components
- Developing a set of equations is a lot harder (and takes longer – a real problem in today’s environment) than assembling pre-existing blocks
- Behavioral modeling (actually, any type of modeling) tests the designer’s real understanding of the device – often more deeply than they want to admit
In summary, it is off the beaten track for an AMS designer to develop a behavioral model from scratch – for some, way off the beaten track. The way around this is to work with previously-created behavioral models as a starting point – either do simple modifications or use it as a template. The more popular way around it is to have someone else (a modeler) develop the model to the designer’s specifications. Turn it into another building block that the designer can use.
Show me a good AMS designer and I’ll show you a good AMS modeler.
I believe AMS designers would love to talk about models – what’s in them, their accuracy, their deficiencies and how they can be improved. But I suspect the discussions on AMS languages, when they are expecting a discussion about models, are not of interest to most AMS designers – and may even be a turn-off. Am I right?
 G. R. Boyle, B. M. Cohn, D.O. Pederson, J. E. Solomon, “Macromodeling of Integrated Circuit Operational Amplifiers”, IEEE Journal of Solid-State Circuits, Vol SC-9, No. 6, December 1974, pp.353-364.
<script type="IN/Share" data-counter="right"></script>