VHDL-AMS Stress Modeling – Part 2

In Part 1 of this series I started work on a simple resistor model as a way to illustrate some of the flexibility the VHDL-AMS language offers when creating simulation models. Recall that one of the advantages of VHDL-AMS is adding detail to models – a benefit not available with all modeling languages or methods. With VHDL-AMS, it’s possible to get your model and simulator to report performance details not available with other tools. To illustrate this flexibility, my resistor model will include a power dissipation calculation, and a comparison of the result with a user defined power limit to determine stress conditions.

Before jumping into the next model piece, however, I’ll tie up a loose end I left dangling in my earlier post. I mentioned the use of “==” when formulating device equations in a VHDL-AMS model. And at that time I said to simply interpret the syntax as “equal to”. But that definition doesn’t quite cover what’s going on inside the simulator. The “==” is more accurately interpreted as “balance both sides of the equation”. Once the simulator generates a matrix of equations that represent the system, the unknowns are adjusted during simulation, through a series of iterations, until all equations are solved within a user defined accuracy.

Now back to my resistor model. I’m going to jump right into the next architecture, so if you need a review (or a preview) of the model so far, take a quick look at Part 1. Up to this point it’s a basic Ohm’s Law-based resistor: voltage across the resistor is directly proportional to the product of the current and resistance. Now it’s time to add commands to calculate the power.

Recall once again from your first physics or electric circuits class that the power dissipated in a resistor is dependent on any two of its three operating parameters: voltage, current, resistance. There are a few different combinations of these parameters that calculate power, but I’ll use the following:

   power = voltage x current

Based on this equation, here is the next section in my model:

   1: architecture power1 of resistor is

   2:   quantity vres across ires through p1 to p2;

   3:   quantity pwr : power;

   4: begin

   5:   vres == ires*res;

   6:   pwr == v*i;

   7: end architecture power1;

Here I’ve created a new architecture named “power1” for the resistor model. This architecture is the same as the “basic” architecture in my earlier post, except that its name is changed and Lines 3 and 6 are added to setup the power calculation. Line 3 defines a new quantity named “pwr” (remember that a quantity is an analog element in a model) with an assigned VHDL-AMS type of “power”. Note that pwr is not directly associated with the p1 and p2 ports of the model. Therefore the type assignment simply determines what units will be used (in this case “watts”) to plot the pwr quantity. Line 6 calculates pwr as the product of the voltage across the resistor and the current through it, as define in the standard power equation above. This architecture can be added to the model in Part 1 to create a resistor model with one entity and two architectures (recall that a VHDL-AMS model can only have one entity, but multiple architectures). When I use the resistor model in a SystemVision schematic, I can select which architecture to use for that resistor instance. If I choose the power1 architecture, the resistor’s power is calculated at each time or frequency step during the simulation, and becomes a waveform I can plot when the simulation is finished.

Now that my basic resistor is complete, I can add details that will determine if the power exceeds a user defined power rating. In Part 3 of this series I’ll create another new architecture that detects when the resistor’s power exceeds a user defined limit, and notifies me when there is a problem.

Post Author

Posted January 28th, 2013, by

Post Tags

, , , , , ,

Post Comments

No Comments

About Mike Jensen's Blog

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

Comments

Add Your Comment

Archives

June 2014
  • Wow Factor
  • 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