| |
 | |  |  | | | | Are your AMS behavioral modeling challenges surmountable?
An interview with Ron Vogelsong
Cadence Design Systems, Inc. | |
| |  | |  |
In your opinion, what are key issues for those developing analog and mixed-signal behavioral models?
I think the number one modeling issue is the proper understanding of analog continuity requirements. That's really the key to many analog convergence and efficiency issues. All too often I've seen models written with "idealized" transfer characteristics, which often result in sharp corners or step discontinuities between regions of operation (active to saturated response, for example). Such abstractions may make the model easy to code and the simulation trivial within each of the regions of operation. But it's the transitions between regions that often cause simulation problems, particularly when there can be some external feedback that would force it to spend time crossing through the transition region. If there's only a sharp corner or discontinuity, it's very likely to cause significant simulation problems (e.g., dc convergence & transient timestep issues).
Signal bounding is another key area. Overly idealized models can result in large, rapid output changes in cases where the block should have been filtering the signal. For example, defining an ideal amplifier with a gain of one million and no frequency limiting means that a tiny numerical oscillation of, say 50 uV at the input, would result in an instantaneous 50 V step at the output. If the input should be forced to a larger voltage, say 0.1 V, the output would immediately soar to 100 KV. Without the high-frequency filtering and large-signal limiting effects that naturally occur in real devices, such a model can cause huge problems in some simulations.
The other significant area to be careful of is developing models that force excessive numbers of timepoints to be evaluated. The primary culprit here is the @cross event. Its purpose is to tell the behavioral model to execute some block of code whenever a particular analog expression crosses through zero, which is a very useful way to define an event-driven type of operation. But the thing to look out for is that whenever a crossing is occurring, this function actually requires the simulator to iteratively compute timepoints—that is, full operating points for the entire system at each specific point in time—and search until it finds the point that is within a very tight tolerance of crossing zero for that expression. You can generally expect it to take the equivalent of two to four additional timepoint evaluations each time a crossing is sensed. So the @cross should only be used when high accuracy is important, and even then you should always specify a reasonable voltage and time tolerance for it (see the manual for @cross syntax). Otherwise, if seeing the event at the next timestep the simulator normally would take is sufficient, then, "if" statements can be used to perform similar operations with no simulation time penalty.
How do you know when a behavioral model has enough detail? What rules of thumb do you use? What criteria do you use to balance accuracy and simulation time?
Generally, it's the usage of a model that determines how detailed it needs to be — there is no solid line that determines when you're done. However, here are some general rule-of-thumb suggestions:
- Things that the user would logically assume to be a part of the model should be in there: e.g., primary transfer relationship & primary limitations.
- Basic output impedances and dominant overall frequency responses should be included on all analog outputs, which greatly helps to catch loading issues.
- Things that commonly cause problems and are easy to check for should be included in the model: e.g., check for proper supply voltages and bias levels and then print warning messages when things aren't right! (Note that this makes the behavioral model much MORE valuable than a transistor-level model - it tells you when you use it wrong!)
- Document in the model what IS and what ISN'T modeled there! If you don't know, you're not done modeling yet. Without that info, the model cannot be effectively used - people will always make wrong assumptions.
- If the behavioral model isn't significantly faster than the circuit-level model, then adding more features is probably not useful. What you may want to do instead is more carefully test the model to see WHY it's so slow, and possibly fix that.
- If the features you're considering adding will only benefit a small portion of the simulations to be performed, it's likely easier to use the transistor-level implementation for those few cases than to spend the additional time required to improve the model.
- Remember that not everyone needs the same model complexity. Practice making a simple model, then copying to another view name to add additional features that could significantly slow it down. Both models should contain documentation as to what they do and don't do, so that anyone using them can choose which they want.
How much speed improvement can one reasonably expect when doing solid, accurate behavioral models?
Actually, that's a trick question. Speed improvement isn't very closely related to how accurate the behavioral model is. The two primary things that limit the speedup using behavioral models are how much analog circuitry has been replaced, and the relationship between the average timestep sizes needed to run the behavioral model versus what was needed to run the original circuit. The total amount of time required to actually compute the quantities in the behavioral model is often a small percentage of total simulation time, so adding a few extra terms in the model to accurately describe circuit performance can result in greatly improved accuracy with very little change in simulation speed compared to a much simpler model.
When large parts of a system are replaced by behavioral equivalents, it's not uncommon to find that it only takes 1/2 to 1/5 of the total number of timepoints to complete the simulation, since the extremely detailed transistor-by-transistor effects that caused overly small timesteps to occur in the circuit model will no longer be an issue. At the same time, the overall complexity of the system (as measured by number of elements, nodes, or equations) could easily be an order of magnitude or more reduced, which can lead to each timepoint evaluation only taking 1/5 to 1/20 of what was required at the circuit level. It's therefore common to see overall speedups in the range of 10x to 100x for typical systems.
Certain types of systems can have much greater speedup. If a portion of the system required an extremely small timestep size to accurately simulate some detailed internal operation, a behavioral model might be written that only defines the overall effect needed without requiring that portion of the operation. For example: a low-pass filter implemented in a high-frequency sampled data system could be replaced with a continuous time ideal filter. Also, in PLLs for example, putting all oscillating signals into the digital environment can result in much quicker analog simulation times.
Some circuits, such as programmable-gain amplifiers, can require hundreds or thousands of transistors to perform what is a simple one-line definition in a behavioral model, thereby garnering speedups of 100x to 1000x is some cases. On the other hand, if you have a simple amplifier built out of a dozen or so transistors, and you use a highly accurate behavioral model that includes high-frequency gain and phase relationships, large-signal slew rate, output impedance versus frequency and bias, common mode rejection, etc., it's not uncommon to find that the behavioral model takes as long to simulate as the transistor-level model does. That doesn't mean the behavioral model isn't still valuable - it can still be used to determine what characteristics a block needs to have before the system is implemented, as well as show how parametric variations in module behavior would effect system operation.
What are some pros and cons of Verilog-AMS and VHDL-AMS?
The big pro for either of them is that you can define both the analog and the digital portions of your system in the mode that's most natural for them, and define in a single module exactly how they interact with each other. So they're the languages of choice for D/A and A/D converters, VCOs, frequency-to-voltage transformation (e.g., PLLs), and generally any analog block which contains significant digital control (enable, latch, mode, programmable gain or filter coefficients, etc.).
For all-analog blocks, the language of choice is Verilog-A—it is the industry standard for analog behavioral modeling, and will likely become even more common in the future as it's extended for device modeling applications.
In the digital domain, both Verilog and VHDL have their separate sets of loyal fans, which is not likely to change any time soon. As such, the respective audiences tend toward mixed-signal design with Verilog-AMS or VHDL-AMS respectively.
As a design-based user, I've always found the syntax of Verilog-AMS to make more sense to me personally. It is very closely related to how models were developed decades ago, using linear and nonlinear dependent sources in SPICE subcircuits. I spent much of the 80s and 90s working on that form of behavioral modeling (macromodeling), and immediately recognized in Verilog-A that the contribution operator is directly analogous to a nonlinear dependent source which I can now write out an expression for. If you draw a subcircuit with the definitions of how to compute the sources and impedances in that topology, you'll discover it's a very easy step to implement in Verilog-AMS.
VHDL-AMS, on the other hand, bases its analog modeling format on writing simultaneous equations. While that may be natural for certain types of modeling tasks, I find it to be much more confusing when the models start becoming complex. I just haven't found a case in behavioral modeling yet where I needed a system of many simultaneous equations to properly format the model. I automatically formulate the description in the form of a topology I'd use to implement the model: I see it in terms of currents and voltages in some topological connection, not N equations in M unknowns.
I have heard from someone who was doing modeling for micro-electro-mechanical devices (MEMs) who felt it was easier to implement the equations of motion using simultaneous equations (they require conversion to an integral form to write out in the coding style of Verilog-AMS). Same thing goes for developing detailed device models based on fundamental device physics principles. Those are particular fields where large numbers of interdependent nonlinear differential equations are defined in the literature with less-than-obvious conversion to a specific potential vs. flow description of the problem. But for common usage for system-to-block-level behavioral model implementation, I think the Verilog-AMS language is much more accessible to the typical user.
How long does it typically take to write a behavioral model for a cell?
My general answer is "somewhere between two hours and two months". I've worked on cells that fall throughout that range of times. How long it will take depends very strongly on how many features you have to develop for it. If it's a very simple model that only takes a few lines of code to describe a transfer relationship, or if you already have a similar model laying around, it may take at most an hour or two to make a few minor tweaks and run a simulation to check that it works as expected. On the other hand, modeling highly complicated analog systems with many modes of operation, nonlinear DC characteristics, complex frequency response interacting with large signal transient limitations, etc. can take many weeks to fully develop a model.
One of the biggest differentiators in how long a modeling task will take for a reasonably complex cell is how long it will be before you understand what it is the model needs to do. A description of what a few of the key parameters are often gives little or no insight into what needs to go into a model. I've worked on many modeling tasks in which, given the transistor-level cell, I spent several weeks developing test benches and running simulations to understand how the controls affected the various signal paths through the module. THEN I started developing a model for it. On the far end of the spectrum, I've spent a half hour talking to the designer of the block about exactly how it worked, given a complete description of what all the pins did, what needed to be modeled, what effects I could ignore, and also given test bench schematics specifically used to check out the operation of that cell as they expected it to be used. In less than a day I was working on the behavioral model.
One of the misconceptions of behavioral modeling is that it takes a long time to build a model. Actually, the time spent coding the model is generally only a small part of a behavioral-modeling effort. In my experience, the timeline of a typical modeling task often looks something like this:
- 25% definition (deciding what features the model should have);
- 10% implementation (deciding how the model will do that);
- 5% coding (writing the code to do the implementation);
- 60% verification (building, running, and debugging testbenches to verify operation).
That's right - generally over half of the time is spent trying to prove that the model does what it's supposed to do. It's therefore relatively easy to fill libraries with lots of models that might work, but very hard to deliver fully functional models unless sufficient time is allocated for model verification.
How long does it take someone to learn how to use AMS modeling?
There are a couple of different ways to answer that question:
1) Anyone can immediately use AMS models written by others - they're just parameterized models that plug directly into your simulation (you can use the hierarchy editor to choose which view to use for each block). This of course assumes that the person who wrote the model actually took the time to document what it does and what its parameters mean, so that it can be used effectively.
2) You can get started doing your own AMS behavioral modeling in as little as a few weeks. Figure a few days for the Verilog-A class, a few days to polish up on the digital Verilog language if you haven't worked with it lately, and a few more days for the Virtuoso AMS Designer training (which includes some mixed-signal model development tasks). At that point, you've been exposed to the basics of what you need to do, so you can begin AMS-modeling tasks. The trouble is, in the beginning, you won't be very good at it, because there are a whole lot of trial and error experiments involved in figuring out what's the best way to model things, and a lot of experience is needed before you can look at a block's operation and know how you'd want to model that. Sooo...
3) Once you've been through the basics defined above, look for some references that will help you get a good idea of how to model various types of cells. Here are some useful resources:
- Look in the Cadence libraries you have available: For example, ahdlLib contains a few hundred Verilog-A models; bmslib has another hundred or so models in both the Verilog-AMS and Verilog-A format; and don't forget that ModelWriter also can be used to generate Verilog-A templates for a variety of cells. Pick some type of model you're thinking of working on, pull up some example models, read through them and try to understand what they do. Build test circuits around them, simulate them, and see if they do what you think they did. Much can be learned just by looking at the many ways things have been implemented, and you can usually start with one that you understand and modify it to get a block out that does what you want without too much effort.
- Several books are available as well: Dan FitzPatrick & Ira Miller's "Analog Behavioral Modeling with the Verilog-A Language" (Kluwer 1998) does a reasonable job of working through the basic Verilog-A syntax and a bunch of examples; Ken Kundert & Olaf Zinke's "The Designer's Guide to Verilog-AMS" (Kluwer 2004) provides a good introduction to the Verilog-AMS language and also provides many examples.
- And, hopefully you can catch the AMS Behavioral Modeling Workshop that I've provided a few dozen times over the last couple of years (including every year at the International Cadence User Group meetings since 2001), which tries to introduce you to the best practices and significant gotcha's involved in analog and mixed-signal behavioral model development.
4) Finally, in order to become a competent modeler, you must spend considerable time modeling. If you can only spare a few hours a week to spend on developing models, you'll probably never get to a point where you're really comfortable with it - there's too much to learn to retain it all at that rate. You really have to be able to dive in and work on modeling for a reasonable part of your day for months to get to the point where you can quickly understand what you need to do. That's why most companies who are doing this right will have several people on staff that spends a good part of their time doing behavioral modeling. Those people get good enough in a reasonable amount of time to be able to get the job done, and then others who need to do some modeling on a less-frequent basis can come to them to get the help they need.
If your company is just getting started in this area, it will be of paramount importance to initially get external help in this regard, so that you can get started with some good models and have a ready resource to bounce the "How do I do this?" and "What did I do wrong?" type questions off of. Help is available through Cadence Engineering Services engagements (we have several good modelers on staff). Without such a resource, it's all too easy to waste large amounts of time debugging basic modeling problems, while having sufficient support available means you'll be able to concentrate your time on learning how to model more effectively.
| 
About the author
Ron Vogelsong has been active in analog macro/behavioral modeling since 1980. [At that time, adding a behavioral model into SPICE2 involved writing Fortran code to handle ALL the operations required: keeping track of states in the presence of transient iterations & backsteps, and computing partial derivatives to properly load the conductance matrix, were significant parts of the behavioral modeling process. It's a whole lot easier now!]
He received a Ph.D. from the University of South Florida in 1985, and continued as a professor there until 1990, when he became part of Harris Semiconductor's Fastrack Design Systems team, developing extensive libraries of parameterized behavioral models to support a Top-Down Design methodology. He joined Cadence in 2001 to focus on analog and mixed-signal behavioral model development.
In his spare time, Ron is an accomplished musician (B.A. in Music at USF in 1978). He performs with and writes arrangements for a variety of ensembles, including a Dixieland band, various brass ensembles, Church orchestra, Gospel quartet, and several Handbell choirs. |
| |
This content has been rated 5 out of 5 by other users |
|
|
|
|
|