Denver Pels 20071113 Cooper Vhdl-Ams

8/8/2019 Denver Pels 20071113 Cooper Vhdl-Ams

1/102

Denver Chapter, IEEE Power Electronics

www.denverpels.org

Introduction To The VHDModeling Language

Scott CooperMentor Graphics

Presented 13 November 2007Westminster, Colorado


2/102

Denver Chapter, IEEE PELS

Special Note

This document contains an expanded verspresentation that Scott Cooper presented

Chapter meeting and a paper written by Scan introduction to modeling language

The Chapter thanks Scott Cooper for contributions.


3/102

Introduction to System Modeling Using VH

Introduction to VHDLPresented by Scott Coope


4/102


Presentation Agend

VHDL-AMS Overview

Here we will briefly define what VHDL-AMS is, and somewith it.

Electrical Analog ModelingIn this portion of the presentation, we concentrate on analo

modeling concepts with VHDL-AMS.

Mixed-Signal ModelingIn this section, we discuss mixed-signal modeling techniqu

Power Converter Design ExampleThe last part of the presentation will focus on a power conv

with VHDL-AMS models.


5/102


What is VHDL-AMS

A mixed-signal modeling language base

(IEEE 1076-1993)

A strict superset of VHDL (IEEE 1076.

AMS =>Analog /MixedSignal Extensions

Represents complex models directly

Non-linear Ordinary Differential-Algebraic Eq

Mixed Analog/Digital

Can also model non-electrical physical p


6/102


VHDL-AMS Concep

VHDL-AMS models are organized as en

architectures It has a concept oftime, concurrent pro

It has a well-defined simulation cycle

It can model continuous and discontinu

Equations are solved using conservation(e.g. KCL, Newtons Laws)

It handles initial conditions, piecewise-dbehavior, and so forth


7/102


Electrical Analog Mod


8/102


VHDL-AMS Model Stru

VHDL-AMS models are typically compr

sections: an entity and an architecture.

Entity - Describes the model interface to

world

Architecture - Describes the function orthe model


9/102


Entity - model interfa

Pins p1 and p2 provide the interface

model and the outside world.

The nature of these pins is defined in the

Entity declaration.


10/102


Resistor Model (Entity Dec

entity resistor is

port (

terminal p1, p2 : elect

end entity resistor;

Pin D

p1, p2 -


11/102


Resistor Model (Entity Exp

entity resistor is

port (terminal p1, p2 :


Entity declaration

Device port (pin)

Port type:

Analog?

Digital?

Conserved?

Entity/model name


12/102


Architecture - model be

The architecture describes the behavior

i = v / res

In this case, the model behavior is gover

law, which relates current and voltage as


13/102


Resistor Model (Archite

architecture ideal of resisto

constant res : real := 10.0

quantity v across i through

begin -- architecture ideal

i == v / res;

end architecture ideal;

Characte

i =


14/102


Resistor Model (Architecture

architecture ideal of resistor

constant res : real := 10.0e



i == v / res;


EnArchitecture name

Architect

Model behavior

Internal object

declarations

Now that weve seen the overall structure of

model, lets explore some elements of the mo


15/102


VHDL-AMS Object Ty

There are six classes of objects in VHD

Constants

Terminals

Quantities

Variables

Signals Files

For analog modeling, constants, termin

quantities are routinely used


16/102


Constants

Data storage object for use in a model

constant res : real := 50.0;Declares constant, res, of type real, and initializes

constant is of type real, it must be assigned only re

must include a decimal point.

constant count : integer := 3;Declares constant count, of type integer, and initia

count is of type integer, it must be assigned only w

must not include a decimal point.

constant td : time := 1 ns;Declares constant td, of type time, and initializes i

seconds).

Time is a special kind of constant, described next


17/102


Predefined Physical T

The constant time is apredefined physical type, s

it represents a real world physical property. It caninteger.

As a physical type, time values are specified with

by a multiplier (separated with a space). Predefin

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 v


18/102


Constants (cont.)

Constants make models easier to unders

modify (as opposed to using literal value i == v/50.0; -- Poor modeling style

i == v/res; -- Good modeling style

Constant values cannot be changed duri


19/102


Terminals

Terminals represent continuous, conserv

in VHDL-AMS

Terminals have across (potential) and th

aspects

Terminal types are referred to as nature

Example terminal natures (predefined):

electrical - voltage across, current through

translational position across, force through

thermal temperature across, power (or heat-flow

fluidic pressure across, flow-rate through

Users can define custom terminal nature


20/102


21/102


Free Quantities

Free quantities can be used to represent non-cons

analog values.

They are often used to clarify model descriptions

ability to view internal model waveforms. Free q

used to describe signal-flow (block diagram) typ

quantity internal_variable : real := 5.0;

In this case, the quantity internal_variable is of type

to 5.0.

quantity power : real;

In this case, the quantity power is declared as type r

the default (left-most) value for that type. The defau

guaranteed to be no larger than -1.0e+38. Dependinit is sometimes important to initialize quantities and

values.


22/102


Branch Quantities

Branch quantity

Branch quantities are analog objects used for cosystems. For electrical systems, these quantities

either the voltage or current, or both, of a termin

To illustrate branch quantities, consider the enti

the resistor model discussed previously:

terminal p1, p2 : electrical;

An example of the branch quantity declaration s

terminals is next:


23/102


Branch Quantities

quantity v across i through p1 to

Quantity v refers to

the across aspect of

terminal ports p1 and p2

Quantity i refers to

the through aspect of

terminal ports p1 and p2

v and i are d

to terminal ports

Recall the resistor entity declaration for ports p1 and p

terminal p1, p2 : electrical;

Since p1 and p2 are declared as electrical ports, v will

and i will represent current

Any name can be used for the quantities (not restricted


24/102


Source Quantities

Source quantity

Source quantities are used for frequency and noThese are used only in sources when frequency

to be performed, and other models do not requir

in this domain. A syntax example is given as:

quantity spectral_src real spectrum


25/102


26/102


Resistor Model (Entity with

entity resistor is

generic (

res : real := 10.0e3);

port (terminal p1, p2 : ele


Generic

Generic name

Value of generic can be initialized in

declaration. This value will be over-specified when the component is inst


27/102


architecture ideal of resistor

constant res : real := 10.0e3

quantity v across i through p


i == v / res;


Resistor Model(Architecture with Gen

Constant res no longer defined in arch


28/102


Implicit Quantity Attributes

Useful predefined quantity att

QdotTime derivative of quanti

v == L*idot; -- v = L*di/dt

Qinteg

Time integral of quantityv == (1/C)*iinteg + init; -- v = (1/C)

Qdelayed(T)

Quantity Q delayed by tim

v_out == v_indelayed(td); many more


29/102


Analog Modeling Exam


30/102


Inductor Model (Ent

use ieee.electrical_systems.all

entity inductor is

generic (

ind : real); -- inducta

port (

terminal p1, p2 : electriend entity inductor;

Pin Defini

p1, p2 :ind : user su

i

+ v -p1 p2


31/102


Inductor Model (Archite

architecture ideal of inducto


begin -- ideal architecture

v == ind * idot;end architecture ideal;

Fundamenta

inv =i+ v -

p1 p2


32/102


Diode Model (Entity

entity diode is

generic (

-- saturation current

Isat : current := 1.0e-1

port (

terminal p, n : electricend entity diode;

Pin Defini

p, n : eIsat : user s


33/102


Diode Model (Architec

architecture ideal of diode isconstant TempC : real := 27.0;

constant TempK : real := 273.0 + T

constant vt : real := PHYS_K*TempK

quantity v across i through p to n

begin

i == Isat*(exp(v/vt)-1.0);


Fundamenta

(e*= Isati


34/102


Op Amp Model (Enti

entity opamp_3p is

generic (a_ol: real := 100.0e3;

f_0dB: real := 1.0e6

);

port (

terminal in_pos: electrica

terminal in_neg: electrica

terminal output: electrica

);

end entity opamp_3p;

Pin Defini

in_pos, in_neg, a_ol, f_0dB : us

in_pos

in_neg

output


35/102


Op Amp Model (Archite

architecture default of opamp_3p is

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_3d

quantity v_in across in_pos to in_neg;

quantity v_out across i_out through output

begin

v_out == v_in'ltf(num, den);

end architecture default;

Fundamenta

vinvout =

in_pos

in_neg

outputv_in v_out


36/102


Incandescent LamAn incandescent lamp converts electrical energy into therm

From an electrical standpoint, the lamp filament acts as a te

resistance.

From a thermal standpoint, current flows through this resist

and thermally dissipated as a combination of thermal condu

capacitance, and radiation.

i

Electrical model governing power

v

R v*i = power => heat flow

(Powerelectrical = Powerthermal)

Thermal mode

hflow


37/102


Lamp Equations

We begin with the electrical model of the preceding figur

temperature-dependent electrical resistance. The power diresistance is determined as follows:

power = v*i

where the power is simply the product of the voltage (v) a

resistance and the current (i) through it. The voltage acros

resistance can be determined using Ohms law as follows

v = i*R

where R represents the electrical resistance at the given te

resistance, in turn, can be calculated with the following fo

R = RC*(1.0 + alpha*(T - TC))

where RC is the electrical resistance when the lamp is co

unheated cold temperature of the filament, T is the actu

temperature, and alpha is the resistive temperature coeffic


38/102


Lamp Equations

We now have the necessary information to calculate the te

dependent electrical power as a function of filament temptask is to develop equations which describe how this pow

dissipated.

For the thermal capacitance component (cth), the governin

hflowcap

= cth

*dT/dt

where the heat flow is the product of the time derivative o

temperature (T) and the thermal capacitance (cth). The the

(rth) component is formulated as follows:

hflowres= (T - TA)/rthwhere the heat flow is the ratio of the delta temperature (a

(T) minus ambient temperature (TA)), and the thermal resiwill also dissipate heat in the form of electromagnetic rad


39/102


Lamp Equations

The radiated heat flow increases as the fourth power of th

temperature, and may be described as follows:hflowradiated = Ke*(T

4- TA4)

where Ke is the radiated energy coefficient. We now have

necessary to implement the incandescent lamp model.

To summarize our approach, we are attempting to equate

thermal power (heat flow), as follows:Electrical: power = v*i

and

Thermal: hflow = hflowcap+ hflowres+ hflowrthese two equations may be equated by the following rela

Electrical/thermal: power = hflow


40/102


Developing the Lamp M

Although it is quite easy to develop simple mod

unstructured manner, more complex models benstructured modeling approach. A recommended

analog modeling is:

1. Determine the models characteristic relatio

and external variables

2. Implement these relationships as simultaneo

VHDL-AMS

3. Declare appropriate objects to support the si

statements


41/102


Incandescent Lamp (Arch

begin

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

v == i*r_temp;

hflow == v*i; -- Electrical power = heat flow

hflow == cth*temp_fil'dot + ke*SIGN(temp_fil - temp_amb_K)*(temp_fil*

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

-- Note: For alpha, cth and rth, temperatures specified in C or K will work si-- for which only the change in temperature is significant, not its absolute of

end architecture dyn_therm;

Firstrelati

simu

architecture dyn_therm ofLamp is

constant temp_amb_K : real := temp_amb + 273.18;

constant temp_cold_K : real := temp_cold + 273.18;

quantity v across i through p1 to p2;

quantity r_temp : resistance; -- Resistance at temp_fil [ohms]

quantity temp_fil : temperature; -- Filament temperature [K]

quantity hflow : heat_flow; -- Heat flow from filament [watt

th

objec

simu


42/102


Incandescent Lamp (E

entity Lamp is

generic (

r_cold : resistance := 0.2; -- Filament resista

temp_cold : temperature := 27.0; -- Calibration tem

alpha : real := 0.0045; -- Resistive temp ke : real := 0.85e-12; -- Radiation coeff

rth : real := 400.0; -- Thermal conduc

cth : real := 0.25e-3; -- Thermal heat ca

temp_amb : temperature := 27.0); -- Ambient tempe

port (terminal p1, p2 : electrical);

end entity Lamp;

Finally, define the models interface to the outsi


43/102


Model Solvability

Analog models are solved by the simulat

simultaneous equations. When solving siequations, the number of equations munumber of unknowns to be solved.

To ensure the same number of equationsin a behavioral model, the following formapplied:

# equations = # free quantities+ # through quantities+ # quantity ports of mod


44/102


Mixed-Signal Mode


45/102


Mixed-Signal Introduc

In this section, we combine the analog an

modeling capabilities of VHDL-AMS.

An overview of A/D and D/A conversion

will be given next, followed by specific m

examples.


46/102


Analog to Digital

The above attribute is used to convert an analog (co

into a digital (discontinuous) signal, by detecting ancrossing. The syntax is as follows:

Qabove(threshold);

Where Q is the analog quantity to be converted, and

analog threshold level.

This statement returns a boolean true if quantity Q

below to above the threshold level; it returns a boolequantity Q passes from above to below the threshold


47/102


Digital to Analog

There are two primary methods for converting from digita

quantities. The first method involves using the ramp attribQ == Sramp(tr,tf);

Where Q is an analog quantity, S is a digital signal, and tr

and fall-times ofQ at transition points.

When signal S changes value, quantity Q tracks this changit over a linear interval oftr or tf, depending on the directi

The ramp attribute also performs the function of restartin

the discontinuous points when signal S is updated. This is

consideration for analog simulation so that the simulator d

when encountering a discontinuity.


48/102


Digital to Analog

The second method for D/A conversion can be used

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 func

a digital signal.

In this case, if the ramp attribute is not included in t

break statementshould be included to synchronize t

to the digital signal during state transitions. The brea

used explicitly to accomplish what the ramp attribut

which is to guide a simulator through discontinuities


49/102


Mixed Signal Model Ex


50/102


Analog to Digital Interface

entity a2d is

generic (vthreshold : real

port (d_output : out std_lo

terminal a_input : el

end entity a2d;

Entity declaration can include both analog and


51/102


Analog to Digital Interface (A

architecture behavioral of a2d is

quantity vin across a_input to electri

begin

process (vinabove(vthreshold)) is

begin

if vinabove(vthreshold) then

d_output


52/102


The above Attribut

Why use above instead of> or < ?

above() generates an event exactly when the

It is the only way to generate a signal to use in a

< or > do a comparison at each time-step, wh

the exact crossing.

Must use not above() to represent bbelow() is not part of the VHDL-AMS la


53/102


Simple Switch and En

The purpose of this switch is to allow or prevent current fl

and p2, depending on the value ofsw_state. Ports p1 and panalog, and port sw_state is std_logic digital.

entity switch_dig_nogen is

port ( sw_state : in std_lo

terminal p1, p2 : electri

end entity switch_dig_nogen;


54/102


Simple Switch Architearchitecture 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)

beginif (sw_state = 0) then

r_sig


55/102


Key Switch Attribut

event

The mechanism by which digital events aVHDL-AMS. The switch uses this to det

digital control signal is given.

ramp

Ensures that when switching from one vaanother, a reasonable amount of switchi

used.

The syntax used in the switch example is:

q == Sramp(tr, tf);

where q is a quantity (r), S is a signal (r_sig), and tr and tf arerepresenting the rise time and fall time respectively.


56/102


Ideal Limiter Model (E

A limiter model entity is shown below. Its function is to r

voltage levels which pass from input to output. In order tobehavior, the model selects between one of three simultan

depending on the level of the input voltage.

entity limiter_ideal is

generic (

limit_high : real := 10.0; -- u

limit_low : real := -10.0); -- l

port (

terminal input: electrical;

terminal output: electrical);end entity limiter_ideal ;


57/102


Ideal Limiter Model (Arch

architecture simple oflimiter_ideal is

quantity vin across input to electrical_ref;quantity vout across iout through output to electrica

begin

ifvinabove(limit_high) use -- above upper limi

vout == limit_high;

elsif not vinabove(limit_low) use -- below lower lim

vout == limit_low;

else -- no limit exceeded, so pass input sign

vout == vin;

end use;

break on vin'above(limit_high), vin'above(limit_low)

end architecture simple;


58/102


Power Converter Exa


59/102


Phase 1 Averaged M

Phase 1 allows both frequency and time dom

of the design. It simulates very quickly, and overall control loop to be stabilized.


60/102


Averaged Model Stimulus a

Dynamic lo

Output voltage


61/102


Phase 2 Ideal Switch/DiodPhase 2 allows switching effects to be analy

relatively ideal switch and diode models. Drand currents can now be evaluated.


62/102


Averaged and Switched

Superimposed output voltages

averaged and switched designs


63/102


Phase 3 MOSFET, IRR Diode Checks

Phase 3 includes a MOSFET switch, a diode

includes IRR effects, as well as stress monitMOSFET and diode.


64/102


Averaged, Ideal Switch, MOS

Superimposed output voltages fo

averaged, ideal switched and MOswitch-based designs


65/102


Stress Indicators in Wavefo

Boolean indicators in the Waveform Viewer

any stress measures have been violated.


66/102


Analyzing Causes of Stress (I

If MOSFET

fast (RGATE

specificatio


67/102


Analyzing Causes of Stress (MO

If MOSFE

slow (RGArating is v


68/102


Test IRR Diode

Test circuit for t

reverse-recoverymodeled.


69/102


IRR Diode Test Resu

Test results

with revers

effects mod


70/102


VHDL-AMS Reference M How to Model Mechatronic Systems Using VHDL-AMS i

SystemVision Technology Series. This booklet serves as the

modeling course. It is available from the SystemVision WelMentor Graphics at the SystemVision website.

The System Designer's Guide to VHDL-AMS (P. J. AshenA. Teegarden - ISBN 1-55860-749-8, published by Morgan2002) is a comprehensive textbook for the VHDL-AMS mod

The Designers Guide to Analog & Mixed-Signal Modelin

0-9705953-0-1, published by Avant!, 2001) includes numerboth the VHDL-AMS and MAST modeling languages.

The VHDL-AMS Quick Reference Guide offers a summarlanguage features and syntax. It is accessed from within Sy

Manuals > VHDL-AMS Quick Reference.


71/102


Thank You!


72/102

System Modeling White Paper

www.mentor.com/systemvision

System Modeling: An Introduction

Scott CooperMentor Graphics


73/102

System Modeling: An Introduction - 2 -

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 PositionController) 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 usingspecialized 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 time-

consuming, 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 bedifficult 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

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 arereferred 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 digitalcommand.

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.

Figure 1 Position Controller

This type of servo positioning system is

commonly employed in various applications in

DigitalCommand

Servo/Motor/

Load

D

2A

ServoDigital

Command


74/102


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 beimplemented by another designer

The specification for the Digital Commandsubsystem 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 Servosubsystem is this designers 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 ServoSubsystems

The focus of the Develop System Modeling

Analysis Strategyphase will be to mathematically

describe the various analog components in the

Servo subsystem, and to consider the modelingprocess 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

often entails upgrading high-level models to be

more consistent with the intended physical

implementation of the system. SPICE and VHDL-

AMS models are combined to achieve this goal

for the Position Controller system.

The Integrate Digital Command and ServoSubsystemsphase discusses how to implement the

Digital Command subsystem components using

the mixed analog/digital features of the VHDL-

AMS 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 SubsystemSince 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


75/102


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.

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 speed2. Load position accuracy3. Stability margins4. Noise rejection5. 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

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 newmodel?

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 designers first inclination is typically towish 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


76/102


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 resistora 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 exactly10 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 isimportant, 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 allof

the required models may not be available, a good

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 theirsimulation tools. One such format, the VHDL-

AMS 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 changingthe 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 dont 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 doesnt 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 hardwaredescription 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.


77/102


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 oftenreferred to as macro-modeling or block-

diagram 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

components manufacturer provides.

Servo SubsystemComponent 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 actuallyimplemented 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 aswitching 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 thechanges. 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.


78/102


Figure 3 - Example switching waveform

As shown in the figure, it takes quite a fewtime 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 isacceptable given the following two assumptions:

The frequency of the switching amplifier ismuch greater than the bandwidth of the

control loop (true in the vast majority of

designs)

Power consumption is not of greatconcern 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

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 fairlyintuitive, as shown in Equation (1).

inout vKv *= (1)

At a high, abstract level, a power amplifier just

amplifies an input signal and presents it at the

output. ParameterK 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).

2211 ** ininout vKvKv += (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 andK2).

The addition of optional gain coefficients is a

recurring theme in many of the models presented

in this paper. This is not by accident. Generallyspeaking, models should be developed so that

they are re-usable. By simply adding user-

adjustable 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 oftenemployed for this purpose). The behavior of a

potentiometer can be expressed as shown in

Equation (3).

inout angleKv *= (3)

The potentiometer behavior is very similar to that

of the amplifier behavior shown in Equation (1).


79/102


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 feedbackpolarity 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 motors shaft. As the main motor spins, the

smaller motor generates a back-EMF voltage thatis proportional to the shaft speed.

Since the tachometer is not a critical

component in this phase of the design, only the

behaviorof 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).

dt

angledKv inout

)(*= (4)

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 transferfunction, differential equation, and discrete RC

(resistor/capacitor) components.

Low-pass filter as transfer function

Filter behavior is often described using Laplace

transfer functions. The description of the low-pass

filter behavior using a Laplace transfer function is

given in Equation (5).

p

p

inouts

vv

+

= * (5)

Where p is the cutoff frequency in radiansper 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 operators 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).

dt

dvvv outpoutin *+= (6)

To implement a model in this manner, the

frequency must be converted into a time constant.This conversion is shown in Equation (7).

p

p

1

= (7)

Where p is the time constant in seconds.

Low-pass filter as RC components

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 behaviorcan 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].


80/102


RCp = (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 frequency-

dependent voltage divider due to changingcapacitor impedance. As frequency goes up,

capacitor impedance goes down, and the output

voltage amplitude drops.

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.

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).

dt

djtorq

*= (9)

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 inEquation (10).

2

2

*dt

djtorq

= (10)

This second formulation is used in the Servo

subsystem illustrated in Figure 2.

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 theextent 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

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.

Figure 5 - Motor as resistive load

The drawback to this model, of course, is thatit doesnt take any motor dynamics into account.

In addition, this simplistic approach doesnt 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 andinductance, as shown in Figure 6.


81/102


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

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).

dt

dilriKv T *** ++= (11)

Equation (11) represents motor winding resistance

losses (i*r), inductance losses (l*di/dt), as well as

induced back-EMF voltage (KT*).

The dynamic behavior on the mechanical side

of a DC motor can be described with Equation

(12).

dt

djdiKtorq T

*** ++= (12)

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

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


82/102


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 conservedenergy 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, andwill 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 SystemModeling 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 VHDL-

AMS. 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 pre-

existing, 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 non

conserved, control block modeling style, as well

as a conserved-energy modeling style. Before

engaging in model development, the style orcombination 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 ModelingAnalysis 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.

inout vKv *= (13)

This functionality can be easily and directlydescribed 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 themodels 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 behaviorof the model is defined within an

architecture. This is where the actual functionality

of the model is described. A single model may


83/102


only have one entity, but may contain multiple

architectures. The power amplifier will be

developed by first describing its entity, and then

its architecture.

EntityThe 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 isgeneric (

-- generic (parameter) declarations);

port (-- port (pin) declarations);

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 pre-

pending 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.

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 aredeclared 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:


-- generic (parameter) declarations

);port (

terminal input : electrical;terminal output : electrical);

end entity gain;

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


84/102


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. Anexample of how this might appear in the model

would be:

port (terminal in_p, in_m : electrical; --

inputsterminal output : electrical -- output);

Note how like-natured ports are optionally

declared on the same line. If this component was

modeled with a non-conserved modeling style, theports would be declared asport quantities, rather

than terminals. In that case, the ports would not

have across and through aspects.

Ports can also be of type signal. These non-

conserved 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 models ports are defined, the

model must declare any parameters that will be

passed in externally. For the gain model, there isonly the gain parameter, K (referred to as a

generic in VHDL-AMS). This generic is

accounted for as follows:


K : real := 1.0 -- Model gain);

port (terminal input : electrical;terminal output : electrical

);end entity gain;

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

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. Thebasic structure of an architecture definition for the

gain model is shown below:

architecture ideal ofgain is-- declarations

begin-- simultaneous statements

end architectureideal ;

The first line of this model architecture

declares an architecture called ideal. This

architecture is declared for the entity calledgain.

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 concurrentstatements are located in the model (concurrent

statements will be discussed in the Integrate

Digital Command and Servo Subsystemsphase).

The basic equation for the gain component given

in Equation (13) can be implemented as follows:

architecture ideal ofgain is-- declarations

beginvout == K * vin;

end architecture ideal ;

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


85/102


case vin and vout need to be declared (K was

declared in the entity). Declarations for vin and

vout are shown below:

architecture ideal ofgain isquantity vin across input to electrical_ref;quantity vout across iout through

output to electrical_ref;begin

vout == K * vin;end architecture ideal ;

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 arethen 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

Branch quantity vin is declared as the voltage

across port input relative to ground

(electrical_ref). Electrical_refcan 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

port names in_p and in_m), then the branch

quantity declaration would appear as follows:

quantity vin across in_p to in_m;

The single input port approach was chosen forthe 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 thiscurrent. 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 models 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 ofiout that

is required to ensure vout is the correct value to

maintain equality for the expressions in the

equation:

vout == K * vin;

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


86/102


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 Kirchoffs Current Law (KCL) isenforced at each system node. For mechanical

systems, Newtons laws are enforced.

A VHDL-AMS model with conservation-

based 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 PackagesModels often require access to data types and

operations not defined in the model itself. VHDL-

AMS 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, andfluidic_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 isVOLTAGE acrossCURRENT throughELECTRICAL_REF reference;

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:

library IEEE;use IEEE.electrical_systems.all;

These statements allow the model to use allitems

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;


K : real := 1.0 ); -- Model gainport (

terminal input : electrical;terminal output : electrical );

end entity gain;

architecture ideal ofgain isquantity vin across input to electrical_ref;quantity vout across iout through


vout == K * vin;end architecture ideal ;

This gain model is also used for the Ktach andKpot blocks shown in Figure 2.

Summing Junction

The summing junction functional description is

given in Equation (14).

2211 ** ininout vKvKv += (14)

A complete summing junction model, summer, is

shown below:

library IEEE;

use IEEE.electrical_systems.all;

entity summerisgeneric (

K1 : real := 1.0; -- Input1 gainK2 : real := 1.0 ); -- Input2 gain

port (terminal in1, in2 : electrical;terminal output : electrical );


87/102


end entity summer;

architecture ideal ofsummerisquantity vin1 across in1 to electrical_ref;quantity vin2 across in2 to electrical_ref;quantity vout across iout through

output to electrical_ref;beginvout == K1 * vin1 + K2 * vin2;

end architecture ideal ;

The summers 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 Summers 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 andvin2.

Potentiometer

The potentiometer behavior can be expressed as

shown in Equation (15).

inout angleKv *= (15)

The complete potentiometer model is shown

below:

library IEEE;use IEEE.mechanical_systems.all;use IEEE.electrical_systems.all;

entity potentiometerisgeneric (k : real := 1.0); -- optional gain

port (terminal input : rotational; -- input terminalterminal output : electrical); -- output terminal

end entity potentiometer ;

architecture ideal ofpotentiometerisquantity ang_in across input to rotational_ref;quantity v_out across i_out through


v_out == k*ang_in;endarchitecture ideal;

The potentiometer model contains a non-

electrical 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 models

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).

dt

angledKv inout

)(*= (16)

The tachometermodel is listed below:

library IEEE;use IEEE.mechanical_systems.all;use IEEE.electrical_systems.all;

entity tachometerisgeneric (k : real := 1.0); -- optional gain

port (terminal input : rotational; -- input terminalterminal output : electrical); -- output terminal

end entity tachometer ;

architecture ideal oftachometerisquantity ang_in across input to rotational_ref;quantity v_out across out_i through

output to electrical_ref;beginv_out == K * ang_in'dot;



88/102


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 ofquantity ang_in. Thus v_out will continuously

evaluate to the derivative ofang_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 isquite convenient. This description is given in

Equation (17).

p

p

inouts

vv

+

= * (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 isgeneric (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 ofLowPass is

quantity vin across input to electrical_ref;quantity vout across iout throughoutput 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 See Section 22.1 of [1] for a complete list of predefined

attributes.

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

This low-pass filter implementation uses the

ltf (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 t

Documents

Denver Pels 20071113 Cooper Vhdl-Ams