System Modeling: An Introduction

Citation preview

System Modeling White Paper

System Modeling: An Introduction

Scott Cooper Mentor Graphics

REF: MWP2650

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

System Modeling: An Introduction

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 technologies create an environment in which a system can be tuned, optimized, and critical insights can be gained – before any hardware is built. During the verification phase of the design, simulation technologies can again be employed to verify intended system operation. It is a common mistake to completely design a system and then attempt to use simulation to verify whether or not it will work correctly. Simulation should be considered an integral part of the entire design phase, and continue well into the manufacturing phase. SYSTEM OVERVIEW The Position Controller is composed of two sections, as indicated by the dotted line dividing the system shown in Figure 1. These sections 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-toanalog (D/A) converter which produces an analog representation of the digital command. Digital Command Digital Command

Servo

D 2 A

Servo/ Motor/ Load

Figure 1 – Position Controller

1

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. This type of servo positioning system is commonly employed in various applications in 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

2

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 often entails upgrading “high-level” models to be more consistent with the intended physical implementation of the system. SPICE and VHDL-AMS models are combined to achieve this goal for the Position Controller system. The Integrate Digital Command and Servo Subsystems phase discusses how to implement the Digital Command subsystem components using the mixed analog/digital features of the VHDL-AMS modeling language. Once the Digital Command subsystem is implemented, the entire Position Controller system will be simulated. All design development and simulation in this paper is performed with the SystemVision™ System Modeling Solution from Mentor Graphics Corporation. DEVELOP SYSTEM MODELING ANALYSIS STRATEGY This first phase of a system design deals with many of the decisions that need to be made when starting development of a new system. Attention is also given to defining mathematical descriptions for the various analog components in the Servo subsystem, and how to systematically approach the modeling process in general. SERVO SUBSYSTEM Since the majority of the modeling tasks exist in the

System Modeling: An Introduction

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

System Modeling: An Introduction

2. 3. 4. 5.

Load position accuracy Stability margins Noise rejection Robustness to parameter variations

It is important to consider what specific information is desired from a simulation, as it helps to focus the modeling efforts. For this paper, speed and accuracy are of main concern. The primary components that may affect the speed and accuracy of the Servo subsystem are the low-pass filter, the motor, and the load (power considerations will be deferred until the “Develop Detailed Servo Subsystem” phase of the process). By focusing on these critical components, the fidelity requirements on other component models can be relaxed. COMPONENT MODELS In order to create a system model, each component in the real system will need to have a corresponding “component model” (although it is often possible to combine the function of multiple components into a single component model). These component models are then connected together (as would be their physical counterparts), to create the overall system model. What lies at the heart of any computer simulation, therefore, are the component models. The “art” of creating the models themselves, and sometimes more importantly, of knowing exactly what to model and why, are the primary keys to successful simulation. MODELING DECISIONS When setting out to obtain the models necessary for a system design, the following questions should be considered: 1. Which characteristics need to be modeled, and which can be ignored without affecting the results? 2. Does a model already exist? 3. Can an existing model be modified to work in this application?

3

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 development time as well as the time required to run a given simulation session. For example, suppose a design uses a 10 kΩ 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

4

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 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 VHDL-AMS hardware description language, is used in depth in subsequent phases of this design. Can an existing model be modified? If an exact model is not already available, it is also possible that a similar model can be found, and reparameterized or functionally modified in order to serve the design. Before proceeding further, however, a distinction should be made between re-parameterizing a

System Modeling: An Introduction

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. 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 “block-diagram modeling” and is popular with both SPICE-type and control systems simulators. Since one of the purposes of this paper is to instruct the reader in model development, the assumption will be made that all models required for the first phases of

System Modeling: An Introduction

the design will need to be created (although the opposite is actually true – all of the models that comprise the Position Controller system were actually available in a library supplied with SystemVision, and would possibly be available from other VHDL-AMS simulator vendors as well). What component data is available? Consideration must also be given to what component data is available in the first place. The capabilities of a model may need to be restricted based on the amount (and quality) of data the component’s manufacturer provides. SERVO SUBSYSTEM COMPONENT MODEL DEVELOPMENT The behavior for each of the analog components required by the Servo subsystem shown in Figure 2 will be considered next. The D/A converter consists of mixed analog/digital functionality, and will be discussed in the Integrate Digital Command and Servo Subsystems phase of the design process. Very simple models will be developed first, followed by models of moderate sophistication. These behavioral descriptions are actually implemented as component models in the next phase of the design process. Power Amplifier The “big picture” functionality of the system is of primary interest in the initial phase of the design. It has also already been determined that the power amplifier is not a critical component with respect to Servo subsystem speed and accuracy. Therefore, the power amplifier can be initially modeled as a simple gain block with unlimited voltage and current drive capacity. In reality, this system will likely employ a switching amplifier topology to drive the motor. Why then start off with such a simplified model of the power amplifier? Aside from the obvious answer that the time required

5

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.

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 defines the behavior to

6

System Modeling: An Introduction

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

vout = K * vin

(1)

At a high, abstract level, a power amplifier just amplifies an input signal and presents it at the output. Parameter K represents the gain factor. Summing Junction A mathematical description of an ideal summing junction is also fairly intuitive. This behavior can be described as shown in Equation (2).

vout = K1 * 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 user-adjustable gain coefficients at strategic locations in a model, the model becomes useful to a wider audience at negligible cost in terms of model development time. Potentiometer A potentiometer is a device that generates a voltage level in proportion to a rotational angle. (For greater precision, optical encoders are often employed for this purpose). The behavior of a potentiometer can be expressed as shown in Equation (3).

System Modeling: An Introduction

vout = K * anglein

(3)

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 filter behavior using a Laplace transfer function is given in Equation (5).

7

vout = vin *

ωp s +ωp

(5)

Wheredω 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 *

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

τp = Where

τ

p

1 ωp

(7)

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

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

(8)

τ p = RC

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

Figure 4 - RC Low-pass Filter

The filter can be modeled using any of these approaches, all of which can be simulated in either the time or frequency domains. Load (Inertia) The load is a fairly critical system component since it will likely represent one of the largest time constants in the entire system. This will directly influence the speed of the system. For this design, the load will be represented as an inertia, the behavior of which is described in Equation (9).

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 dω ( ). The load torque can also be calculated as a function of (shaft) position ( θ ). System Modeling: An Introduction

This formulation is given in Equation (10).

torq = j *

d 2θ dt 2

(10)

representing it as a resistor in series with an inductor. This includes the electrical dynamics of the winding – i.e. the winding resistance and inductance, as shown in Figure 6.

This second formulation is used in the Servo subsystem illustrated in Figure 2. 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 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 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.

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

System Modeling: An Introduction

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

9

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

di dt

(11)

Equation (11) represents motor winding resistance losses (i*r), inductance losses (l*di/dt), as well as induced back-EMF voltage (KTdω * ). The dynamic behavior on the mechanical side of a DC motor can be described with Equation (12).

torq = − K T * i + d * ω + j *

dω dt

(12)

Equation (12) accounts for motor shaft inertia (j*d * ), as well as dω /dt), viscous damping losses (ddω 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

10

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

System Modeling: An Introduction

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 highlevel system model, all of the component models are fairly simple to develop in VHDL-AMS. Consideration of how the actual components will be implemented in the physical system will be given in the detailed design phase. At that time, it will prove useful to use pre-existing, freely-available SPICE models in addition to VHDL-AMS models. An additional decision needs to be made as well. A “control block” model representation of the motor was previously illustrated. This was referred to as a “non-conserved” model, since motor loading effects needed to be explicitly modeled with feedback loops and summing junctions. VHDL-AMS supports this non-conserved, control block modeling style, as well as a conserved-energy modeling style. Before engaging in model development, the style 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.

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

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

System Modeling: An Introduction

(13)

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.

11

VHDL-AMS keywords are denoted in this paper by the bold style2.

); port ( terminal input : electrical;

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.

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.

Comments are included in a model by pre-pending the comment with “--“. The contents of both the generic and port sections in the previous entity listing are comments, and will not be executed as model statements.

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.

The port names for this model will be called input and output. Any non-VHDL-AMS keywords may be chosen as port names.

As will be shown shortly, there are other predefined terminal natures besides electrical, such as mechanical, fluidic, thermal, and several others.

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:

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

entity gain is generic ( -- generic (parameter) declarations

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

12

terminal in_p, in_m : electrical; -- inputs

System Modeling: An Introduction

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 non-conserved ports are used for digital connections. Signal ports will be discussed in the Integrate Digital Command and Servo Subsystems phase of the design. Now that the 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

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:

); end entity gain;

architecture ideal of gain is -- declarations

Generic K is declared as type real, so it can be assigned any real number. In this case, it is given a default value that will be used by the model if the user does not specify a gain value when the model is instantiated. Models are not required to have default values for generics. Architecture Model functionality is implemented in the architecture section of a VHDL-AMS model. The basic structure

System Modeling: An Introduction

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

13

in the functional equation. In this case vin and vout need to be declared (K was declared in the entity). Declarations for vin and vout are shown below: architecture ideal of gain is quantity vin across input to electrical_ref;

As discussed earlier, the gain model could have been declared with two ports, in which case using electrical_ref within the model would be unnecessary. If this were the case (assuming input port names in_p and in_m), then the branch quantity declaration would appear as follows:

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

quantity vin across in_p to in_m;

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;

Figure 8 - Branch quantities

14

Model Solvability When solving simultaneous equations, the general rule is that there must be an equal number of unknowns and

System Modeling: An Introduction

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 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 conservation-based ports must therefore be constructed such that a through branch quantity is declared for each model equation – even if the through quantity itself is not used in the equation! In the case of the gain model, quantity iout is needed to satisfy this requirement.

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

Libraries and Packages Models often require access to data types and operations not defined in the model itself. VHDL-AMS supports the concept of packages to facilitate this requirement. A package is a mechanism by which related declarations can be assembled together, in order to be re-used by multiple models.

library IEEE; use IEEE.electrical_systems.all;

entity gain is generic ( K

: real := 1.0 ); -- Model gain

port (

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:

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 ;

nature ELECTRICAL is VOLTAGE across CURRENT through

System Modeling: An Introduction

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

15

SUMMING JUNCTION The summing junction functional description is given in Equation (14).

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

(14)

vout = K * anglein

(15)

The complete potentiometer model is shown below: library IEEE; use IEEE.mechanical_systems.all;

A complete summing junction model, summer, is shown below:

use IEEE.electrical_systems.all; entity potentiometer is generic (

library IEEE; use IEEE.electrical_systems.all;

k : real := 1.0); -- optional gain port ( terminal input : rotational; -- input terminal

entity summer is generic (

terminal output : electrical); -- output terminal end entity potentiometer ;

K1 : real := 1.0; -- Input1 gain K2 : real := 1.0 ); -- Input2 gain port ( terminal in1, in2 : electrical; terminal output : electrical ); end entity summer;

architecture ideal of potentiometer is quantity ang_in across input torotational_ref; quantity v_out across i_out through output to electrical_ref; begin v_out == k*ang_in;

architecture ideal of summer is

end architecture ideal;

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

16

The potentiometer model contains a non-electrical input port. Just as mixed-analog/digital models are referred to as “mixed-signal” models, models such as the potentiometer are referred to variously as mixed-technology, multi-technology, multi-domain, and multi-physics models. The potentiometer model represents the first departure from an all-electrical model encountered thus far in the design. The 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,

System Modeling: An Introduction

the IEEE.mechanical_systems package is included in the model. TACHOMETER The tachometer functionality is expressed as shown in Equation (16).

v out = K *

d ( anglein ) dt

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

(16)

vout = vin *

ωp s +ωp

(17)

The tachometer model is listed below: library IEEE; use IEEE.mechanical_systems.all;

This low-pass filter description may be implemented directly using VHDL-AMS. The complete VHDLAMS model for the low-pass filter is listed below:

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

entity tachometer is

use IEEE.math_real.all;

generic ( k : real := 1.0); -- optional gain port ( terminal input : rotational;

-- input terminal

terminal output : electrical); -- output terminal

entity LowPass is generic ( Fp : real := 1.0e6; -- Pole frequency [Hz] K

: real := 1.0);

-- Filter gain

end entity tachometer ; port ( architecture ideal of tachometer is quantity ang_in across input to rotational_ref; quantity v_out across i_out through

terminal input : electrical; terminal output : electrical); end entity LowPass;

output to electrical_ref; begin v_out == K * ang_in'dot; end architecture ideal;

architecture ideal of LowPass is quantity vin across input to electrical_ref; quantity vout across iout through output to electrical_ref;

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 3 See Section 22.1 of [1] for a complete list of predefined attributes.

System Modeling: An Introduction

constant wp : real := math_2_pi*Fp; constant num : real_vector := (wp, 0.0); constant den : real_vector := (wp, 1.0); begin vout == K * vin'ltf(num, den); end architecture ideal ;

This low-pass filter implementation uses the ‘ltf (Laplace transfer function) attribute to implement the transfer function in terms of num (numerator) and den (denominator) expressions. These expressions must be constants of type real_vector. The real vectors are specified in ascending powers of s, where each term is separated by a comma. Since num and den must be of

17

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.

generic (j: moment_inertia); -- Kg*meter**2 port (terminal rot1 : rotational); end entity inertia_r; architecture ideal of inertia_r is

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

torque = J *

d 2 ( anglein ) dt 2

(18)

This behavior can be implemented as a VHDL-AMS model as shown below: library IEEE; use IEEE.mechanical_systems.all;

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

torq = − K T * i + d * ω + j *

(19)

dω dt

(20)

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 languages. All of these motor effects (and more) can be quickly and easily described in a model, using the governing equations themselves. The VHDLAMS version of the DC motor model is listed below.

entity inertia_r is 4 Constant wp can also be assigned to a single element in a real_vector using the following syntax: (0=>wp).

18

library IEEE; use IEEE.mechanical_systems.all;

System Modeling: An Introduction

use IEEE.electrical_systems.all; entity DCMotor_r is

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.

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;

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.

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;

The next step is to parameterize the component models if necessary. The following parameter values are used for this design: low-pass 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.

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 simultaneous equation to be introduced into the model.

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

Note that these simultaneous equations are virtually identical to those given in (19) and (20). This direct “mapping” between physical component descriptions

System Modeling: An Introduction

19

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 9 - Closed-Loop Frequency Response

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.

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.

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.

Figure 10 - Closed-Loop Transient Response

Three waveforms are indicated: the input position profile command, the output of the low-pass filter, and the load position profile. 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. Figure 12 - Motor overshoot versus tachometer gain

20

System Modeling: An Introduction

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. DEVELOP DETAILED SERVO DESIGN Thus far, a 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 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

System Modeling: An Introduction

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 space-related 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 of the system in general. In the case of the Servo subsystem, a fairly high-level subsystem model has been developed, which among other things, does not account for the power delivery system. Such systems are often the trickiest parts of a design, and should be fully explored using simulation technology. For the sake of brevity, only a few component models for the Servo subsystem will be refined in this paper. These are: • • •

Low-pass filter Summing Junction Power Amplifier

LOW-PASS FILTER IMPLEMENTATION Op amps (operational amplifiers) are commonly used to implement analog functions. Both the low-pass filter and summer functions will be implemented using op amps. Since there are no special restrictions on the

21

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.

added to filter out high frequency noise. The SPICEbased LM307 model will also be used for the summing junction implementation.

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

22

The power amplifier will now be re-implemented 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 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

System Modeling: An Introduction

H-bridge with PWM The H-bridge represents the largest design change between the conceptual and detailed Servo subsystem designs. The H-bridge is illustrated in Figure 16. Assume that a motor is connected between the MOT_P and MOT_M terminals of the H-bridge. The basic concept behind the H-bridge topology is as follows: if the upper-left (M1) and lower-right (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. 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

System Modeling: An Introduction

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

23

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.

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

24

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.

System Modeling: An Introduction

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.

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.

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

System Modeling: An Introduction

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

25

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.

entity buf is generic ( delay : time := 0 ns);

-- Delay time

port ( input : in std_logic; output : out std_logic);

The EOC output is fed into an edge-to-pulse generator (Pulse Gen). 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.

end entity buf; architecture ideal of buf is begin output