Analog Modeling – Part 5

If you’ve followed this Analog Modeling series, you know we’ve been talking about a general process for HDL-based modeling of analog behavior. If you’re new to the discussion, or simply want to review what we’ve talked about so far, check these links: Part 1, Part 2, Part 3, Part 4.

In my last post we developed a set of equations describing the relationship between the thermal and electrical properties of an incandescent lamp. Following the process outlined in Part 2, we now need to implement the equations using our modeling language of choice.

I’ve written before about VHDL-AMS, which is the language I will use to complete our incandescent lamp model. I chose VHDL-AMS for several reasons, two of the most important being capability and portability.

VHDL-AMS is very capable, having ample horsepower to model complex device and system behavior across a wide range of technologies. This isn’t to say, however, that the language is complex. In fact, its syntax and semantics are quite straight forward.

VHDL-AMS models are also very portable, a direct result of the language being an IEEE-sponsored industry standard. As long as my models adhere to the standard, I can move them between supporting simulators.

In addition to these language properties, I chose VHDL-AMS for our incandescent lamp model because it’s a major contributing factor to the power and flexibility of SystemVision.

VHDL-AMS models are divided into two sections: an entity and an architecture. The entity defines how the model connects to other elements of a system, and what properties users can adjust to characterize the model’s performance. The architecture describes the model’s function by implementing device equations using VHDL-AMS syntax. From a “which comes first” perspective, it makes the most sense to start model development with the architecture. Once the architecture is complete, the entity easily follows since its structure and content simply support the architecture. With this in mind, let’s work on the architecture.

From Analog Modeling – Par 4 we have the following device equations:

   Filament resistance = Rcold x (1.0 + Alpha x (Tfil – Tcold))

   Voltage = Current x Filament resistance

   Hflow(thermal) = Power(electrical)

   Hflow(conductive) = (Tfil – Tamb) / Rth

   Hflow(capacitive) = Cth x d(Tfil) / dt

   Hflow(radiated) = Ke x (Tfil**4 – Tamb**4)

   Hflow(total) = Hflow(conductive) + Hflow(capacitive) + Hflow(radiated)

Let’s first convert these equations to VHDL-AMS syntax (note that some of the elements are renamed to make the equations more compact):

   r_temp == r_cold*(1.0 + alpha*(temp_fil – temp_cold_K));

   v == i*r_temp;

   hflow == v*i;

   hflow == cth*temp_fil’dot + ke*SIGN(temp_fil – temp_amb_K)*(temp_fil**4

            – temp_amb_K**4) + (temp_fil – temp_amb_K)/rth;

Now let’s define constants and additional analog elements that support these equations. Since Kelvin is the default temperature scale for VHDL-AMS, let’s first define a couple of constants to convert degrees Celsius to Kelvin:

   constant temp_amb_K : real := temp_amb + 273.15;

   constant temp_cold_K : real := temp_cold + 273.15;

Next, we need to define analog elements, called “quantities” in VHDL-AMS, to help us define items in the equations that vary with time:

   quantity v across i through p1 to p2;

   quantity r_temp : resistance;

   quantity temp_fil : temperature;

   quantity hflow : heat_flow;

The first quantity statement defines how the voltage across and current through the lamp relate to the model pins (we will define the pins in the entity). The remaining quantity statements define analog elements that not only support the model equations, but also become waveforms that we can plot after a simulation. For example, once the model is finished we can plot the filament’s resistance and temperature, as well as the total heat flow for the lamp.

These are all of the architecture elements we need to completely describe the operation of our lamp. The only thing left to do is add an architecture wrapper around them:

   architecture dyn_therm of Lamp is

      constant temp_amb_K : real := temp_amb + 273.18;

      constant temp_cold_K : real := temp_cold + 273.18;

      quantity v across i through p1 to p2;

      quantity r_temp : resistance;

      quantity temp_fil : temperature;

      quantity hflow : heat_flow;

   begin

      r_temp == r_cold*(1.0 + alpha*(temp_fil – temp_cold_K));

      v == i*r_temp;

      hflow == v*i;

      hflow == cth*temp_fil’dot + ke*SIGN(temp_fil – temp_amb_K)*(temp_fil**4

                    – temp_amb_K**4) + (temp_fil – temp_amb_K)/rth;

   end architecture dyn_therm;

And that’s it. We now have a complete VHDL-AMS architecture, called “dyn_therm”, describing the relationship between the thermal and electrical properties of an incandescent lamp. While we could have used another modeling language to implement the lamp’s behavior, VHDL-AMS is pretty hard to beat for clarity and ease of coding. In the final post of this series, Analog Modeling – Par 6, we’ll finish the model by adding the VHDL-AMS entity.

Post Author

Posted March 23rd, 2012, 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