Download An Introduction To The VHDL

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
Mixed-Signal Modeling
In this section, we discuss mixed-signal modeling techniques.
D
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
A mixed-signal modeling language based on VHDL
(IEEE 1076-1993)
A strict superset of VHDL (IEEE 1076.1-1999)

D
Represents complex models directly


D
AMS => Analog / Mixed Signal Extensions
Non-linear Ordinary Differential-Algebraic Equations (DAEs)
Mixed Analog/Digital
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.
D
The nature of these pins is defined in the model’s
“Entity declaration.”
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
D
The architecture describes the behavior of the model.
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:






D
Constants
Terminals
Quantities
Variables
Signals
Files
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
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
15
Constants (cont.)
D
Constants make models easier to understand and
modify (as opposed to using literal values)


D
i == v/50.0;
i == v/res;
-- Poor modeling style
-- Good modeling style
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):




D
electrical - voltage across, current through
translational – position across, force through
thermal – temperature across, power (or heat-flow) through
fluidic – pressure across, flow-rate through
Users can define custom terminal natures
Introduction to System Modeling Using VHDL-AMS
17
Quantities: 3 Types
D
Free quantity - non-conservative analog object:

D
Branch quantity - analog object used for conservative
energy systems:

D
quantity pwr : real;
quantity v across i through p1 to p2;
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.
quantity power : real;
–
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.
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
Generic name
entity resistor is
generic (
res : real := 10.0e3);
port (
terminal p1, p2 : electrical);
end entity resistor;
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)
Pin Definitions/Argument:
+ vp1
p2
i
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)
Fundamental Equation:
+ vp1
p2
i
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
Pin Definitions/Argument:
output
in_neg
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
a ol
vout = vin
1+
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.
T
v
i
hflow
R
v*i = power => heat flow
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.
–

D
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.
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.
D
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.
D
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.
D
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.
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
Servo
D
2
A
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.
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
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
-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
System Modeling: An Introduction
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-
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.
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
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).
-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
(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 transfer
function, 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
System Modeling: An Introduction
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)
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
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 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-
τ 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.
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)
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
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 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.
(10)
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 *
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).
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 *
System Modeling: An Introduction
dω
dt
(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
- 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
System Modeling: An Introduction
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
- 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 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.
System Modeling: An Introduction
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;
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
- 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
);
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;
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
System Modeling: An Introduction
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 ;
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 ;
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 -
case vin and vout need to be declared (K was
declared in the entity). Declarations for vin and
vout are shown below:
port names in_p and in_m), then the branch
quantity declaration would appear as follows:
quantity vin across in_p to in_m;
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 ;
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
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
System Modeling: An Introduction
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;
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
- 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;
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
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 );
- 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).
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;
System Modeling: An Introduction
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
(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;
- 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 = 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
See Section 22.1 of [1] for a complete list of predefined
attributes.
System Modeling: An Introduction
vout == K * vin'ltf(num, den);
end architecture ideal ;
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
Constant wp can also be assigned to a single element in a
real_vector using the following syntax: (0=>wp).
- 17 -
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;
use IEEE.electrical_systems.all;
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;
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
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.
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 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.
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
System Modeling: An Introduction
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.
Figure 10 - Closed-Loop Transient Response
- 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.
System Modeling: An Introduction
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
- 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.
System Modeling: An Introduction
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 -
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.
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
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
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).
System Modeling: An Introduction
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.
- 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.
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
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
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.
A2D
D2A
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
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
LATCH
EOC
OE
A/D
Clk
BUS
D/A
Load
Delay
Start
Figure 21 - Digital Command Subsystem Test bench
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 -
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;
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)
System Modeling: An Introduction
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
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 -
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)
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.
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;
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
OR gate (pulse generator)
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 OR gate model listing is again quite
similar to the buffer and inverter models. In this
System Modeling: An Introduction
wait until – wait until boolean true condition
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
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;
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.
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);
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
System Modeling: An Introduction
Thorough VHDL-AMS implementations for both D/A and
A/D converters are discussed in Chapter 8 of [1].
- 28 -
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
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
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 ;
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.
System Modeling: An Introduction
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
- 31 -