Able to significantly reduce design risks, simulating overall system performance does not require expert knowledge of modeling.
By Richard Comerford, Electronic Products
The lesson of ancient Babel still resonates through the halls of design firms today: if you really want to screw up a project, make sure that everyone working on it speaks a different language. Having a common technical language to express design concepts and plans is essential to enabling a team of engineers to work together.
And before everyone goes off to work out the details of their particular part of the design, it doesn’t hurt to do an overall simulation of the design concept. This will help ensure that, when completed, a complex system can do the job for which it was intended.
Unfortunately, that isn’t always the case. As Mentor Graphics design experts Scott Cooper, Mike Donnelly, and Darrel Teegarden observe in their introduction to How to Model Mechatronic Systems Using VHDL-AMS, “Although use of computer models is a key for successful design of complex systems, [we] have observed that engineers are often reluctant to invest the time and energy required to develop such models.”
They believe there are two reasons for this situation. For one, until relatively recently there were no standardized modeling formats available for such work. For another, there is a preconceived notion on the part of most designers that simulation technologies are difficult to use productively, and that building models is even more difficult. The lack of a standardized modeling format was solved by an IEEE standard, the VHDL-AMS hardware description language. Described as rich-featured and powerful, it lets users develop useful models and create meaningful simulations without having to become experts in the language. Then too, it promotes model reuse by allowing users to store models, easily adapt them, and run them on various compatible simulators.
As to overcoming preconceived notions, it’s hoped that the following example based on material from the Cooper-Donnelly-Teegarden work previously cited will help convince designers that modeling is not too difficult.
A VHDL-AMS model consists of two different types of program statements: an entity statement and at least one architecture statement. The entity statement defines the interfaces of the device being modeled in so far as they are relative to the simulation. Through the interface, the model can communicate with other models via its ports (pins). Any external parameters to be used in the model are also declared in the entity statement, and the name of the entity is typically the same as the name of the model itself. An architecture statement defines the behavior of the model. A single model may only have one entity, but may contain multiple architectures, with each architecture statement defining a different type of behavior.
To understand how these statements are created, consider the case of an ideal single-input, single-output power amplifier, whose gain equation is output = K * input. The entity statement for this amplifier would be that shown in Figure 1.
entity amp is generic ( K : real := 1.0 -- model gain, a generic (parameter) declaration ); port ( terminal input : electrical; terminal output : electrical -- port (pin) declarations ); end entity amp;
Figure 1. Entity statement for a simple power amplifier.
In the entity statement (as well as the architecture statement), the keywords for the model are always given in boldface. Comments about the coding are always preceded by “–“, and the
descriptive comment, of course, is not used in the simulation. In the entity’s generic statement, the value of the gain (1) is declared, while in the ports statement, the input and output ports are described. The generic K is declared as type real, so it can be assigned any real number. The value 1 is a default value here, but models do not have to have default values for generics. Note that the entity begins and ends with the name of the model, in this case, “amp”.
Model functionality is implemented in the architecture section (Figure 2), whose first line of declares an architecture called “ideal.” for the entity called “amp.” The model developer chose the name “ideal” to indicate that this is an idealized, high-level implementation. The model’s simultaneous equations and other concurrent statements appear between the begin and end keywords.
architecture ideal of amp is quantity vin across input to electrical_ref; quantity vout across iout through output to electrical_ref -- declarations; begin vout == K * vin -- simultaneous statements; end architecture ideal;
Figure 2. Architecture statement for a simple power amplifier.
In VHDL-AMS, the “==” sign indicates that this equation is continuously evaluated during simulation, and equality is maintained between the expressions on either side at all times. If multiple equations are used in a model, they are evaluated concurrently.
In the architecture statement, both vin and vout need to be declared (K was declared in the entity). Since the electrical terminals (input and output) of this model have both voltage (across) and current (through) aspects associated with them, these terminals cannot be directly used to realize the model equation. Instead, individual objects are declared for each, and these objects are then used to realize the model equation.
In VHDL-AMS, analog-valued objects used to model conserved energy systems are called branch quantities because they are declared between two terminals. Branch quantity vin is declared as the voltage across port input relative to electrical ground, specified as electrical_ref in VHDL-AMS models. Branch quantity vout is declared as the voltage across port output relative to electrical_ref.
In the architecture listing, there no quantity declaration for the input current, since this is supposed to be an idealized voltage amplifier model and acts an ideal load, not drawing any current. Since no branch quantity is declared for this current, the input current is zero. The idealized output can supply any current, so the through quantity iout is declared along with across quantity vout. The simulator will then solve for the instantaneous value of iout needed to ensure vout is the correct value for the expressions in the governing equation: vout == K * vin.
While it is possible to model with much greater complexity using VHDL-AMS, the inherent simplicity of the modeling statements do not create a barrier to their use. Hopefully, you’ll be interested in pursing the language further, in which case the references given in the Appendix will prove extremely useful.
How to Model Mechatronic Systems Using VHDL-AMS, SystemVision Technology Series, Mentor Graphics, Series Editors Scott Cooper, Mike Donnelly, Darrel Teegarden, http://www.mentor.com/products/sm/techpubs/index.cfm
The System Designer’s Guide to VHDL-AMS: Analog, Mixed-Signal, and Mixed-Technology Modeling,. by Peter Ashenden, University of Adelaide, Gregory Peterson, University of Tennessee, and Darrell Teegarden, Mentor Graphics. http://books.elsevier.com/mk/default.asp?isbn=1558607498
“Fundamentals of VHDL-AMS for Automotive Electrical Systems,.” Online workshop presented by Mentor Graphics. Available from the SystemVision websitehttp://www.mentor.com/systemvision