Analog Modeling – Part 2

In Analog Modeling – Part 1 I reviewed the importance of equation selection in the analog modeling process. In a nutshell, the first step in getting good simulation results is choosing equations that best describe the behavior or device you want to analyze. Your analog equation set could be as simple as a single transfer function describing the relationship between the inputs and outputs of a block, or as complex as the set of mathematical relationships characterizing a detailed motor model. Regardless of the complexity, turning your set of equations into a viable simulation model may seem a bit daunting. Like most engineering tasks, however, if you establish and use a proven process, even the most complicated task is reduced to a simple set of practical steps. For analog modeling using a general hardware description language (HDL), I recommend the following process flow:

  • Decide what you want your model to tell you about the device (hint: you may want to know more than the standard equations tell you)
  • Derive the characteristic equations and relationships for internal and external variables to calculate the information you want to know
  • Implement the equations and relationships using syntactically correct statements based on your modeling language choice
  • Declare and define appropriate objects to support your model statements

Before discussing the details of these steps, it’s worthwhile to understand how a model is structured in the HDL you plan to use. For this post, I’ll describe the general structure for a model written in VHDL-AMS. Keep in mind that model structures for other languages may differ a little…or a lot.

A typical VHDL-AMS model has two parts: an Entity and an Architecture. Each has a specific purpose. A VHDL-AMS Entity defines the parameters you can adjust to tune your model’s behavior, and describes how the model connects to other elements in a system. For example, here is the Entity for a simple resistor:

   entity resistor is
     generic (
        resistance : real := 100.0);
     port (
        terminal p1, p2 : electrical);
   end entity resistor;

The Generic section establishes a parameter called “resistance” and sets it to a value of 100. The Port section names two terminals, “p1″ and “p2″, and defines them as electrical in nature, meaning simulation results will be stored using electrical units. Any performance definition for this resistor model must be related to these two terminals.

A VHDL-AMS Architecture defines how the device operates, and connects the operation definition to the information in the model Entity. Here is a sample Architecture for the resistor model:

   architecture ideal of resistor is
      quantity voltage across current through p1 to p2;
    begin
      voltage == current * resistance;
   end architecture ideal;

This simple Architecture implements the device equation (in this case Ohm’s law) in VHDL-AMS syntax, and defines how the equation relates to terminals p1 and p2 in the Entity. Notice that the equation

   voltage == current * resistance

is very similar to the textbook definition of Ohm’s Law: v = i * r. The “quantity” statement defines how the “voltage” and “current” elements in the equation are associated with terminals p1 and p2. In this case, voltage is calculated across, and current through, the terminals. Knowing how to structure a model for a particular HDL simplifies the modeling process.

With this brief introduction to VHDL-AMS model structure, we can add some detail to our modeling process discussion. In my next post I’ll give some pointers on deciding what details you need to know about a device.

Post Author

Posted February 2nd, 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