VHDL-AMS Stress Modeling – Part 3

I’ve been away from my blog for a couple of months helping the SystemVision Engineering team with a few details related to our upcoming release: SystemVision 5.10. We’re excited about this new release. It introduces, among other things, a new way to create simulation models from a variety of data sources. We think this new capability will make it much easier to create SystemVision simulation models. The new release should be out in the next few weeks, and I’ll write more once it is finished. Now back to my stress modeling series…

In Part 1 and Part 2 of this series I explained the foundation for adding stress calculations to a simulation model: in this case, a simple resistor defined by Ohm’s Law. Part 1 developed the basic resistor model. Part 2 showed how to include power calculations by adding just a couple of lines of model code. As is, this is a fully functional model that will tell me important details about how my resistor performs in a circuit. But VHDL-AMS gives me the power to go even further, so I can have my model notify me, while the simulation is running, if my resistor’s power exceeds a certain limit. To do this, I use a combination of two VHDL-AMS commands (ASSERT and REPORT) and two attributes (‘ABOVE and ‘IMAGE). As I did in Part 2, I will create a new architecture to add this new capability t0 my model:

   1: architecture power2 of resistor is

   2:  quantity v across i through p1 to p2;

   3:  quantity pwr : power;

   4: begin

   5:  assert pwr’above(max_pwr)

   6:    report “*** Maximum power of ” & real’image(max_pwr)

   7:           & ” watts exceeded at ” & real’image(now) & ” seconds.”

   8:           & ” Measured power is: ” & real’image(pwr) & ” watts. ***”

   9:    severity warning;

   10:    v == i*res;

   11:    pwr == v*i;

   12: end architecture power2;

If you compare this power2 architecture with the power1 architecture in Part 2, you will notice that Lines 1-4 and Lines 10-12 are the same, except for the architecture name change. The added functionality in the power2 architecture, in Lines 5-9, defines how the resistor’s power (defined by the pwr quantity) is monitored and reported when an overpower, or stress condition, is detected. It starts with the ASSERT command and ‘ABOVE attributes in Line 5. The ‘ABOVE attribute monitors a VHDL-AMS quantity, in this case the resistor’s power, to see if it exceeds a level defined by the max_pwr limit. This limit is added as a generic to the model entity as follows:

   A:  generic (

   B:    res : resistance;

   C:    max_pwr : power := 0.25);

The original entity contained just Lines A-B. Line C adds the power limit used in Line 5. When the resistor power exceeds the max_pwr limit, the ASSERT command forces something to happen, in this case to report that the power was exceeded and what the calculated power is. This information is displayed in the simulation log using the REPORT command and the ‘IMAGE attribute in Lines 6-8. While this covers three lines in the model, the simulator sees this as one continuous line due to the ampersand (&) line continuation character. The REPORT command instructs the simulation to send text strings to the simulation log, so anything in quotes is reported as-is. The ‘IMAGE attribute also lets me include values for quantities as part of the reported message. In this case, the “real’image(max_pwr)” syntax reports the power limit setting as defined by the user. So if the value of max_pwr is left at its default in Line C, the Line 6 portion of the REPORT command sends the following information to the simulation log when the limit is exceeded:

*** Maximum power of 0.25

The “real’image(now)” syntax in Line 7 allows me to extract the simulation time at which the power limit is exceeded, and the “real’image(pwr)” syntax in Line 8 sends the detected value of the resistor’s power, contained in the pwr quantity, to the simulation log. To complete the example, assume that max_pwr is left at its default, that this limit is exceeded at 1.4 seconds, and that the actual power is 0.45 watts. The message sent to the log, as reported with the REPORT command above, looks something like this:

 *** Maximum power of 0.25 watts exceeded at 1.4 seconds. Measured power is: 0.45 watts. ***

Finally, Line 9 sets the severity of the ASSERT command. For my resistor model, the severity is set to “warning” to inform the user that the resistor model may produce unexpected results. Other severity options are “note” which is used to report general information from the simulation, “error” which indicates something is wrong with the model, and “failure” which can be used to indicate a condition that should normally never occur. What a simulator does with a severity level depends on the simulator’s definition. SystemVision simply logs details when the severity is set to note or warning, but halts the simulation when the severity is set to error or failure.

And there you have it: a resistor model that not only calculates its own power dissipation, but also reports when the power exceeds a user defined limit. If you have a copy of SystemVision, or another simulator that supports VHDL-AMS, try combining the model entity and architectures from Part 1, Part 2, and Part 3 into a single model file and experiment with a simulation. Make sure to setup your circuit so the resistor’s power exceeds the limit you set. Then look at the simulation log window to see how the REPORT command records its message. You might also try playing with the severity level to see how your simulator handles each setting. I have one more architecture that helps with viewing resistor power states in a waveform viewer, but explaining the model would make even a new blog entry a bit long. If you’re interested in seeing this architecture, of if you want a fully assembled version of the entire model, send me an email and I will send it to you.

Post Author

Posted March 25th, 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

October 2014
  • Reliability vs Robustness
  • 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