Denver Pels 20071113 Cooper Vhdl-Ams (1)

Introduction To The VHDL-AMD Modeling Language
Scott Cooper Mentor Graphics Presented 13 November 2007 Westminster, Colorado
Denver Chapter, IEEE Power Electronics Society www.denverpels.org

Special Note
This document contains an expanded version of the presentation that Scott Cooper presented at the Chapter meeting and a paper written by Scott that is an introduction to modeling languages. The Chapter thanks Scott Cooper for his contributions.

Denver Chapter, IEEE PELS

2

Introduction to VHDL-AMS
Presented by Scott Cooper

Introduction to System Modeling Using VHDL-AMS

1

Presentation Agenda
D

VHDL-AMS Overview
Here we will briefly define what VHDL-AMS is, and some concepts associated with it.

D

Electrical Analog Modeling
In this portion of the presentation, we concentrate on analog, or continuous-time, modeling concepts with VHDL-AMS.

D D

Mixed-Signal Modeling
In this section, we discuss mixed-signal modeling techniques.

Power Converter Design Example
The last part of the presentation will focus on a power converter design developed with VHDL-AMS models.

Introduction to System Modeling Using VHDL-AMS

2

What is VHDL-AMS?
D D D

A mixed-signal modeling language based on VHDL (IEEE 1076-1993) A strict superset of VHDL (IEEE 1076.1-1999)


AMS => Analog / Mixed Signal Extensions Non-linear Ordinary Differential-Algebraic Equations (DAEs) Mixed Analog/Digital

Represents complex models directly
 

D

Can also model non-electrical physical phenomena

Introduction to System Modeling Using VHDL-AMS

3

VHDL-AMS Concepts
D D D D D D

VHDL-AMS models are organized as entities and architectures It has a concept of time, concurrent processes It has a well-defined simulation cycle It can model continuous and discontinuous behavior Equations are solved using conservation laws (e.g. KCL, Newton’s Laws) It handles initial conditions, piecewise-defined behavior, and so forth

Introduction to System Modeling Using VHDL-AMS

4

Electrical Analog Modeling

Introduction to System Modeling Using VHDL-AMS

5

VHDL-AMS Model Structure
VHDL-AMS models are typically comprised of two sections: an entity and an architecture.
D D

Entity - Describes the model interface to the outside world Architecture - Describes the function or behavior of the model

Introduction to System Modeling Using VHDL-AMS

6

Entity - model interface

D

Pins “p1” and “p2” provide the interface between this model and the outside world. The nature of these pins is defined in the model’s “Entity declaration.”

D

Introduction to System Modeling Using VHDL-AMS

7

Resistor Model (Entity Declaration)
Pin Definitions: p1, p2 - electrical pins

entity resistor is port ( terminal p1, p2 : electrical); end entity resistor;

Introduction to System Modeling Using VHDL-AMS

8

Resistor Model (Entity Explanation)
Entity declaration Entity/model name Port names Port Nature: Electrical? Mechanical? Thermal? …?

entity resistor is port ( Device port (pin) terminal p1, p2 :electrical); Port type: end entity resistor;
Analog? Digital? Conserved?

Entity/model name

Introduction to System Modeling Using VHDL-AMS

9

Architecture - model behavior
D

The architecture describes the behavior of the model.

D

In this case, the model behavior is governed by Ohm’s law, which relates current and voltage as:
i = v / res

Introduction to System Modeling Using VHDL-AMS

10

Resistor Model (Architecture)
Characteristic Equation: i = v / res

architecture ideal of resistor is constant res : real := 10.0e3; quantity v across i through p1 to p2; begin -- architecture ideal i == v / res; end architecture ideal;
Introduction to System Modeling Using VHDL-AMS 11

Resistor Model (Architecture Explanation)
Architecture name Entity name

architecture ideal of resistor is constant res : real := 10.0e3; Internal object declarations quantity v across i through p1 to p2; begin -- architecture ideal Model behavior i == v / res; end architecture ideal;

Architecture name

Now that we’ve seen the overall structure of a VHDL-AMS model, let’s explore some elements of the model.
Introduction to System Modeling Using VHDL-AMS 12

VHDL-AMS Object Types
D

There are six classes of “objects” in VHDL-AMS:
     

Constants Terminals Quantities Variables Signals Files

D

For analog modeling, constants, terminals, and quantities are routinely used

Introduction to System Modeling Using VHDL-AMS

13

Constants
D

Data storage object for use in a model  constant res : real := 50.0;
Declares constant, res, of type real, and initializes it to 50.0. Since this constant is of type real, it must be assigned only real values, which must include a decimal point. 

constant count : integer := 3;
Declares constant count, of type integer, and initializes it to 3. Since count is of type integer, it must be assigned only whole values, which must not include a decimal point.



constant td : time := 1 ns;
Declares constant td, of type time, and initializes it to 1 ns (1.0e-9 seconds). Time is a special kind of constant, described next.

Introduction to System Modeling Using VHDL-AMS

14

Predefined Physical Types
D

D

The constant time is a predefined physical type, so named because it represents a real world physical property. It can be either real or integer. As a physical type, time values are specified with a value followed by a multiplier (separated with a space). Predefined time multipliers consist of the following:
- fs (femto-seconds) - ps (pico-seconds) - ns (nano-seconds) - us (micro-seconds) - ms (milli-seconds) - sec (seconds) - min (minutes) - hr (hours) Since td is of type time, it may only be assigned time values.
Introduction to System Modeling Using VHDL-AMS

D

15

Constants (cont.)
D

Constants make models easier to understand and modify (as opposed to using literal values)
 

i == v/50.0; i == v/res;

-- Poor modeling style -- Good modeling style

D

Constant values cannot be changed during simulation

Introduction to System Modeling Using VHDL-AMS

16

Terminals
D D D D

Terminals represent continuous, conservative ports in VHDL-AMS Terminals have across (potential) and through (flow) aspects Terminal types are referred to as “natures” Example terminal natures (predefined):
   

electrical - voltage across, current through translational – position across, force through thermal – temperature across, power (or heat-flow) through fluidic – pressure across, flow-rate through

D

Users can define custom terminal natures

Introduction to System Modeling Using VHDL-AMS

17

Quantities: 3 Types
D D

Free quantity - non-conservative analog object:


quantity pwr : real;

Branch quantity - analog object used for conservative energy systems:


quantity v across i through p1 to p2;

D

Source quantity - for frequency domain:


quantity spectral_src real spectrum mag, phase;

Source quantities will not be discussed in this course

Introduction to System Modeling Using VHDL-AMS

18

Free Quantities
Free quantities can be used to represent non-conserved analog values. They are often used to clarify model descriptions, and provide the ability to view internal model waveforms. Free quantities are also used to describe signal-flow (block diagram) type models.  quantity internal_variable : real := 5.0;
–

In this case, the quantity internal_variable is of type real, and is initialized to 5.0. In this case, the quantity power is declared as type real, and is initialized to the default (left-most) value for that type. The default value for type real is guaranteed to be no larger than -1.0e+38. Depending on how they are used, it is sometimes important to initialize quantities and avoid their default values.



quantity power : real;
–

Introduction to System Modeling Using VHDL-AMS

19

Branch Quantities
D

Branch quantity
Branch quantities are analog objects used for conservative energy systems. For electrical systems, these quantities are used to access either the voltage or current, or both, of a terminal port. To illustrate branch quantities, consider the entity declaration for the resistor model discussed previously:

D

terminal p1, p2 : electrical;
An example of the branch quantity declaration syntax for these terminals is next:

Introduction to System Modeling Using VHDL-AMS

20

Branch Quantities
Quantity “i” refers to the through aspect of terminal ports p1 and p2

quantity v across i through p1 to p2 ;

Quantity “v” refers to the across aspect of terminal ports p1 and p2
D D D

“v” and “i” are defined with respect to terminal ports p1 and p2

Recall the resistor entity declaration for ports p1 and p2 : terminal p1, p2 : electrical; Since p1 and p2 are declared as electrical ports, v will represent voltage, and i will represent current Any name can be used for the quantities (not restricted to v and i)

Introduction to System Modeling Using VHDL-AMS

21

Source Quantities
Source quantity
Source quantities are used for frequency and noise modeling. These are used only in sources when frequency domain analysis is to be performed, and other models do not require them to perform in this domain. A syntax example is given as:
quantity spectral_src real spectrum mag, phase ;

Introduction to System Modeling Using VHDL-AMS

22

Generic Constants (“Generics”)
D D

D

Allow models to be externally parameterized Static objects can be defined as generics in the entity of a model, rather than as constants in the architecture of a model Allows the model to be used more “generically,” without having to modify the model itself. The model user just passes in a value to the model.

Introduction to System Modeling Using VHDL-AMS

23

Resistor Model (Entity with Generic)
Generic type Optional initializer entity resistor is generic ( res : real := 10.0e3); port ( terminal p1, p2 : electrical); end entity resistor;

Generic name

Value of generic can be initialized in the entity declaration. This value will be over-written if specified when the component is instantiated.

Introduction to System Modeling Using VHDL-AMS

24

Resistor Model (Architecture with Generic)

architecture ideal of resistor is constant res : real := 10.0e3; quantity v across i through p1 to p2; begin -- architecture ideal i == v / res; end architecture ideal;

Constant res no longer defined in architecture
Introduction to System Modeling Using VHDL-AMS 25

Implicit Quantity Attributes (analog)
Useful predefined quantity attributes
D

D

D

D

Q’dot Time derivative of quantity Q v == L*i’dot; -- v = L*di/dt Q’integ Time integral of quantity Q v == (1/C)*i’integ + init; -- v = (1/C) ∫i dt + k Q’delayed(T) Quantity Q delayed by time T v_out == v_in’delayed(td); … many more

Introduction to System Modeling Using VHDL-AMS

26

Analog Modeling Examples

Introduction to System Modeling Using VHDL-AMS

27

Inductor Model (Entity)
+ vp1 i p2

Pin Definitions/Argument: p1, p2 : electrical pins ind : user supplied argument

use ieee.electrical_systems.all; entity inductor is generic ( ind : real); -- inductance value port ( terminal p1, p2 : electrical); end entity inductor;

Introduction to System Modeling Using VHDL-AMS

28

Inductor Model (Architecture)
+ vp1 i p2

Fundamental Equation:

di v = ind dt

architecture ideal of inductor is quantity v across i through p1 to p2; begin -- ideal architecture v == ind * i’dot; end architecture ideal;

Introduction to System Modeling Using VHDL-AMS

29

Diode Model (Entity)
Pin Definitions/Argument: p, n : electrical pins Isat : user supplied argument

entity diode is generic ( -- saturation current Isat : current := 1.0e-14; port ( terminal p, n : electrical); end entity diode;

Introduction to System Modeling Using VHDL-AMS

30

Diode Model (Architecture)
Fundamental Equation:

i = Isat * (exp

v vt

− 1 .0 )

architecture ideal of diode is constant TempC : real := 27.0; constant TempK : real := 273.0 + TempC; constant vt : real := PHYS_K*TempK/PHYS_Q; quantity v across i through p to n; begin i == Isat*(exp(v/vt)-1.0); end architecture ideal;

Introduction to System Modeling Using VHDL-AMS

31

Op Amp Model (Entity)
in_pos output in_neg

Pin Definitions/Argument:
in_pos, in_neg, output : electrical pins a_ol, f_0dB : user supplied arguments
entity opamp_3p is generic ( a_ol: real := 100.0e3; f_0dB: real := 1.0e6 ); port ( terminal in_pos: electrical; terminal in_neg: electrical; terminal output: electrical ); end entity opamp_3p;

Introduction to System Modeling Using VHDL-AMS

32

Op Amp Model (Architecture)
in_pos output v_in in_neg

Fundamental Equation:
v_out

vout = vin 1+

a ol s

architecture default of opamp_3p is 3 dB constant f_3dB: real := f_0dB/a_ol; constant w_3dB: real := math_2_pi*f_3dB; constant num: real_vector := (0 => a_ol); constant den: real_vector := (1.0, 1.0/w_3dB); quantity v_in across in_pos to in_neg; quantity v_out across i_out through output to ELECTRICAL_REF; begin v_out == v_in'ltf(num, den); end architecture default;

ω

Introduction to System Modeling Using VHDL-AMS

33

Incandescent Lamp
D D

An incandescent lamp converts electrical energy into thermal energy. From an electrical standpoint, the lamp filament acts as a temperature-dependent resistance. From a thermal standpoint, current flows through this resistance, power is developed and thermally dissipated as a combination of thermal conductance, thermal capacitance, and radiation.

v i R hflow
v*i = power => heat flow

T rth cth

(Powerelectrical = Powerthermal)
Electrical model governing power Thermal model governing power (heat flow)

Introduction to System Modeling Using VHDL-AMS

34

Lamp Equations
We begin with the electrical model of the preceding figure, which consists of a temperature-dependent electrical resistance. The power dissipated by this resistance is determined as follows: power = v*i where the power is simply the product of the voltage (v) across the electrical resistance and the current (i) through it. The voltage across the electrical resistance can be determined using Ohm’s law as follows: v = i*R where R represents the electrical resistance at the given temperature. This resistance, in turn, can be calculated with the following formula: R = RC*(1.0 + alpha*(T - TC)) where RC is the electrical resistance when the lamp is “cold,” TC is the unheated “cold” temperature of the filament, T is the actual filament temperature, and alpha is the resistive temperature coefficient of the filament.

Introduction to System Modeling Using VHDL-AMS

35

Lamp Equations
We now have the necessary information to calculate the temperaturedependent electrical power as a function of filament temperature. The next task is to develop equations which describe how this power is thermally dissipated. For the thermal capacitance component (cth), the governing equation is: hflowcap = cth*dT/dt where the heat flow is the product of the time derivative of the filament temperature (T) and the thermal capacitance (cth). The thermal conductance (rth) component is formulated as follows: hflowres = (T - TA)/rth where the heat flow is the ratio of the delta temperature (actual temperature (T) minus ambient temperature (TA)), and the thermal resistance. The lamp will also dissipate heat in the form of electromagnetic radiation.

Introduction to System Modeling Using VHDL-AMS

36

Lamp Equations
The radiated heat flow increases as the fourth power of the object’s temperature, and may be described as follows: hflowradiated = Ke*(T4 - TA4) where Ke is the radiated energy coefficient. We now have all the equations necessary to implement the incandescent lamp model. To summarize our approach, we are attempting to equate electrical power to thermal power (heat flow), as follows: Electrical: power = v*i and Thermal: hflow = hflowcap + hflowres + hflowradiated these two equations may be equated by the following relationship: Electrical/thermal: power = hflow

Introduction to System Modeling Using VHDL-AMS

37

Developing the Lamp Model
Although it is quite easy to develop simple models in an unstructured manner, more complex models benefit from a structured modeling approach. A recommended approach for analog modeling is: 1. Determine the model’s characteristic relationships for internal and external variables 2. Implement these relationships as simultaneous statements in VHDL-AMS 3. Declare appropriate objects to support the simultaneous statements

Introduction to System Modeling Using VHDL-AMS

38

Incandescent Lamp (Architecture)
…then declare appropriate architecture dyn_therm of Lamp is objects to support the constant temp_amb_K : real := temp_amb + 273.18; constant temp_cold_K : real := temp_cold + 273.18; simultaneous equations. quantity v across i through p1 to p2; quantity r_temp : resistance; -- Resistance at temp_fil [ohms] quantity temp_fil : temperature; -- Filament temperature [K] quantity hflow : heat_flow; -- Heat flow from filament [watts]
begin First, express core r_temp == r_cold*(1.0 + alpha*(temp_fil - temp_cold_K)); relationships as VHDL-AMS v == i*r_temp; simultaneous equations… hflow == v*i; -- Electrical power = heat flow 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; -- Note: For alpha, cth and rth, temperatures specified in C or K will work since each represents a ratio, -- for which only the change in temperature is significant, not its absolute offset. end architecture dyn_therm;

Introduction to System Modeling Using VHDL-AMS

39

Incandescent Lamp (Entity)
Finally, define the model’s interface to the outside world.
entity Lamp is generic ( r_cold : resistance := 0.2; temp_cold : temperature := 27.0; alpha : real := 0.0045; ke : real := 0.85e-12; rth : real := 400.0; cth : real := 0.25e-3; temp_amb : temperature := 27.0); port (terminal p1, p2 : electrical); end entity Lamp;

-- Filament resistance at temp_cold -- Calibration temperature [deg C] -- Resistive temp coefficient [ohms/deg C] -- Radiation coefficient [watts/K^4] -- Thermal conduction [deg C/watt] -- Thermal heat capacitance [joules/C] -- Ambient temperature [deg C]

Introduction to System Modeling Using VHDL-AMS

40

Model Solvability
Analog models are solved by the simulator as simultaneous equations. When solving simultaneous equations, the number of equations must equal the number of unknowns to be solved. To ensure the same number of equations and unknowns in a behavioral model, the following formula may be applied:
# equations = # free quantities + # through quantities + # quantity ports of mode out

Introduction to System Modeling Using VHDL-AMS

41

Mixed-Signal Modeling

Introduction to System Modeling Using VHDL-AMS

42

Mixed-Signal Introduction
In this section, we combine the analog and digital modeling capabilities of VHDL-AMS. An overview of A/D and D/A conversion techniques will be given next, followed by specific model examples.

Introduction to System Modeling Using VHDL-AMS

43

Analog to Digital
The ‘above attribute is used to convert an analog (continuous) quantity into a digital (discontinuous) signal, by detecting an analog threshold crossing. The syntax is as follows: Q’above(threshold); Where Q is the analog quantity to be converted, and threshold is the analog threshold level. This statement returns a boolean ‘true’ if quantity Q passes from below to above the threshold level; it returns a boolean ‘false’ if quantity Q passes from above to below the threshold level.

Introduction to System Modeling Using VHDL-AMS

44

Digital to Analog
There are two primary methods for converting from digital signals to analog quantities. The first method involves using the ‘ramp attribute, as follows: Q == S’ramp(tr,tf); Where Q is an analog quantity, S is a digital signal, and tr and tf are the rise and fall-times of Q at transition points. When signal S changes value, quantity Q tracks this change, but transitions to it over a linear interval of tr or tf, depending on the direction of the change. The ‘ramp attribute also performs the function of restarting the analog solver at the discontinuous points when signal S is updated. This is a very important consideration for analog simulation so that the simulator does not get “lost” when encountering a discontinuity.

Introduction to System Modeling Using VHDL-AMS

45

Digital to Analog
The second method for D/A conversion can be used any time a quantity is updated as a function of a signal, as in: Q == f(S); break on S; Where Q is an analog quantity, and f(S) is some function which returns a digital signal. In this case, if the ‘ramp attribute is not included in the statement, a break statement should be included to synchronize the analog quantity to the digital signal during state transitions. The break statement is used explicitly to accomplish what the ‘ramp attribute does implicitly, which is to guide a simulator through discontinuities.

Introduction to System Modeling Using VHDL-AMS

46

Mixed Signal Model Examples

Introduction to System Modeling Using VHDL-AMS

47

Analog to Digital Interface (Entity)

entity a2d is generic (vthreshold : real := 2.0); port (d_output : out std_logic; terminal a_input : electrical); end entity a2d;

Entity declaration can include both analog and digital ports.

Introduction to System Modeling Using VHDL-AMS

48

Analog to Digital Interface (Architecture)
architecture behavioral of a2d is quantity vin across a_input to electrical_ref; begin process (vin’above(vthreshold)) is begin if vin’above(vthreshold) then d_output <= ‘1’; else d_output <= ‘0’; end if; end process; end architecture behavioral; -- Note that no simultaneous equations are required --

Introduction to System Modeling Using VHDL-AMS

49

The ‘above Attribute
D

“Why use ‘above instead of > or < ?”


‘above() generates an event exactly when the crossing occurs.
–

It is the only way to generate a signal to use in a break statement.



< or > do a comparison at each time-step, which may not fall on the exact crossing.

D

Must use “ not ‘above() ” to represent “ ‘below() ”, as ‘below() is not part of the VHDL-AMS language.

Introduction to System Modeling Using VHDL-AMS

50

Simple Switch and Entity

The purpose of this switch is to allow or prevent current flow between pins p1 and p2, depending on the value of sw_state. Ports p1 and p2 are electrical analog, and port sw_state is std_logic digital.

entity switch_dig_nogen is port ( sw_state : in std_logic; terminal p1, p2 : electrical ); end entity switch_dig_nogen;
Introduction to System Modeling Using VHDL-AMS 51

Simple Switch Architecture
architecture ideal of switch_dig_nogen is constant r_open : real := 10.0e3; constant r_closed : real := 15.0e-3; constant trans_time : real := 10.0e-6; signal r_sig : resistance := r_open; quantity v across i through p1 to p2; quantity r : resistance; begin DetectState: process (sw_state) begin if (sw_state = ‘0’) then r_sig <= r_open; elsif (sw_state = ‘1’) then r_sig <= r_closed; end if; end process DetectState; r == r_sig’ramp(trans_time, trans_time); v == r*i; end architecture ideal;

Introduction to System Modeling Using VHDL-AMS

52

Key Switch Attributes
D

‘event

The mechanism by which digital events are detected in VHDL-AMS. The switch uses this to detect when a new digital control signal is given.
D

‘ramp

Ensures that when switching from one value of r_sig to another, a reasonable amount of “switching time” is used.
The syntax used in the switch example is:
q == S’ramp(tr, tf); where q is a quantity (r), S is a signal (r_sig), and tr and tf are real values, representing the rise time and fall time respectively.

Introduction to System Modeling Using VHDL-AMS

53

Ideal Limiter Model (Entity)
A limiter model entity is shown below. Its function is to restrict the range of voltage levels which pass from input to output. In order to implement this behavior, the model selects between one of three simultaneous equations, depending on the level of the input voltage. entity limiter_ideal is generic ( limit_high : real := 10.0; -- upper limit limit_low : real := -10.0); -- lower limit port ( terminal input: electrical; terminal output: electrical); end entity limiter_ideal ;

Introduction to System Modeling Using VHDL-AMS

54

Ideal Limiter Model (Architecture)
architecture simple of limiter_ideal is quantity vin across input to electrical_ref; quantity vout across iout through output to electrical_ref; begin if vin’above(limit_high) use -- above upper limit, so limit output vout == limit_high; elsif not vin’above(limit_low) use -- below lower limit, so limit output vout == limit_low; else -- no limit exceeded, so pass input signal to output vout == vin; end use; break on vin'above(limit_high), vin'above(limit_low); end architecture simple;

Introduction to System Modeling Using VHDL-AMS

55

Power Converter Example

Introduction to System Modeling Using VHDL-AMS

56

Phase 1 – Averaged Model
Phase 1 allows both frequency and time domain exploration of the design. It simulates very quickly, and allows the overall control loop to be stabilized.

Introduction to System Modeling Using VHDL-AMS

57

Averaged Model Stimulus and Results
Output voltage

Dynamic load perturbations

Input perturbations

Introduction to System Modeling Using VHDL-AMS

58

Phase 2 – Ideal Switch/Diode Models
Phase 2 allows switching effects to be analyzed with relatively ideal switch and diode models. Drive voltages and currents can now be evaluated.

Introduction to System Modeling Using VHDL-AMS

59

Averaged and Switched Results
Superimposed output voltages for averaged and switched designs

Introduction to System Modeling Using VHDL-AMS

60

Phase 3 – MOSFET, IRR Diode and Stress Checks
Phase 3 includes a MOSFET switch, a diode model that includes IRR effects, as well as stress monitoring for the MOSFET and diode.

Introduction to System Modeling Using VHDL-AMS

61

Averaged, Ideal Switch, MOSFET Tests
Superimposed output voltages for averaged, ideal switched and MOSFET switch-based designs

Introduction to System Modeling Using VHDL-AMS

62

Stress Indicators in Waveform Viewer
Boolean indicators in the Waveform Viewer that show if any stress measures have been violated.

Introduction to System Modeling Using VHDL-AMS

63

Analyzing Causes of Stress (IRR Violated)

If MOSFET switches too fast (RGATE = 1k), IRR specification is violated.

Introduction to System Modeling Using VHDL-AMS

64

Analyzing Causes of Stress (MOSFET Power)

If MOSFET switches too slow (RGATE = 3k), its power rating is violated.

Introduction to System Modeling Using VHDL-AMS

65

Test IRR Diode
Test circuit for the diode with reverse-recovery effects modeled.

Introduction to System Modeling Using VHDL-AMS

66

IRR Diode Test Results

Test results for the diode with reverse-recovery effects modeled.

Introduction to System Modeling Using VHDL-AMS

67

VHDL-AMS Reference Material
D

How to Model Mechatronic Systems Using VHDL-AMS is the first booklet in the SystemVision Technology Series. This booklet serves as the foundation for this modeling course. It is available from the SystemVision Welcome Screen, and from Mentor Graphics at the SystemVision website. The System Designer's Guide to VHDL-AMS (P. J. Ashenden, G. D. Peterson, D. A. Teegarden - ISBN 1-55860-749-8, published by Morgan-Kaufman Publishers, 2002) is a comprehensive textbook for the VHDL-AMS modeling language. The Designer’s Guide to Analog & Mixed-Signal Modeling (R. S. Cooper - ISBN 0-9705953-0-1, published by Avant!, 2001) includes numerous model examples in both the VHDL-AMS and MAST modeling languages. The VHDL-AMS Quick Reference Guide offers a summary of many VHDL-AMS language features and syntax. It is accessed from within SystemVision: Help > Manuals > VHDL-AMS Quick Reference.

D

D

D

Introduction to System Modeling Using VHDL-AMS

68

Thank You!

Introduction to System Modeling Using VHDL-AMS

69

System Modeling White Paper

System Modeling: An Introduction

Scott Cooper Mentor Graphics

www.mentor.com/systemvision

INTRODUCTION This paper introduces a systematic process for developing and analyzing system models for the purpose of computer simulation. This process is demonstrated using the Digitally-Controlled Positioning System (referred to as “Position Controller”) shown in Figure 1. WHAT IS COMPUTER SIMULATION? The general concept of “computer simulation” (referred to simply as “simulation” in this paper) is to use a computer to predict the behavior of a system that is to be developed. To achieve this, a “system model” of the real system is created. This system model is then used to predict actual system performance and to help make design decisions. Simulation typically involves using specialized computer algorithms to analyze, or “solve”, the system model over some period of time (time-domain simulation) or over some range of frequencies (frequency-domain simulation). WHY SIMULATE? Simulation is useful for many reasons. Perhaps the most obvious use of simulation is to reduce the risk of unintended system behaviors, or even outright failures. This risk is reduced through “virtual testing” using simulation technologies. Virtual testing is typically used in conjunction with physical testing (on a physical prototype). The problem with relying solely on physical testing is that it is often too expensive, too timeconsuming, and occurs too late in the design process to allow for optimal design changes to be implemented. Virtual testing, on the other hand, allows a system to be tested as it is being designed, before actual hardware is built. It also allows access to the innermost workings of a system, which can be difficult or even impossible to observe with physical prototypes. Additionally, virtual testing allows the impact of component tolerances on overall system performance to be analyzed, which is impractical to do with physical prototypes. When employed during the beginning of the design process, simulation provides an
System Modeling: An Introduction

environment in which a system can be tuned, optimized, and critical insights can be gained – before any hardware is built. During the verification phase of the design, simulation technologies can again be employed to verify intended system operation. It is a common mistake to completely design a system and then attempt to use simulation to verify whether or not it will work correctly. Simulation should be considered an integral part of the entire design phase, and continue well into the manufacturing phase. SYSTEM OVERVIEW The Position Controller is composed of two sections, as indicated by the dotted line dividing the system shown in Figure 1. These sections are referred to as the Digital Command and Servo subsystems. These subsystems will be developed individually, and then combined to form the overall Position Controller system. The Position Controller works as follows: A Digital Command subsystem is used to generate a series of user-programmable “position profile” commands, which the motor/load are expected to precisely track. The digitally-generated command drives a digital-to-analog (D/A) converter which produces an analog representation of the digital command. The D/A output is then filtered, and used to command an analog servo loop, the purpose of which is to precisely control the position of an inertial load connected to the shaft of a motor. Each of these blocks will be explored in detail in this paper.
Digital Command Digital Command
D 2 A

Servo Servo/ Motor/ Load

Figure 1 – Position Controller

This type of servo positioning system is commonly employed in various applications in
-2-

the automotive, industrial controls, and robotics industries, among others. Although this paper focuses on this single system, the process used to develop the Position Controller may be applied to a great number of other systems as well. MODELING THE SYSTEM Before setting out to model this system the following assumptions will be made: • The Digital Command subsystem will be implemented by another designer • The specification for the Digital Command subsystem requires that it will generate a new 10 bit digital word every 2 ms The Digital Command and Servo subsystems will be developed individually. Since the Servo subsystem is this designer’s primary design responsibility, special consideration will be given to modeling this subsystem. This approach of breaking a larger system down into manageable subsystem (or smaller) blocks is often helpful during the early phases of a design. Once individual subsystems are working properly, they can then be integrated into the full design. The Position Controller will be developed in four phases as follows: • Develop System Modeling Analysis Strategy • Develop Conceptual Servo Design • Develop Detailed Servo Design • Integrate Digital Command and Servo Subsystems The focus of the Develop System Modeling Analysis Strategy phase will be to mathematically describe the various analog components in the Servo subsystem, and to consider the modeling process in general. In the Develop Conceptual Servo Design phase the analog Servo subsystem components are implemented using the analog behavioral modeling features of the VHDL-AMS language. The Develop Detailed Servo Design phase deals with system implementation issues, which
System Modeling: An Introduction

often entails upgrading “high-level” models to be more consistent with the intended physical implementation of the system. SPICE and VHDLAMS models are combined to achieve this goal for the Position Controller system. The Integrate Digital Command and Servo Subsystems phase discusses how to implement the Digital Command subsystem components using the mixed analog/digital features of the VHDLAMS modeling language. Once the Digital Command subsystem is implemented, the entire Position Controller system will be simulated. All design development and simulation in this paper is performed with the SystemVision™ System Modeling Solution from Mentor Graphics Corporation. DEVELOP SYSTEM MODELING ANALYSIS STRATEGY This first phase of a system design deals with many of the decisions that need to be made when starting development of a new system. Attention is also given to defining mathematical descriptions for the various analog components in the Servo subsystem, and how to systematically approach the modeling process in general. Servo Subsystem Since the majority of the modeling tasks exist in the Servo subsystem, the first three phases of the design process will focus on this subsystem. The Digital Command subsystem will be developed in the fourth phase of the process. The purpose of the Servo subsystem is to precisely control the position of a motor-driven load in response to an analog command. Since the motor/load must be precisely controlled, it suggests that a feedback control loop will need to be employed. Since it is ultimately the position of the load that needs to be controlled, a position feedback loop will be used (which means that the load position must somehow be measured, and fed back to close the control loop). Experience with such systems has shown that both the response and the stability of position control loops can be
-3-

enhanced by including some velocity feedback in the loop in addition to position feedback. An initial design of the Servo subsystem is shown in Figure 2.

corresponding “component model” (although it is often possible to combine the function of multiple components into a single component model). These component models are then connected together (as would be their physical counterparts), to create the overall system model. What lies at the heart of any computer simulation, therefore, are the component models. The “art” of creating the models themselves, and sometimes more importantly, of knowing exactly what to model and why, are the primary keys to successful simulation. Modeling Decisions When setting out to obtain the models necessary for a system design, the following questions should be considered: 1. Which characteristics need to be modeled, and which can be ignored without affecting the results? 2. Does a model already exist? 3. Can an existing model be modified to work in this application? 4. What are the options for creating a new model? 5. What component data is available? These questions will be discussed in turn. Which characteristics need to be modeled, and which can be ignored without affecting the results? While it is important to identify component characteristics that should be modeled, it is equally important to determine what characteristics do not need to be modeled. By simplifying the model requirements, the task of modeling will be simplified as well. The designer’s first inclination is typically to wish for a model that includes every possible component characteristic. However, most situations require only a certain subset of component characteristics. Beyond this subset, the inclusion of additional characteristics is not only unnecessary, but may increase model

Figure 2 - Servo Subsystem

The Servo subsystem consists of a low-pass filter (to filter out quantization noise from the D/A converter), followed by a position control loop with velocity feedback. Position feedback is provided by a potentiometer attached to the motor shaft, and velocity feedback is provided by a tachometer attached to the shaft as well. The motor itself is driven by a power amplifier. The following aspects of the Servo subsystem are of interest from a system design standpoint: 1. Load positioning speed 2. Load position accuracy 3. Stability margins 4. Noise rejection 5. Robustness to parameter variations It is important to consider what specific information is desired from a simulation, as it helps to focus the modeling efforts. For this paper, speed and accuracy are of main concern. The primary components that may affect the speed and accuracy of the Servo subsystem are the low-pass filter, the motor, and the load (power considerations will be deferred until the “Develop Detailed Servo Subsystem” phase of the process). By focusing on these critical components, the fidelity requirements on other component models can be relaxed. Component Models In order to create a system model, each component in the real system will need to have a

System Modeling: An Introduction

-4-

development time as well as the time required to run a given simulation session. For example, suppose a design uses a 10kΩ resistor. To simulate this design, a resistor model is needed. But from the perspective of the design in question, what exactly is a resistor? Is a resistor a device that simply obeys Ohms law, and nothing more? Or does its resistance value vary as a function of temperature? If so, will this temperature dependence be static for a given simulation run, or should it change dynamically as the simulation progresses? What about resistor tolerance? Is it acceptable to assume that the resistor is exactly 10 kΩ? What if the actual resistor component supplied by the manufacturer turns out to be closer to 9.9 kΩ, or 10.1 kΩ (for a +/- 1% resistor)? If the tolerance is important, does the model itself need to account for this tolerance, or is this accounted for by the simulator? Take an op amp as another example. Depending on the application, op amp characteristics such as input current, input offset voltage and output resistance may prove entirely negligible. So is it always necessary to use an op amp model that includes these characteristics? Maybe all that is needed is a high gain block that can be used in a negative feedback configuration. In this case, is it even necessary to include power supply effects in the model? By answering these types of questions, the level of complexity required for any component model can be determined, as well as the corresponding development time that will be needed to create and test it. (Of course, if the goal is to create a re-usable library of component models, then more device characteristics would typically be included in order to make the models as useful as possible to a wide audience of users). Does a model already exist? In a perfect world, all component vendors would produce models of any components they manufacture, in all modeling formats. This is not the case in the real world. But even though all of the required models may not be available, a good
System Modeling: An Introduction

number of them very well may be. Whenever possible, designers should make the most from model re-use. In order to determine the availability of existing models, designers must understand what modeling formats are supported by their simulation tools. One such format, the VHDLAMS hardware description language, is used in depth in subsequent phases of this design. Can an existing model be modified? If an exact model is not already available, it is also possible that a similar model can be found, and re-parameterized or functionally modified in order to serve the design. Before proceeding further, however, a distinction should be made between re-parameterizing a model, and changing the model functionality. Re-parameterizing a model simply means passing in new values, or parameters, which are used by the model equations. The model equations themselves don’t change, just the data passed into them. For example, a resistor model may be passed in the value of 10 kΩ or 20 kΩ. The underlying model doesn’t change, just the value of the resistance. In many cases, by contrast, it is necessary to change the underlying model description itself. Although not as easy as re-parameterizing an existing model, this approach is often faster than creating a new model. What are the options for creating a new model? So how does one actually go about the process of creating simulation models? There are two general “styles” that dominate the modeling landscape today – each with its strengths and weaknesses. The first modeling style uses hardware description languages (HDLs) that have been specifically developed for the purpose of creating models. Creating models with HDLs is often referred to as “behavioral modeling”, but this is a bit misleading as models can be developed in this manner to any desired degree of fidelity.

-5-

Behavioral modeling is discussed extensively in this paper. The second modeling style is one in which a “building block” approach is used to create new models by connecting existing models together in new configurations. This approach is often referred to as “macro-modeling” or “blockdiagram modeling” and is popular with both SPICE-type and control systems simulators. Since one of the purposes of this paper is to instruct the reader in model development, the assumption will be made that all models required for the first phases of the design will need to be created (although the opposite is actually true – all of the models that comprise the Position Controller system were actually available in a library supplied with SystemVision, and would possibly be available from other VHDL-AMS simulator vendors as well). What component data is available? Consideration must also be given to what component data is available in the first place. The capabilities of a model may need to be restricted based on the amount (and quality) of data the component’s manufacturer provides. Servo Subsystem Component Model Development The behavior for each of the analog components required by the Servo subsystem shown in Figure 2 will be considered next. The D/A converter consists of mixed analog/digital functionality, and will be discussed in the Integrate Digital Command and Servo Subsystems phase of the design process. Very simple models will be developed first, followed by models of moderate sophistication. These behavioral descriptions are actually implemented as component models in the next phase of the design process. Power Amplifier The “big picture” functionality of the system is of primary interest in the initial phase of the design. It has also already been determined that the power

amplifier is not a critical component with respect to Servo subsystem speed and accuracy. Therefore, the power amplifier can be initially modeled as a simple gain block with unlimited voltage and current drive capacity. In reality, this system will likely employ a switching amplifier topology to drive the motor. Why then start off with such a simplified model of the power amplifier? Aside from the obvious answer that the time required to develop simple models is less than the time required to develop complicated models, there are two primary reasons why this approach should be considered. First, a switching power amplifier model will typically be driven by a pulse-width modulator (PWM). This device is inherently mixed-signal (i.e. it consists of both analog and digital behaviors). As a result, it will be difficult to perform frequency-domain analysis on a system using such a component. However, frequency domain analysis will prove useful as the control loop is stabilized and the system bandwidth is determined. Second, think about the analog simulation process: a simulator “constructs” the time-domain response for a system model from a collection of system solution points. Each of these solution points represents a corresponding point in time. The time between each of these solutions is called a “time step.” For each one of these time steps, the simulator must solve the entire system model. Further, the solving of each time step is in itself an iterative process, often requiring several passes to get a single time step solution. Whenever waveforms change as the system model is simulated, time steps are generated. The more the waveforms change, the greater the number of time steps required to account for the changes. Systems that include switching electronics have rapidly-changing waveforms by design. As a result, these types of systems can require large amounts of simulation time. A portion of such a waveform is given in Figure 3. For this waveform, each super-imposed “X” represents an actual simulation time step.
-6-

System Modeling: An Introduction

defines the behavior to be implemented. The functionality of each component of the Position Controller system is described in numerous text books, technical papers, and data sheets. In the case of simple models such as a gain block, the mathematical description is fairly intuitive, as shown in Equation (1).

vout = K * vin

(1)

At a high, abstract level, a power amplifier just amplifies an input signal and presents it at the output. Parameter K represents the gain factor. Summing Junction A mathematical description of an ideal summing junction is also fairly intuitive. This behavior can be described as shown in Equation (2). vout = K 1 * vin1 + K 2 * vin 2 (2) Note that optional gain factors (K1 and K2) have been included in the model equation. This allows either input to be optionally scaled, and also allows the model to be changed from a summing junction (e.g. +K1 and +K2), to a differencing junction (e.g. +K1 and –K2). The addition of optional gain coefficients is a recurring theme in many of the models presented in this paper. This is not by accident. Generally speaking, models should be developed so that they are re-usable. By simply adding useradjustable gain coefficients at strategic locations in a model, the model becomes useful to a wider audience at negligible cost in terms of model development time. Potentiometer A potentiometer is a device that generates a voltage level in proportion to a rotational angle. (For greater precision, optical encoders are often employed for this purpose). The behavior of a potentiometer can be expressed as shown in Equation (3). vout = K * anglein (3) The potentiometer behavior is very similar to that of the amplifier behavior shown in Equation (1).

Figure 3 - Example switching waveform

As shown in the figure, it takes quite a few time steps to construct a single pulse in such a system. A 20 KHz switching amplifier could easily require more than 1,000,000 time steps for a 1 second simulation! This is one of the reasons that a simplified model is desired. The important question is: “Can reasonable simulation results be achieved with a simple gain block approach?” The short answer is yes. Even if the actual power amplifier in the system is going to be implemented as a switching amplifier, the gain block representation is acceptable given the following two assumptions: • The frequency of the switching amplifier is much greater than the bandwidth of the control loop (true in the vast majority of designs) • Power consumption is not of great concern in this phase of the design process For the purposes of this paper, these are perfectly reasonable assumptions in the early phases of the overall design. Ultimately, the actual behavior of the switching amplifier will be accounted for, at which time the simple gain block model will be replaced by a switching amplifier model. Now that the scope of the initial power amplifier model has been determined, the next step is to identify a mathematical description that

System Modeling: An Introduction

-7-

The only difference is that the potentiometer input is an angle, rather than a voltage. A potentiometer gain block is also included in Figure 2 in order to reinforce the notion that the potentiometer feedback level is adjustable. This gain block is also used to ensure proper feedback polarity relative to the other input of the summing junction. The tachometer feedback path includes a gain block for the same reasons. Tachometer A tachometer is a component that generates a voltage level that represents a rotational velocity. Physical tachometers are basically smaller motors whose shafts are directly coupled onto the main drive motor’s shaft. As the main motor spins, the smaller motor generates a back-EMF voltage that is proportional to the shaft speed. Since the tachometer is not a “critical” component in this phase of the design, only the behavior of the tachometer needs to be accounted for, not its physical implementation. The tachometer therefore does not need to actually be modeled as a motor at this time. Tachometer behavior can be approximated by differentiating the motor shaft position. This will generate the shaft velocity. The equation describing this behavior is given in Equation (4).
vout = K * d (anglein ) dt

filter behavior using a Laplace transfer function is given in Equation (5).

vout = vin *

ωp s +ωp

(5)

Where ωp is the cutoff frequency in radians per second (rad/s). Equation (5) represents a low-pass filter as a Laplace transfer function with the DC gain normalized to 1. Laplace transfer function descriptions are extremely useful for device behaviors that are described by 2nd or higher-order differential equations. A single pole low-pass filter is a marginal case that is as easily expressed as a differential equation as it is expressed as a Laplace transfer function. This is illustrated next.
Low-pass filter as differential equation

By re-arranging Equation (5) and replacing the Laplace operator s with the differential operator d/dt, the low-pass filter action can also be realized in terms of a differential equation1, as shown in Equation (6).
vin = vout + τ p * dv out dt

(6)

(4)

To implement a model in this manner, the frequency must be converted into a time constant. This conversion is shown in Equation (7). 1 τp = (7)

ωp

Low-Pass Filter As with the other components of this design, the physical implementation of the low-pass filter is not important at this time, but its behavior is. This behavior can be realized in several ways. To illustrate this point, the low-pass filter will be described using three techniques: Laplace transfer function, differential equation, and discrete RC (resistor/capacitor) components.
Low-pass filter as transfer function

Where τp is the time constant in seconds.
Low-pass filter as RC components

Filter behavior is often described using Laplace transfer functions. The description of the low-pass

Both the differential equation and Laplace transfer function approaches for describing the low-pass filter behavior are relatively straightforward and commonly used in practice. The filter behavior can also be described using discrete RC (resistor/capacitor) components. The relationship between the time constant and RC component values is shown in Equation (8).
1

For additional methods to implement the low-pass filter, as well as expanded coverage on the derivations shown here, please refer to Chapter 13 of [1]. -8-

System Modeling: An Introduction

τ p = RC

(8)

The RC implementation of the low-pass filter is illustrated in Figure 4. In this configuration, the low-pass filter is realized by a frequencydependent voltage divider due to changing capacitor impedance. As frequency goes up, capacitor impedance goes down, and the output voltage amplitude drops.

Actuator (Motor) The motor representation must be carefully considered. As a primary focus of the design, the motor in large part determines the overall value of the system model developed in the early design phases. The system model is valuable only to the extent that it can produce useful information that can further guide the system design process. Useful information can only be produced if the motor model is reasonably accurate.
Motor as resistive load

Figure 4 - RC Low-pass Filter

The filter can be modeled using any of these approaches, all of which can be simulated in either the time or frequency domains.

So how might the motor be represented? One approach would be to model it as a pure resistive load, as shown in Figure 5. If the resistance value is chosen to match the winding losses in the motor, then some static or steady-state analyses may be performed. This type of motor model may prove useful for sizing the power amplifier.

Load (Inertia) The load is a fairly critical system component since it will likely represent one of the largest time constants in the entire system. This will directly influence the speed of the system. For this design, the load will be represented as an inertia, the behavior of which is described in Equation (9).
torq = j * dω dt (9)

Figure 5 - Motor as resistive load

In essence, this equation defines how much torque will be required as the load is accelerated (acceleration is calculated as the derivative of the load angular velocity). Equation (9) depicts load torque as a function of (shaft) velocity (ω). The load torque can also be calculated as a function of (shaft) position (θ). This formulation is given in Equation (10). d 2θ torq = j * 2 dt (10)

The drawback to this model, of course, is that it doesn’t take any motor dynamics into account. In addition, this simplistic approach doesn’t even completely model the electrical portion of the motor, which includes winding inductance as well as winding resistance.
Motor as resistive/inductive load

The resistive load motor model can be improved by representing it as a resistor in series with an inductor. This includes the electrical dynamics of the winding – i.e. the winding resistance and inductance, as shown in Figure 6.

This second formulation is used in the Servo subsystem illustrated in Figure 2.

System Modeling: An Introduction

-9-

The dynamic behavior on the mechanical side of a DC motor can be described with Equation (12). torq = − K T * i + d * ω + j * dω dt (12)

Figure 6 - Motor as resistive/inductive load

Although this is an improvement on the previous motor model, the dynamics of the motor are still not represented. For example, there is no accounting for back-EMF, so it will appear that there is more voltage available to drive the motor than there will be in the actual system (since back-EMF will be subtracted from the drive voltage in a real system). A real motor will initially draw a good deal of current from the power amplifier as it tries to overcome the motor shaft inertia, but will then draw less current as the shaft picks up speed. The resistor/inductor model cannot account for this effect because the mechanical inertia of the motor and load are not represented. This model would not provide any real dynamic information – and it is exactly this dynamic information that is needed to verify the overall system topology.
Dynamic motor equations

Equation (12) accounts for motor shaft inertia (j*dω/dt), viscous damping losses (d*ω), as well as the generated torque (KT*i). Together, Equations (11) and (12) provide a reasonable accounting for the dynamic behavior of the motor. A common “control block” model that includes this behavior is given in Figure 7. This model includes all of the basic behaviors of the motor described in Equations (11) and (12), in a fairly intuitive graphical illustration.

Figure 7 - Block diagram of DC motor

A superior approach to modeling the motor is to obtain the fundamental equations which govern motor behavior (widely available from numerous sources), and implement these equations in the model. Using this approach, the dynamic behavior on the electrical side of a DC motor can be described with Equation (11). di (11) dt Equation (11) represents motor winding resistance losses (i*r), inductance losses (l*di/dt), as well as induced back-EMF voltage (KT*ω). v = KT *ω + i * r + l *

As shown in the figure, the terms in the motor descriptions given in Equations (11) and (12) are modeled as functional blocks. Note that the resistance and inductance winding losses are represented by a single Laplace transfer function block (1/(Ls+r)), as are the mechanical damping and inertia (1/(Js+d)). The approach used in Figure 7 is often a convenient way to model mathematical equations. However, as equations grow more complex, or as the number of dependencies between equation variables increases, this approach yields complicated and unintuitive representations. For example, note that the load torque, TL, is fed back into a summing junction in order to be accounted for in the model. This is an example of a modeling approach in which energy conservation is not implicitly built into the models. For such “non-conserved” models, loading effects must literally be fed back in this manner. This is a common situation that can be

System Modeling: An Introduction

- 10 -

avoided by using a conserved-energy modeling approach, which will be considered in the Develop Conceptual Servo Design development phase. Generally speaking, the more complicated the model description, the better the fit to a conserved energy hardware description language such as VHDL-AMS. As shown shortly, all of the motor effects given in Equations (11) and (12) can be quickly and easily described in a VHDL-AMS model. Develop System Model Analysis Strategy Summary All of the Servo subsystem components have now been functionally described. These descriptions are based on common mathematical formulas, and will serve as the foundation for creating the actual component models for the subsystem. This concludes the Develop System Modeling Analysis Strategy phase of the Position Controller system design.
DEVELOP CONCEPTUAL SERVO DESIGN In this phase of the design each of the analog component models required by the Servo subsystem will be developed. This system will be developed with the SystemVision System Modeling Solution by Mentor Graphics Corporation. This simulation environment allows both VHDL-AMS and SPICE models to be freely mixed throughout the design. How to approach the modeling tasks is discussed next. In this conceptual phase of building a useful, yet high-level system model, all of the component models are fairly simple to develop in VHDLAMS. Consideration of how the actual components will be implemented in the physical system will be given in the detailed design phase. At that time, it will prove useful to use preexisting, freely-available SPICE models in addition to VHDL-AMS models. An additional decision needs to be made as well. A “control block” model representation of the motor was previously illustrated. This was referred to as a “non-conserved” model, since

motor loading effects needed to be explicitly modeled with feedback loops and summing junctions. VHDL-AMS supports this nonconserved, control block modeling style, as well as a conserved-energy modeling style. Before engaging in model development, the style or combination of styles to use for the component models should be chosen. Since the Position Controller is fairly simple, either modeling style could be effectively used for this system. However, as it will be easier to graduate to more complex models with a conserved-energy style, conserved-energy component models will be developed.
Power Amplifier As discussed in the Develop System Modeling Analysis Strategy phase, the power amplifier that drives the motor can be thought of as a simple gain block with unlimited voltage and current drive capacity. The functional equation describing the gain block is given in Equation (13). The model descriptions developed in the previous phase will be repeated in this phase for convenience.

vout = K * vin

(13)

This functionality can be easily and directly described in the VHDL-AMS modeling language. Since this component constitutes a first look at VHDL-AMS component modeling, the modeling steps for the gain block will be described in great detail, and several language concepts will be considered. Subsequent model discussions will be less rigorous. VHDL-AMS Models VHDL-AMS models consist of an entity and at least one architecture. The entity defines the model’s interaction with other models, via ports (pins), and also allows external parameters to be passed into the model. The name of the entity is typically the name of the model itself. The behavior of the model is defined within an architecture. This is where the actual functionality of the model is described. A single model may

System Modeling: An Introduction

- 11 -

only have one entity, but may contain multiple architectures. The power amplifier will be developed by first describing its entity, and then its architecture. Entity The entity will serve as the interface between this model and other models. The general structure of an entity for the gain model is as follows:
entity gain is generic ( -- generic (parameter) declarations ); port ( -- port (pin) declarations ); end entity gain;

The port names for this model will be called input and output. Any non-VHDL-AMS keywords may be chosen as port names. Since the decision was made to develop the component models using the “conserved-energy” modeling style, the input and output ports are declared as type terminal. In VHDL-AMS, ports of type terminal obey energy conservation laws, and have both effort (across) and flow (through) aspects associated with them. It is these two aspects that allow terminals to obey energy conservation laws. This declaration is shown as follows:
entity gain is generic ( -- generic (parameter) declarations ); port ( terminal input : electrical; terminal output : electrical ); end entity gain;

The model entity always begins with the keyword entity, and ends with keyword end, optionally followed by keyword entity and the entity name. VHDL-AMS keywords are denoted in this paper by the bold style2. The entity name gain was chosen because this model scales the input voltage by a gain factor, and presents the result at the output. Since the entity name is also the model name, the entity name should accurately describe what the model is, or what it does, so its function can be easily distinguished by the model user. Entities typically contain both a generic section (for parameter passing), and a port section. These are not always required, as parameters are optional, and a system model (the highest level model of the design) may not have any ports. The majority of models, however, will contain both sections. Comments are included in a model by prepending the comment with “--“. The contents of both the generic and port sections in the previous entity listing are comments, and will not be executed as model statements.

2

See Section 1.5 of [1] for a complete list of VHDL-AMS keywords.

A terminal is declared to be of a specific “type.” In VHDL-AMS, the type of a terminal is referred to as its nature. The nature of a terminal defines which energy domain is associated with it. By specifying the word electrical as part of the terminal declarations, both terminals for this model are declared to be of the electrical energy domain, which has voltage (across) and current (through) aspects. One of the reasons for choosing terminals for the ports in the component models is that it allows other “like natured” models to be directly substituted in their place. For example, an ideal gain block could be replaced by an op amp implementation and the ports will correctly match the connecting components. As will be shown shortly, there are other predefined terminal natures besides electrical, such as mechanical, fluidic, thermal, and several others. Note that the gain model is defined with only one input and one output port. This is possible because there is a predefined “zero reference

System Modeling: An Introduction

- 12 -

port” called electrical_ref, which can be used in a model to indicate that the port values are referenced with respect to zero. If the reference port needs to be something other than zero, or if a differential input is required, then a second input port would be added in the entity declaration. An example of how this might appear in the model would be:
port ( terminal in_p, in_m : electrical; -inputs terminal output : electrical -- output );

model is instantiated. Models are not required to have default values for generics. Architecture Model functionality is implemented in the architecture section of a VHDL-AMS model. The basic structure of an architecture definition for the gain model is shown below:
architecture ideal of gain is -- declarations begin -- simultaneous statements end architecture ideal ;

Note how “like-natured” ports are optionally declared on the same line. If this component was modeled with a non-conserved modeling style, the ports would be declared as port quantities, rather than terminals. In that case, the ports would not have across and through aspects. Ports can also be of type signal. These nonconserved ports are used for digital connections. Signal ports will be discussed in the Integrate Digital Command and Servo Subsystems phase of the design. Now that the model’s ports are defined, the model must declare any parameters that will be passed in externally. For the gain model, there is only the gain parameter, K (referred to as a generic in VHDL-AMS). This generic is accounted for as follows:
entity gain is generic ( K : real := 1.0 -- Model gain ); port ( terminal input : electrical; terminal output : electrical ); end entity gain;

The first line of this model architecture declares an architecture called “ideal.” This architecture is declared for the entity called “gain”. As with entities, the model developer also selects the names for architectures. For this model, “ideal” was chosen as the architecture name since this is an idealized, high-level implementation. “Behavioral” or “simple” could just as well have been chosen to denote this level of implementation. The actual model equations(s) appear between the begin and end keywords, which indicate the area where simultaneous equations and concurrent statements are located in the model (concurrent statements will be discussed in the Integrate Digital Command and Servo Subsystems phase). The basic equation for the gain component given in Equation (13) can be implemented as follows:
architecture ideal of gain is -- declarations begin vout == K * vin; end architecture ideal ;

Generic K is declared as type real, so it can be assigned any real number. In this case, it is given a default value that will be used by the model if the user does not specify a gain value when the

In VHDL-AMS, the “==” sign indicates that this equation is continuously evaluated during simulation, and equality is maintained between the expressions on either side of the “==” sign at all times. The next step is to declare all undeclared objects used in the functional equation. In this
- 13 -

System Modeling: An Introduction

case vin and vout need to be declared (K was declared in the entity). Declarations for vin and vout are shown below:
architecture ideal of gain is quantity vin across input to electrical_ref; quantity vout across iout through output to electrical_ref; begin vout == K * vin; end architecture ideal ;

port names in_p and in_m), then the branch quantity declaration would appear as follows:
quantity vin across in_p to in_m;

Since the electrical terminals of this model have both voltage (across) and current (through) aspects associated with them, these terminals cannot be directly used to realize the model equation. Instead, individual objects are declared for each terminal aspect, and these objects are then used to realize the model equation. In VHDL-AMS, analog-valued objects used to model conserved energy systems are called branch quantities. Branch quantities are used extensively in the component models that comprise the Position Controller system model. Vin and vout are declared as branch quantities. Branch quantities are so-named because they are declared between two terminals. Branch quantities for the gain model are illustrated in Figure 8.

Figure 8 - Branch quantities

The single input port approach was chosen for the gain model. Should this input present a representative load (i.e. draw current from whatever is driving it)? Since this is the conceptual phase of the system model development, it makes sense to have the model act as an ideal load (i.e. no current will be drawn from whatever is driving it). This goal is achieved on the input port of the model by simply omitting any reference to the input current in the model description. In other words, no branch quantity is declared for this current. By not declaring a quantity for it, the input current is zero by default. What about the output port? The gain component was earlier described as an idealized component that can supply unlimited output voltage and current. These are the primary qualities of the component model that make it “ideal.” The model’s output port needs to supply any voltage and current required by whatever load is connected to it. To achieve this capability, through quantity iout is declared along with across quantity vout. The simulator will thus solve for whatever instantaneous value of iout that is required to ensure vout is the correct value to maintain equality for the expressions in the equation:
vout == K * vin;

Branch quantity vin is declared as the voltage across port input relative to ground (electrical_ref). Electrical_ref can be thought of as a reference terminal (like a ground pin). Branch quantity vout is declared as the voltage across port output relative to electrical_ref. As discussed earlier, the gain model could have been declared with two ports, in which case using electrical_ref within the model would be unnecessary. If this were the case (assuming input

Model Solvability When solving simultaneous equations, the general rule is that there must be an equal number of unknowns and equations. Computer-based simulation tools typically use Nodal-like analysis to solve systems of equations. This basically means that the computer “picks” the across branch quantities at the various nodes in a system

System Modeling: An Introduction

- 14 -

model, and solves for the corresponding through branch quantities. The simulator solves systems of equations by applying energy conservation laws to through branch quantities. For electrical systems, this means that Kirchoff’s Current Law (KCL) is enforced at each system node. For mechanical systems, Newton’s laws are enforced. A VHDL-AMS model with conservationbased ports must therefore be constructed such that a through branch quantity is declared for each model equation – even if the through quantity itself is not used in the equation! In the case of the gain model, quantity iout is needed to satisfy this requirement. Libraries and Packages Models often require access to data types and operations not defined in the model itself. VHDLAMS supports the concept of packages to facilitate this requirement. A package is a mechanism by which related declarations can be assembled together, in order to be re-used by multiple models. The IEEE has published standards for several packages. Such standards have been defined for various energy domain packages, including electrical_systems, mechanical_systems, and fluidic_systems, among others. It is within these packages that the across and through aspects for each energy domain are declared. For example, the electrical_systems package declares voltage and current types. This is shown in the code fragment listed below:
nature ELECTRICAL is VOLTAGE across CURRENT through ELECTRICAL_REF reference;

library IEEE; use IEEE.electrical_systems.all;

These statements allow the model to use all items in the electrical_systems package of the IEEE library. This package also includes declarations for charge, resistance, capacitance, inductance, flux, and several other useful types. The complete VHDL-AMS gain model is given below:
library IEEE; use IEEE.electrical_systems.all; entity gain is generic ( K : real := 1.0 ); -- Model gain port ( terminal input : electrical; terminal output : electrical ); end entity gain; architecture ideal of gain is quantity vin across input to electrical_ref; quantity vout across iout through output to electrical_ref; begin vout == K * vin; end architecture ideal ;

This gain model is also used for the Ktach and Kpot blocks shown in Figure 2.
Summing Junction The summing junction functional description is given in Equation (14).

vout = K 1 * vin1 + K 2 * vin 2

(14)

A complete summing junction model, summer, is shown below:
library IEEE; use IEEE.electrical_systems.all; entity summer is generic ( K1 : real := 1.0; -- Input1 gain K2 : real := 1.0 ); -- Input2 gain port ( terminal in1, in2 : electrical; terminal output : electrical );

Packages are typically organized into libraries. For example, all of the IEEE energy domain packages are included in the IEEE library. In the case of the gain model, the electrical_systems package is used. This is specified in the model as follows:

System Modeling: An Introduction

- 15 -

end entity summer; architecture ideal of summer is quantity vin1 across in1 to electrical_ref; quantity vin2 across in2 to electrical_ref; quantity vout across iout through output to electrical_ref; begin vout == K1 * vin1 + K2 * vin2; end architecture ideal ;

The summer’s entity passes two generics, K1 and K2, into the architecture. The default configuration for this model is to have no gain on either input (i.e. gain = 1). The Summer’s architecture appears quite similar to that used for the gain model. In this case, there are now two input ports, and a separate branch quantity is declared for each, vin1 and vin2.
Potentiometer The potentiometer behavior can be expressed as shown in Equation (15).

The potentiometer model contains a nonelectrical input port. Just as mixed-analog/digital models are referred to as “mixed-signal” models, models such as the potentiometer are referred to variously as mixed-technology, multi-technology, multi-domain, and multi-physics models. The potentiometer model represents the first departure from an all-electrical model encountered thus far in the design. The model’s input port is still declared as a terminal. The terminal is declared with a rotational nature, which has rotational angle (across) and torque (through) aspects associated with it. This means that mechanical energy conservation laws will apply to this port. Note that the mechanical branch quantity is internally referenced to rotational_ref (as opposed to electrical_ref). In order to access standard mechanical data types, the IEEE.mechanical_systems package is included in the model.
Tachometer The tachometer functionality is expressed as shown in Equation (16).
vout = K * d (anglein ) dt

vout = K * anglein

(15)

The complete potentiometer model is shown below:
library IEEE; use IEEE.mechanical_systems.all; use IEEE.electrical_systems.all; entity potentiometer is generic ( k : real := 1.0); -- optional gain port ( terminal input : rotational; -- input terminal terminal output : electrical); -- output terminal end entity potentiometer ; architecture ideal of potentiometer is quantity ang_in across input to rotational_ref; quantity v_out across i_out through output to electrical_ref; begin v_out == k*ang_in; end architecture ideal;

(16)

The tachometer model is listed below:
library IEEE; use IEEE.mechanical_systems.all; use IEEE.electrical_systems.all; entity tachometer is generic ( k : real := 1.0); -- optional gain port ( terminal input : rotational; -- input terminal terminal output : electrical); -- output terminal end entity tachometer ; architecture ideal of tachometer is quantity ang_in across input to rotational_ref; quantity v_out across out_i through output to electrical_ref; begin v_out == K * ang_in'dot; end architecture ideal;

System Modeling: An Introduction

- 16 -

The VHDL-AMS modeling language provides a mechanism for getting information about items in a model. Several predefined attributes are available for this purpose3. In the tachometer model, the predefined attribute ‘dot is used to return the derivative of quantity ang_in. Thus v_out will continuously evaluate to the derivative of ang_in (times K). Other popular predefined analog attributes include ‘integ (integration), ‘delayed (delay), and ‘ltf (Laplace transfer function). The ‘ltf attribute will be used in the low-pass filter model discussed next.
Low-Pass Filter As discussed previously, directly implementing a Laplace transfer function for the low-pass filter is quite convenient. This description is given in Equation (17).

vout == K * vin'ltf(num, den); end architecture ideal ;

vout = vin *

ωp s +ωp

(17)

This low-pass filter description may be implemented directly using VHDL-AMS. The complete VHDL-AMS model for the low-pass filter is listed below:
library IEEE; use IEEE.electrical_systems.all; use IEEE.math_real.all; entity LowPass is generic ( Fp : real := 1.0e6; -- Pole frequency [Hz] K : real := 1.0); -- Filter gain port (terminal input : electrical; terminal output : electrical); end entity LowPass; architecture ideal of LowPass is quantity vin across input to electrical_ref; quantity vout across iout through output to electrical_ref; constant wp : real := math_2_pi*Fp; constant num : real_vector := (wp, 0.0); constant den : real_vector := (wp, 1.0); begin
3

This low-pass filter implementation uses the (Laplace transfer function) attribute to implement the transfer function in terms of num (numerator) and den (denominator) expressions. These expressions must be constants of type real_vector. The real vectors are specified in ascending powers of s, where each term is separated by a comma. Since num and den must be of type real_vector, these vectors must contain more than one element. However, numerator num only contains a single element, so a second element, 0.0, is added to satisfy the multiple element restriction4. The low-pass filter term from Equation (17) is declared as constant wp, in radians. Since the user specifies a cutoff frequency in Hertz (Fp), a conversion from Hertz to radians is performed, the results of which is assigned to wp. Constant math_2_pi is used for this conversion. It is defined along with many other math constants in the IEEE.math_real package, which must be included in the model description in order for items within it to be accessed by the model. The ‘ltf attribute is a very powerful and convenient tool for describing Laplace transfer functions. It is particularly useful for describing higher-order systems, which can be difficult to express using time-based equations. The ports of the low-pass filter model are declared as electrical terminals. This allows any of the filter implementations given in Equations (5), (6), or Figure 4 to be directly substituted for each other in the system model.
‘ltf

Load It is ultimately the system load that needs to be positioned (via the motor shaft). As far as the system is concerned, this load acts as extra inertia to the motor, and can be expressed as shown in Equation (18).
4

See Section 22.1 of [1] for a complete list of predefined attributes.

Constant wp can also be assigned to a single element in a real_vector using the following syntax: (0=>wp). - 17 -

System Modeling: An Introduction

d 2 (anglein ) torque = J * dt 2

(18)

This behavior can be implemented as a VHDL-AMS model as shown below:
library IEEE; use IEEE.mechanical_systems.all; entity inertia_r is generic (j: moment_inertia); -- Kg*meter**2 port (terminal rot1 : rotational); end entity inertia_r; architecture ideal of inertia_r is quantity theta across torq through rot1 to rotational_ref; begin torq == j * theta'dot'dot; end architecture ideal;

languages. All of these motor effects (and more) can be quickly and easily described in a model, using the governing equations themselves. The VHDL-AMS version of the DC motor model is listed below.
library IEEE; use IEEE.mechanical_systems.all; use IEEE.electrical_systems.all; entity DCMotor_r is generic ( r_wind : resistance; -- Winding resistance kt : real; -- Torque Constant l: inductance; -- Winding inductance d: real; -- Damping coefficient j: moment_inertia); -- MOI port (terminal p1, p2 : electrical; terminal shaft_rot : rotational); end entity DCMotor_r; architecture basic of DCMotor_r is quantity v across i through p1 to p2; quantity theta across torq through shaft_rot to rotational_ref; quantity w : real; begin w == theta'dot; torq == -1.0*kt*i + d*w + j*w'dot; v == kt*w + i*r_wind + l*i'dot; end architecture basic;

The inertial load model contains only a single mechanical port. Since rotational angle (rather than rotational velocity) was chosen as the across quantity for this port, the actual model equation is formulated in terms of port angle, theta. Theta is differentiated twice before being multiplied by the moment of inertia, J, to produce torque. Note that multiple ‘dot attributes can be applied in succession for this purpose.
Motor In the Develop System Modeling Analysis Strategy phase two equations which govern DC motor behavior were introduced:

v = KT *ω + i * r + l *

di dt

(19)

dω (20) dt Equations (19) and (20) provide a practical representation for the dynamic behavior of the motor. Unlike the non-conserved “control block” model implementation introduced in Figure 7, Equations (19) and (20) can be directly implemented in a VHDL-AMS model. This is one of the strengths of hardware description torq = − K T * i + d * ω + j *
System Modeling: An Introduction

The motor model is easily implemented by extending the concepts discussed throughout this paper. Of special note is the actual implementation of the motor’s equations: Since the overall design is a position controller (as opposed to a velocity controller), the model’s mechanical port is declared in terms of motor shaft angle (theta). However, it is also desirable to describe the model equations in terms of velocity (w), rather than angle. This is accomplished by declaring an intermediate quantity, w. This is referred to as a free quantity, and it represents the shaft velocity. Free quantities are used when analog valued objects are required that do not have branch aspects associated with them. For model solvability, each free quantity requires one

- 18 -

simultaneous equation to be introduced into the model. Note that these simultaneous equations are virtually identical to those given in (19) and (20). This direct “mapping” between physical component descriptions and model representation is one of the great benefits of the HDL-based modeling approach. The more direct the mapping, the more intuitive the model.
Simulation and analysis Every component in the Servo subsystem now has a corresponding VHDL-AMS model. The next step is to create the overall system model out of the component models. This is typically accomplished by creating a graphical symbol for each component model, and then connecting the ports of the symbols using a schematic capture environment. The symbols map to an underlying model, and the symbol pins correlate to model ports. This was the approach used to create the Servo subsystem schematic illustrated in Figure 2. The next step is to parameterize the component models if necessary. The following parameter values are used for this design: lowpass filter cutoff frequency = 50 Hz; power amplifier gain = 1000; potentiometer gain = 5; tachometer gain = 0.01. The motor was characterized to drive a 10e-6 Kg*m2 inertial load. With the system model complete, various simulations can be performed to determine overall system performance. Since the purpose of this paper is to instruct in the development of a system model, and not to debug and analyze a Position Controller system, only a few analysis results are given. To actually debug a real system, many simulations would be performed throughout the design process and beyond.

overall bandwidth of about 46 Hz. The low-pass filter (set at 50 Hz) dominates this response. The bandwidth of the control loop itself is near 200 Hz.

Figure 9 - Closed-Loop Frequency Response

Additional frequency-domain analyses that should be performed include:
• • • Open-loop phase/gain margin Loop optimization Filter settings/system bandwidth tradeoffs

Time Domain Response The closed-loop time domain response to a specific positioning profile is given in Figure 10. Three waveforms are indicated: the input position profile command, the output of the lowpass filter, and the load position profile.

Frequency Domain Analysis Results A closed-loop frequency domain analysis was performed to determine the system bandwidth. The result of this analysis is shown in Figure 9. This waveform was measured at the position feedback summing junction. It indicates an

Figure 10 - Closed-Loop Transient Response

System Modeling: An Introduction

- 19 -

The waveforms indicate that the load does in fact track the input command profile. How well does it track? Now that a working system model is available, several simulations can be performed, and the results measured and analyzed. Gains can be tweaked, and assumptions can be checked. For example, it was mentioned earlier that velocity (tachometer) feedback would help stabilize the control loop, as well as enhance the overall response. The system model can now be used to determine how much tachometer feedback is required to achieve acceptable performance. Figure 11 shows load position waveforms as a function of changing the tachometer component model gain values from 0.005 to 0.05 in steps of 0.005. The subsystem is driven by a voltage pulse with a 1 ms rise-time. The amount of ringing decreases as tachometer gain is increased, as expected.

Figure 12 - Motor overshoot versus tachometer gain

This waveform illustrates that position overshoot can be virtually eliminated with a tachometer gain value of 0.009 or greater. (However, if the tachometer gain is increased too much, the system response will start to slow down). The initial value of 0.01 should be sufficient for the tachometer gain. Develop Conceptual Servo Design Summary All of the Servo subsystem components that were mathematically described in the Develop System Modeling Analysis Strategy phase have now been modeled in the VHDL-AMS modeling language. The seamless mapping of abstract mathematical descriptions to actual model implementations is one of the benefits of VHDL-AMS. This concludes the Develop Conceptual Servo Design phase of the Position Controller design.

Figure 11 - Motor output versus tachometer gain

These results can be quantified by performing an overshoot measurement on them, and displaying the overshoot values as a function of tachometer gain values. These results are illustrated in Figure 12.

DEVELOP DETAILED SERVO DESIGN Thus far, a simulatable conceptual system model has been developed and used to verify an acceptable value for the tachometer feedback gain. A possible next step is to consider “upgrading” various component models to account for the eventual physical implementation of the system. What does this mean? Recall that the original goal was to develop a “system model” of the Position Controller. This system model was to be used to provide information as to whether the

System Modeling: An Introduction

- 20 -

design topology was sound (the example of the tachometer feedback gain was used to demonstrate the usefulness of the conceptual model). In the conceptual model the physical implementation of the various components was not considered. Now that simulation results have shown that the topology is indeed sound, a choice needs to be made: build the actual design, or increase the value of the system model even more to reduce risks in the physical system later? Another option is to do both concurrently. Part of the “art” of designing a system is to be able to make the transition from simulation model to physical prototype at some reasonable point in the design process. Some designers jump as quickly as possible into “real hardware,” and may even forego the use of simulation as a tool altogether. Others tend put off building the physical system as long as possible and continue refining the system model. Where should the line be drawn? It really depends on the amount of risk that is acceptable for the specific design. For example, invasive medical devices or spacerelated systems cannot tolerate failure. For these types of systems, highly-refined system models are often used in conjunction with physical prototypes to minimize risks. On the other hand, non-critical systems do not need to be so rigorously developed, but still benefit from system models. Such models can help minimize system performance degradation due to part tolerances stemming from manufacturing variability. Part costs can be minimized as well. Additionally, having access to a simulatable system model can help to improve overall system robustness, and foster a better understanding the system in general. In the case of the Servo subsystem, a fairly high-level subsystem model has been developed, which among other things, does not account for the power delivery system. Such systems are often the trickiest parts of a design, and should be fully explored using simulation technology.

For the sake of brevity, only a few component models for the Servo subsystem will be refined in this paper. These are: • Low-pass filter • Summing Junction • Power Amplifier
Low-pass filter implementation Op amps (operational amplifiers) are commonly used to implement analog functions. Both the low-pass filter and summer functions will be implemented using op amps. Since there are no special restrictions on the Position Controller design in terms of high-bandwidth or low-noise, generic op amps can be used for these implementations. LM307 op amps, which are inexpensive, and intended for general purpose use, will be selected for this application. The low-pass filter can be implemented with an op amp as shown in Figure 13. The RC values are calculated using the relationship described by Equation (8).

Figure 13 - Low-pass filter implementation

What op amp characteristics should (and should not) be modeled? There are really no special requirements for the op amp model, as it is being used in a very general manner. However, the model should take power supply levels into account as this can affect the system bandwidth (the ideal power amplifier allowed unlimited voltage and current). As discussed in the Develop System Modeling Analysis Strategy phase of the design process, a check to see if a required model already exists should be made. Although a VHDL-AMS model can be developed for the LM307 op amp, it (along
- 21 -

System Modeling: An Introduction

with hundreds of other op amp models) is already available in SPICE format. Since the SystemVision System Modeling Solution allows any combination of VHDL-AMS and SPICE models in a design, it makes sense to use a SPICE model for this component.
Summing junction implementation The summing junction can be implemented as shown in Figure 14. This is a standard inverting op amp implementation with three inputs to accommodate the low-pass filter output, potentiometer feedback, and tachometer feedback. A small feedback capacitor is added to filter out high frequency noise. The SPICE-based LM307 model will also be used for the summing junction implementation.

the MOSFET gates in the H-bridge. The PWM accepts analog inputs, and produces two digital outputs that are the logical opposite of each other. This operation is illustrated graphically in Figure 15. The upper output pin puts out a pulse width whose duty cycle is proportional to positive analog inputs. The lower output pin puts out a pulse whose duty cycle is proportional to negative analog inputs.

Figure 15 - PWM operation

Figure 14 - Summing junction implementation

Power amplifier implementation At the Develop System Modeling Analysis Strategy phase of the design process, a very ideal, high level power amplifier model was developed. The reasoning was that detailed power delivery analysis was not critical in the beginning phases of the design. The power amplifier will now be reimplemented as a full-fledged switching amplifier. Such an amplifier consists of three basic building blocks: a pulse-width modulator, an H-bridge, and H-bridge gate drivers.

Pulse-width modulator The pulse-width modulator (PWM) is required to convert analog control loop commands into corresponding pulse widths that are used to drive
System Modeling: An Introduction

H-bridge with PWM The H-bridge represents the largest design change between the conceptual and detailed Servo subsystem designs. The H-bridge is illustrated in Figure 16. Assume that a motor is connected between the MOT_P and MOT_M terminals of the H-bridge. The basic concept behind the H-bridge topology is as follows: if the upper-left (M1) and lowerright (M4) MOSFETs are driven on together, then current will flow from the power supply through M1, through the motor terminals, through MOT_P and MOT_M, and back out through M4. This will cause the motor shaft to rotate in one direction. If M1 and M4 are then driven off, and M3 and M2 are driven on, current will flow through the motor, but in the opposite direction. This will cause the motor shaft to rotate in the opposite direction. The “fly-back” diodes across each MOSFET are used to provide a path for current to flow during switching, since the inductance of the motor will not allow the current to switch instantaneously. Without the fly-back diodes, very large voltage spikes will result from the abrupt disruption in motor current.

- 22 -

Assuming that the power required for the current application of the Position Controller is fairly small, the power for the H-bridge comes from the voltage supplies that are used by the op amps.

Figure 16 - H-bridge motor driver

The key H-bridge component is the MOSFET. As with op amp models, there are numerous MOSFET models available in SPICE format. Since appropriate models exist, there is no need to develop one. An IRF150 MOSFET model will be used for this design. Why use an H-bridge configuration when the same performance could be achieved with a simple push-pull configuration requiring only two MOSFETs? One of the unstated goals of this design topology is that it needs to be easily reconfigured for different sized loads. In the case of a fairly light load (as is demonstrated here), the standard +/-12 volts available for the on-board op amps are sufficient to drive the load. However, as the motor/load increase in size, higher voltage levels will be required. In such cases it is more efficient to have a single high voltage supply rather than two of them. H-bridge topologies are popular for this use: driving a motor bi-directionally from a single power supply. The requirement for higher voltage levels is also the reason IRF150 MOSFETs were chosen (which are somewhat over-sized for this particular load).

Gate Drivers Each MOSFET in Figure 16 is driven by a special gate-drive component. The purpose of this component is two-fold: first, MOSFETs are most efficient when driven hard into the “fully on” position. Capacitance exists between the gate and source of the MOSFET, and a driver with good current drive capacity is required to quickly charge this capacitance. The second reason the gate-drive component is required is due to changing reference levels. The sources of the upper MOSFETs actually “float” up when switched on. This means that the gate-drive must also float up, or it will be unable to keep the FET on. This is accomplished by referencing the gate-drive output to the source of the FET. The gate-drive component accepts a digital (logic) input from the PWM, and converts it to a differential analog output. The positive pin of the differential drives the FET gate, and the negative pin drives the FET source.
Servo Subsystem All of the individual models for the implementation phase of the design are combined as shown in Figure 17, which represents the complete detailed Servo subsystem.

Figure 17 – Detailed Servo subsystem

Figure 18 shows the switching voltage across the motor input terminals for several PWM cycles. The resulting motor current is also shown. The figure illustrates a positive average motor current (resulting in clockwise shaft rotation) in response to a positive input profile command. Note that the duty cycle of the MOT_P motor terminal is much greater than that of the MOT_M terminal.

System Modeling: An Introduction

- 23 -

anticipate and fix any design issues – before actual hardware is built. In fact, since the conceptual simulation results match the detailed results, the conceptual system model can be used for the majority of subsequent (non-power oriented) analyses. Further Servo subsystem analyses will not be pursued in this paper. However, the overall Position Controller system design will be taken to the next level by adding in the Digital Command subsystem model. Develop Detailed Servo Design Summary In this phase of the Position Controller development, selected components were modeled in more detail than in the conceptual design phase. This was done in order to produce a system model that more closely matches the eventual hardware implementation of the system. This concludes the Develop Detailed Servo Design phase of the Position Controller design.
INTEGRATE DIGITAL COMMAND AND SERVO SUBSYSTEMS The Digital Command subsystem represents quite a different challenge than did the Servo subsystem. This is because it is assumed that the Digital Command subsystem is designed by a different engineer than the Servo subsystem designer. However, the Servo designer still needs to perform some “system level” analyses to determine unanticipated systemic interactions that will likely occur between the subsystems. It can be very costly in terms of both time and money to discover such interactions in the prototyping and production phases of the design process. There are other system level issues to explore as well. Recall in previous phases of this design that from a system design standpoint, the following aspects of the Position Controller are of interest: • Load positioning speed • Load position accuracy

Figure 18 - H-bridge waveforms and motor current

The load positioning results from simulating both conceptual and detailed Servo subsystem models are given in Figure 19. As shown in the figure, there is quite a good match between these subsystem models.

Figure 19 - Conceptual/Detailed Servo waveforms

Now that the Servo subsystem is completely implemented, is it time to build a prototype? Actually, now is the time to start really testing out various aspects of the system model. “What-if” tradeoffs can be made, performance as a function of component tolerances can be determined, and many other analyses can be performed. This is the pay-off for the model development effort. Now the system model can be used to
System Modeling: An Introduction

These performance measures have already been investigated with the Servo subsystem
- 24 -

model. However, analysis of the Servo subsystem alone cannot account for the effect of Digital Command quantization noise. in other words: how many bits does the system really need to be to satisfy accuracy specifications, and to what value should the overall conversion rate be set? To answer these questions, some sort of subsystem model for the Digital Command subsystem will be needed. The question then becomes “What aspects of the Digital Command subsystem need to be modeled in order to perform reasonable system-level analysis?” What the servo designer really needs is a test bench in which discrete versions of the input position profile can be produced, just as they would be generated by the Digital Command subsystem. But the servo designer does not really want to implement the full Digital Command subsystem. So, how can a test bench be designed without developing a complete Digital Command subsystem model? A simple approach would be to employ the D/A converter to convert digitally-generated profiles into their analog equivalents. Although possible, how will the digital profiles be generated? What is really needed is an analog waveform that is digitized, then converted back into its quantized analog equivalent. This approach yields a reasonable solution: an easily programmable position profile, and a quantized reproduction of the profile to be used as the input to the Servo subsystem. A Digital Command subsystem test bench topology that achieves this goal is illustrated in Figure 20.

bits. This level of information would be readily available in any subsystem specification. A more detailed representation of the Digital Command subsystem is given in Figure 21.
Pulse Gen
V_IN OE EOC LATCH

A/D Clk Delay

BUS

D/A

Load

Start

Figure 21 - Digital Command Subsystem Test bench

A2D

D2A

This subsystem works as follows: when a Start pulse is generated, the A/D converter samples the analog input, V_IN. This analog value is digitized one bit per clock (Clk) cycle, until all 10 bits are updated. When all 10 bits are set, the A/D sets the end-of-conversion (EOC) pin high. The EOC output is fed into an edge-to-pulse generator. When EOC goes high, the pulse generator produces a pulse of user-definable width. This pulse enables the OE pin on the A/D, which allows the 10 bit values to be placed on its output pins. The output pins drive a bus connected between the A/D output and D/A input. The pulse driving the OE pin on the A/D also drives the latch pin on the D/A through a buffer. The buffer includes a delay to allow the A/D pins to stabilize to their new values before the D/A latches them in. Once latched, the digital bits are converted into an analog value after a “conversion” delay. The cycle then repeats itself with the next Start pulse.
Digital Command subsystem component model development The various component models required by the Digital Command subsystem will now be developed. As with the Servo subsystem, the Digital Command subsystem will be developed with the SystemVision System Modeling Solution by
- 25 -

Figure 20 - Digital Command Subsystem Block Diagram

The beauty of this approach lies in its simplicity: an output for the Digital Command subsystem can be generated without knowing anything about the Digital Command subsystem itself, except its conversion rate and number of
System Modeling: An Introduction

Mentor Graphics Corporation. These component models will be developed with the same approach used in the Servo subsystem design. All of the analog portions of the component models will be developed using the conserved-energy modeling style. Buffer The buffer (Delay) component simply reproduces the input signal at its output, after an optional delay time. The VHDL-AMS model listing for the buffer is shown below:
library ieee; use ieee.std_logic_1164.all; entity buf is generic ( delay : time := 0 ns); -- Delay time port ( input : in std_logic; output : out std_logic); end entity buf; architecture ideal of buf is begin output <= input after delay; end architecture ideal;

All of the signal ports in this paper will be of type std_logic. Several “digital logic” packages, including std_logic, have been predefined in the IEEE.std_logic_1164 package. Signal ports also have a direction: in, out, or inout. Port input of the buffer model is declared as type in, and port output of the buffer is declared as type out. The actual functionality of the model is described in the architecture with the following statement:
output <= input after delay;

This statement reads “signal output takes on the value of signal input after a time specified by delay.” This expression is referred to as a concurrent signal assignment statement. This is a quite convenient format for expressing simple signal assignments. It is actually a shorthand notation for the formal digital description mechanism in VHDL-AMS: the process. Processes will be discussed shortly. Pulse Generator The pulse generator component converts a signal edge into a user-specified pulse width. This sort of behavior can be implemented directly as a single behavioral model. It can also be conveniently implemented as a structural model using a collection of basic logic gates (structural modeling is basically equivalent to the macromodeling approach discussed earlier). In order to illustrate the structural-modeling approach, the edge-to-pulse generator is implemented as shown in Figure 22.
EDGE IN PULSE OUT

There are some differences between this digital model and the analog models discussed previously. First, the ports are declared with a slightly different syntax: the type of port does not need to be specified. If no port type is specified, it is assumed to be of type signal. Signal ports do not have “natures.” However, several types of signals exist. Std_logic is a general purpose signal type that allows a signal to take on one of the following enumerated values:
‘U’ (Uninitialized) ‘X’ (Forcing unknown) ‘0’ (Forcing zero) ‘1’ (Forcing one) ‘Z’ (High impedance) ‘W’ (Weak unknown) ‘L’ (Weak zero) ‘H’ (Weak one) ‘-‘ (Don’t care)

DELAY = PW

Figure 22 - Edge-to-Pulse Generator

The edge-to-pulse generator works as follows: assume a positive going edge appears on the input pin, EDGE_IN. A logic ‘0’ appears at the input
- 26 -

System Modeling: An Introduction

inverter’s output. This ‘0’ is passed through to an input to the OR gate. It is also passed through another inverter, which after a delay, presents a ‘1’ at the input of the OR gate. Thus the output of the OR gate is a ‘0’ from the time the edge appears at the input of the device, until after the second inverter’s delay, at which time the OR gate output goes to a ‘1’. All of this time, the output inverter is presenting the logical opposite of the OR gate output to the device output pin. So the device output goes from an initial value of ‘0’ to a value of ‘1’, and then back to a value of ‘0’. The duration of the positive pulse is equal to the user-definable delay of the second inverter. The architectures for both the inverter and OR gate models will be briefly discussed next.
Inverter (pulse generator)

case, the two input pins, in1 and in2 are logically OR’ed, so that the output pin will go high when either input pin goes high (after a time specified by delay). Clock A representative method for implementing a digital clock in VHDL-AMS is shown next. This method introduces the concept of a process. Processes are fundamental to both digital and mixed-signal VHDL-AMS component modeling.
clk_gen : process begin clk_out <= '1'; wait for on_time; clk_out <= '0'; wait for off_time; end process clk_gen;

A digital inverter is similar to a buffer, but the inverter produces at its output the logical opposite of the signal appearing at its input. The architecture for the inverter model is given below:
architecture ideal of inverter is begin output <= not input after delay; end architecture ideal;

The inverter model listing is identical to that of the buffer model, with the exception of the not operator preceding the input signal. This means that signal output takes on the logical opposite of signal input after a time specified by delay.
OR gate (pulse generator)

Process statements between the begin and end process keywords are sequentially executed. Processes themselves are concurrent statements, and are executed simultaneously with respect to one another. Signals may be assigned new values within processes. However, these signals take on the new values only after the process execution suspends. Process execution is controlled with wait statements. When wait statements are encountered in a process, the process execution suspends. How long it suspends depends on the form of the wait statement. There are three wait statement forms:
wait on – wait on a signal value change wait for – wait for some amount of time wait until – wait until boolean true condition

The two-input OR gate produces a ‘1’ at its output whenever either input is ‘1’. Otherwise, its output is ‘0’. The architecture for a two-input OR gate model is given below:
architecture ideal of or2 is begin output <= in1 or in2 after delay; end architecture ideal;

The clock process works as follows: when the simulation begins, the process is automatically executed during the process execution phase of the simulation cycle (at the beginning of a simulation, signals are updated first, then processes are executed. This is a result of the VHDL-AMS digital simulation cycle)5.
5

The OR gate model listing is again quite similar to the buffer and inverter models. In this
System Modeling: An Introduction

Please refer to Chapter 7 of [1] for a comprehensive discussion of the VHDL-AMS simulation cycle. - 27 -

Signal clk_out is scheduled to take on the value ‘1’, and then the process suspends until a time duration of on_time has elapsed. When the process suspends, signal clk_out is changed to ‘1’. The process remains suspended until the time specified by on_time elapses, at which time the process resumes execution, and clk_out is scheduled to take on the value ‘0’. Once again, the process suspends for an additional length of time, determined by the value of off_time. When the process suspends this time, clk_out is changed to its newly-scheduled value, ‘0’. The process remains suspended until the amount of time specified by off_time elapses, at which time the process reaches the end process keywords, causing the process to start over from just below the begin keyword. In this manner, the process is continuously executed, producing a digital clock signal, the period of which is on_time + off_time. Note how on_time and off_time are interpreted relative to “simulation time.” In the previous digital model examples, a process statement was not explicitly used. In essence, a shorthand notation was employed with implied wait on statements, the arguments of which were the input ports of the model. For example, the OR gate model’s behavior is governed by the following:
output <= in1 or in2 after delay;

Digital-to-Analog (D/A) Converter The D/A model is fairly lengthy, so only the central process which is the “heart” of the model will be discussed6. The overall idea of the D/A model is to sum weighted voltage values that correspond to each input bit in the converter. The MSB is assigned ½ the full-scale voltage range of the converter, the next bit is assigned ¼ the full-scale range, and so on. The voltages corresponding to all of the high input bits are then summed together. This voltage sum is then placed on the D/A’s output terminal.
proc : process variable v_sum : real; variable delt_v : real; begin wait until (latch'event and latch = '1'); v_sum := 0.0; delt_v := (vmax - vmin)/2.0; for i in high_bit downto low_bit loop delt_v := delt_v / 2.0; if bus(i) = '1' or bus(i) = 'H' then v_sum := v_sum + delt_v; end if; end loop; sum_out <= v_sum; end process; vout == sum_out'ramp(tr, tf);

Implied in this notation is an unseen “wait on in1 or in2” statement. This implied statement causes the model to respond to changes on either in1 or in2. The wait on statement can also be used at the beginning of a process in the form of a sensitivity list. This optional list states what signal(s) the process should respond to, or is sensitive to.

Refer to Figure 21 for the schematic locations of the bus and latch ports. As mentioned in the clock model description, signals take on their newly-assigned values after the process suspends. There is another digital assignment statement, the variable, which can be declared in a process. Unlike signals, variables take on their newly-assigned values immediately when they are executed. When the process executes, two variables are declared: v_sum and delta_v. V_sum is used to hold the cumulative voltage value that results from adding up the representative bit voltage values. Delta_v is used to calculate the voltage weight for each bit, by successively dividing the previous value by two.
6

Thorough VHDL-AMS implementations for both D/A and A/D converters are discussed in Chapter 8 of [1]. - 28 -

System Modeling: An Introduction

The calculation of bit values and summing of corresponding voltages all occurs in a for loop. The for loop is entered with the following statement:
for i in high_bit downto low_bit loop

end if; bit_cnt := bit_cnt - 1; when output => eoc <= '1' after delay ; wait on oe until oe = '1' OR oe = 'H' ; bus <= dtmp; wait on oe until oe = '0' OR oe = 'L' ; bus <= (others => 'Z'); bit_cnt := bit_range-1 ; mode := input ; end case ;

High_bit and low_bit are generics the user sets

to establish the number of bits for the D/A. Starting with the MSB (high_bit), the for loop is executed once for each bit, and then stops executing after the LSB (low_bit). Analog-to-Digital Converter (A/D) As with the D/A model, the A/D model is fairly lengthy and complex. For the sake of brevity, only the core functionality of the model will be presented. One popular approach to modeling an A/D converter is to divide the conversion sequence into separate modes: the input mode acknowledges that a new conversion is being requested, and samples the input analog voltage; the convert mode is where the actual analog-todigital conversion is performed, the results of which are stored internally; and the output mode is where the internally stored digital bits are placed on the output ports of the A/D converter. The A/D model fragment listed below illustrates this approach.
case mode is when input => wait on start until start = '1' or start = 'H' ; Vtmp := Vin; thresh := Vmax ; dtmp(Nbits-1) := '0'; eoc <= '0' ; mode := convert ; when convert => thresh := thresh / 2.0 ; wait on clk until clk = '1' OR clk = 'H'; if Vtmp > thresh then dtmp(bit_cnt) := '1' ; Vtmp := Vtmp - thresh ; else dtmp(bit_cnt) := '0' ; end if ; if bit_cnt < 1 then mode := output; System Modeling: An Introduction

Refer to Figure 21 for the schematic locations of the various ports used in this model. This model fragment constitutes the core of the A/D model. The three mode approach is implemented using a case statement. A case statement can be used when model behavior depends on the value of a single expression. The when keyword is used in conjunction with the case statement to select between the possible alternatives. When in the input mode, the model waits for a rising edge on the start pin, then samples the input analog voltage, performs some initialization, then updates to the convert mode. Once in the convert mode, a threshold voltage against which the input voltage is compared is calculated as ½ the reference voltage. The reference voltage specifies the overall input range of the A/D. The model then waits for a rising clock edge to begin the conversion sequence. If the sampled input voltage is larger than the threshold voltage, the MSB is set to ‘1’. If it is smaller, the MSB is set to ‘0’. A counter is decremented to the next bit down from the MSB, and the process is repeated, beginning with reducing the threshold voltage again by ½. This “successive approximation” conversion approach is repeated until all of the digital bits have been updated, at which time the mode is changed to output. Once in the output mode, the end-ofconversion (eoc) pin is set high after an optional delay. When an output enable (oe) rising edge is received, all of the internal data bits are placed on the model’s output pins (bus). When a falling
- 29 -

edge is received on oe, the output pins are updated to a high-impedance state, and the model is placed in the input mode. In order to use the concept of a mode in the model, we define a new VHDL-AMS type called mode. Type mode has three possible enumerated alternatives, input, convert, and output. The mode type is declared as follows:
type mode is (input, convert, output);

Once declared, type mode can be used like any pre-defined type in VHDL-AMS. The ability to extend the language in this manner is one of the features that makes VHDL-AMS such a powerful modeling language.
Simulation and analysis The simulation results for the A/D portion of the Digital Command subsystem are given in Figure 23. These results illustrate the analog input profile expressed as digital bits on the A/D output.

Figure 24 - Digital Command subsystem input/output

Now that the complete Position Controller system model is available, additional testing may be performed. For example, one of the design criteria was that this is a 10-bit system. Is it possible that the performance specifications could be met with a less costly 8-bit system? This can be tested by simply changing the generic parameters in the A/D and D/A models that control the number of bits represented by each converter, and resimulating the system. The responses of both simulations can then be compared. These results are given in Figure 25.

Figure 23 - Digital Command subsystem A/D conversion

The overall results for the Digital Command subsystem are given in Figure 24. These results show the input profile along with the quantized D/A output waveform. It is this D/A output waveform that is useful for system tests.

Figure 25 - Quantization versus A/D conversion time

Although a quantitative analysis will need to be performed, it looks as though there is relatively small steady-state positioning difference between
System Modeling: An Introduction - 30 -

the 10-bit and 8-bit systems for this test case. Depending on the overall system specifications, this may mean that a less costly 8-bit D/A converter can be used in place of a 10-bit converter. Integrate Digital Command and Servo Subsystems Summary All of the Servo subsystem components that were mathematically described in the Develop System Model Analysis Strategy phase have now been modeled in the VHDL-AMS modeling language. The seamless mapping of abstract mathematical descriptions to actual model implementations is one of the benefits of VHDL-AMS. This concludes the final phase of the Position Controller design.
SUMMARY This paper has presented some fundamental ideas for building a simulatable system model for a Position Controller system. The Position Controller system was modeled in four progressive phases. In the Develop System Modeling Analysis Strategy phase, attention was given to systematically progressing through the systems modeling process, as well as mathematically describing the components of the Servo subsystem. In the Develop Conceptual Servo Design phase, component models were developed for each component in the Servo subsystem. A subsystem model was developed, and initial simulations were performed. Possible problems were identified and resolved. In particular, it was determined that tachometer feedback was required to stabilize the position loop. This was dealt with very early in the design phase. In the Develop Detailed Servo Design phase, selected servo component models were further refined to more closely reflect the eventual physical implementation of the design. Simulations were again performed, the results of which were compared to results from the conceptual phase.

In the Integrate Digital Command and Servo Subsystems phase, the mixed-analog/digital Digital Command subsystem model was developed and simulated. Both subsystems were then integrated to form the Position Controller system model. This system model was simulated, and a system trade-off (# bits vs. performance) was considered. All of the development and analysis throughout this design process was performed with the SystemVision System Modeling Solution from Mentor Graphics Corporation. Although a Position Controller system was the focus of our discussions, the techniques presented in this paper are equally applicable to other systems.
FOR MORE INFORMATION Related information/links can be found as follows: • Download SystemVision for hands-on system modeling and analysis www.mentor.com/systemvision/downloads. html • For SystemVision product details, visit www.mentor.com/systemvision REFERENCES

[1] “The System Designer’s Guide to VHDLAMS: Analog, Mixed-Signal, and MixedTechnology Modeling”. Written by Peter Ashenden, University of Adelaide, Gregory Peterson, University of Tennessee, and Darrell Teegarden, Mentor Graphics. http://books.elsevier.com/mk/default.asp?isbn =1558607498

System Modeling: An Introduction

- 31 -