One of the great values of modeling with a hardware description language is simply this: you can tell a model to calculate and report all sorts of information about what’s happening inside it. Consider a generic electrical model, for example. Simulators will report voltages across and currents through the device. But what if you want to know how much power is dissipated in the device? Or if the power exceeds a preset limit? Or maybe if the part is overstressed and possibly fails? And what if you want the device behavior to change on failure? With the right hardware description language and simulator combination, you can model and analyze all of these device characteristics and more.
VHDL-AMS is among the most flexible and powerful hardware description languages available for modeling device behavior, and it’s an IEEE standard so it’s supported by more than one tool vendor. I’ve talked about various aspects of VHDL-AMS in earlier blog posts:
- VHDL-AMS Model Portability – Fact of Fiction?
- Qualities of VHDL-AMS Quantities
- VHDL-AMS Black Belt
- What’s the “AMS” in VHDL-AMS?
- VHDL-AMS and Switch Hysteresis
- VHDL-AMS Revisited
Among its many strengths is the ability mentioned above – you can tell your models to calculate operation details that normally might not be available with other modeling languages and methods. I’ll use a simple resistor model to illustrate what I’m talking about. Before jumping into the modeling discussion, however, let’s quickly review a few VHDL-AMS fundamentals:
- VHDL-AMS is a superset of the VHDL digital modeling language. If you can model a device’s behavior in standard VHDL, you can model the same behavior in VHDL-AMS. VHDL-AMS simply adds analog and mixed-signal extensions to VHDL.
- VHDL-AMS models are constructed in two parts: the ENTITY and the ARCHITECTURE. The entity defines how the model will connect to other models in a circuit or system. The architecture defines the device behavior. A device model can have multiple architectures, but only one entity. The entity and one or more architectures work together to determine how the model behaves during a simulation.
- VHDL-AMS is a strongly typed language, meaning most elements in a model must be associated with a physical type. For example, the pins of my resistor model example will be defined as electrical type. Typing is important since VHDL-AMS is a multi-physics modeling language, meaning it’s suitable for modeling electrical and non-electrical behavior. Simulators use this typing information to check for correct connections (e.g. to prevent you from connecting an electrical pin to a hydraulic pin) and to determine what physical units to use when plotting waveforms (e.g. so voltage across and current through my resistor are plotted in units of volts and amps respectively).
- A VHDL-AMS “quantity” is an analog element in a model that is calculated by the simulator. For example, the voltage across and current through my resistor will be defined as quantities for my model. I can also define other quantities such as power and self-heating temperature. VHDL-AMS quantities are assigned a type, either by association (e.g. by port declarations) or explicitly in the quantity declaration (e.g. power or temperature).
With this short review in mind, let’s take a look at my resistor model. Recall from basic physics (or your first electrical circuits class), that the electrical characteristics of a resistor are defined by Ohm’s Law:
voltage = current x resistance
In other words, the voltage across a resistor is equal to the current through the resistor multiplied by the resistance. So with a constant resistance, an increase in current produces an increase in voltage proportional to the resistance. I’ll use this simple equation as the foundation for my resistor model.
Deciding how to start building a model is partly determined by personal preference, and partly by model complexity. For device behavior defined by complex mathematics, it is often easier to define the architecture first, then build the entity to support the architecture. But since my model is based on a simple equation, I’m going to start by defining the entity. Just like a real resistor, my model will have two ports (e.g. p1 and p2) and a resistance value (e.g. res). Here is what my entity looks like (note that I’ve added line numbers for ease of reference):
1: library ieee;
2: use ieee.electrical_systems.all;
3: entity resistor is
4: generic (
5: res: resistance := 0.0);
6: port (
7: terminal p1 : electrical;
8: terminal p2 : electrical);
9: end entity resistor;
Line 1 connects the standard IEEE VHDL-AMS library to the model. This library contains pre-defined type definitions. Line 2 instructs the model to use type definitions in the electrical_systems package within the IEEE library. Line 3 starts the formal entity definition. Lines 4 and 5 declare a property called res, typed as a resistance, with a default value of 0.0. I can use this property to assign my model a specific resistance value in a circuit. Lines 6 through 8 define the two ports for my model. Both are defined as terminals, which are analog ports in VHDL-AMS, and assigned electrical types. Line 9 closes the entity definition. Now let’s take a look at the architecture.
I will develop functionality for my resistor model using multiple architectures. My first architecture models basic resistor behavior using Ohm’s Law as defined above. Additional architectures will calculate the power dissipated in the resistor, and then determine if the power exceeds a user-defined limit. Here is the first architecture:
10: architecture basic of resistor is
11: quantity vres across ires through p1 to p2;
13: vres == ires*res;
14: end architecture basic;
Line 10 opens the architecture definition, gives it a name (basic), and links the architecture with my entity (resistor). Again, my resistor model is allowed only one entity, but I can define as many architectures as suites me. I simply need to give each architecture a different name. Line 11 begins the declaration section of the architecture, defines my analog quantities vres and ires, and associates each with the p1 and p2 ports defined in the entity. The simulator calculates these quantities, with vres calculated as the voltage across ports p1 and p2, and ires calculated as the current flowing through the ports from p1 to p2. Note that defining the port direction as “p1 to p2” is significant: in this case p1 is defined as having a higher potential than p2. Line 12 ends the declaration section and starts the model definition. Line 13 implements Ohm’s Law using VHDL-AMS syntax. The only difference between the Ohm’s Law equation and the VHDL-AMS implementation is the “==” syntax, which has significance for how the simulator handles the relationship between vres and the product of ires and res; I’ll save the detailed explanation for another blog post. For this discussion just consider “==” to mean “equal to”. Finally, Line 14 closes the basic architecture and completes this first version of my resistor model.
And that’s it for a basic Ohm’s Law-based resistor, which will work in any simulator that supports the full VHDL-AMS language standard. In my next blog post I’ll add another architecture that calculates the power dissipated in the resistor.