Sign In
Forgot Password?
Sign In | | Create Account

VHDL-AMS Stress Modeling – Part 3

Mike Jensen

Mike Jensen

Posted Mar 25, 2013
0 Comments

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.

Modeling

More Blog Posts

About Mike Jensen

Mike JensenMost career paths rooted in high technology take many interesting (and often rewarding) twists and turns. Mine has certainly done just that. After graduating in electrical engineering from the University of Utah (go Utes!), I set off to explore the exciting, multi-faceted high tech industry. My career path since has wound its way from aircraft systems engineering for the United States Air Force, to over two decades in applications engineering and technical marketing for leading design automation software companies, working exclusively with mechatronic system modeling and analysis tools. Along the way, I’ve worked with customers in a broad range of industries and technologies including transportation, communications, automotive, aerospace, semiconductor, computers, and consumer electronics; all-in-all a very interesting, rewarding, and challenging ride. In my current gig, I work on technical marketing projects for Mentor Graphics' SystemVision product line. And in my spare time I dream up gadgets and gizmos, some even big enough to qualify as systems, that I hope someday to build -- providing I can find yet a little more of that increasingly elusive spare time. Visit Mike Jensen's Blog

More Posts by Mike Jensen

Comments

No one has commented yet on this post. Be the first to comment below.

Add Your Comment

Please complete the following information to comment or sign in.

(Your email will not be published)

Archives

 
Online Chat