VHDL-AMS Stress Modeling – Part 1

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:

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;

   12: begin

   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.

Post Author

Posted January 7th, 2013, by

Post Tags

Post Comments


About Mike Jensen's Blog

Views, insights, and commentary on mechatronic system design and analysis. Mike Jensen's Blog


2 comments on this post | ↓ Add Your Own

Commented on January 28, 2013 at 10:33 am
By VHDL-AMS Stress Modeling – Part 2 « Mike Jensen's Blog

[...] Part 1 of this series I started work on a simple resistor model as a way to illustrate some of the [...]

Commented on March 25, 2013 at 2:28 pm
By VHDL-AMS Stress Modeling – Part 3 « Mike Jensen's Blog

[...] Part 1 and Part 2 of this series I explained the foundation for adding stress calculations to a [...]

Add Your Comment


May 2014
  • SystemVision 5.10.3
  • March 2014
  • IESF 2014: Military & Aerospace
  • Engineering Oops!
  • Big Engineering
  • January 2014
  • SystemVision Model Wizard
  • December 2013
  • SystemVision 5.10.2
  • Modeling: An Engineer’s Dilemma
  • October 2013
  • What is Your Legacy?
  • September 2013
  • Automotive IESF 2013
  • July 2013
  • Simple Design Solutions
  • June 2013
  • SystemVision 5.10
  • May 2013
  • Engineering Muscle Memory
  • EDA vs. Windows 8
  • March 2013
  • VHDL-AMS Stress Modeling – Part 3
  • January 2013
  • VHDL-AMS Stress Modeling – Part 2
  • VHDL-AMS Stress Modeling – Part 1
  • December 2012
  • Practice! Practice!
  • November 2012
  • Sharing Tool Expertise
  • October 2012
  • Preserving Expertise
  • Virtual Prototyping — Really?
  • Innovations in Motion Control Design
  • September 2012
  • Game Changers
  • Do We Overdesign?
  • August 2012
  • Tsunami Remnants
  • July 2012
  • A New Look at Device Modeling
  • SystemVision 5.9
  • June 2012
  • Veyron Physics
  • May 2012
  • Rooster Tail Engineering
  • April 2012
  • Automotive IESF 2012
  • Teaching and Learning CAN Bus
  • March 2012
  • Analog Modeling – Part 6
  • Analog Modeling – Part 5
  • Analog Modeling – Part 4
  • February 2012
  • Analog Modeling – Part 3
  • Analog Modeling – Part 2
  • January 2012
  • Analog Modeling – Part 1
  • Connecting Tools and Processes
  • December 2011
  • Turning-Off and Tuning-In
  • Use vs. Experience
  • Analyzing the Big Picture
  • November 2011
  • Simulating for Reliability
  • October 2011
  • SystemVision 5.8
  • VHDL-AMS Model Portability — Fact or Fiction?
  • September 2011
  • IESF 2011 Moves to Frankfurt
  • Simulation Troubleshooting
  • August 2011
  • Qualities of VHDL-AMS Quantities
  • Military & Aerospace IESF 2011
  • Touring Johnson Space Center
  • July 2011
  • Engineering versus Science
  • June 2011
  • System Reengineering
  • May 2011
  • Integrating Hardware and Software Design
  • Engine Remote Start
  • Integrated System Design
  • Simulation Experiments (Part 3)
  • April 2011
  • Automotive IESF 2011
  • Pushbutton Cars
  • System Simulation with FEA-Base Motor Models
  • March 2011
  • Simulation Experiments (Part 2)
  • Simulation Experiments (Part 1)
  • Japan: Patience and Grace Amid Disaster
  • Top Gear = Driving Fun
  • February 2011
  • Buoyancy
  • Ideas in Motion
  • January 2011
  • The Mechanical Half of Mechatronics
  • Detroit Auto Show
  • Signal-flow vs Conserved System Modeling
  • SystemVision 5.7…Ready, Set, Go!
  • December 2010
  • SystemVision and Windows 7
  • Friction Vacation
  • Simulation Beyond Volts and Amps (Part 4)
  • November 2010
  • Simulation Beyond Volts and Amps (Part 3)
  • Simulation Beyond Volts and Amps (Part 2)
  • Simulation Beyond Volts and Amps (Part 1)
  • October 2010
  • SAE Convergence Recap (and an Unexpected Surprise)
  • VHDL-AMS Black Belt
  • Converging on SAE Convergence
  • System Design vs System Repair
  • September 2010
  • What’s the “AMS” in VHDL-AMS?
  • How Sensitive is Your System?
  • Do You Trust Your Simulator?
  • August 2010
  • What’s in a SPICE Model?
  • Cycling + Gravity = Pain
  • NI Week: Fun for Engineers
  • June 2010
  • Are You a Flexible Thinker?
  • VHDL-AMS and Switch Hysteresis
  • May 2010
  • VHDL-AMS Revisited
  • Segway to U3-X
  • Atomic Glue
  • March 2010
  • IESF Recap
  • February 2010
  • IESF is Coming…
  • System Level HDL-topia
  • January 2010
  • Mastering Design Abstraction
  • The Joy of Disassembly