DesignCon 2012

An Improved Co-Simulation Approach

to Rapidly Prototype, Verify, and
Implement Dynamic FPGA-based
Embedded Control Systems

Muris Mujagic, National Instruments

[email protected]

Oleg Stepanov, National Instruments

[email protected]

Brian MacCleery, National Instruments

[email protected]
Abstract
This paper presents a new co-simulation methodology for the rapid prototyping, design,
and verification of digital controllers for switching power electronics circuits based on field
programmable gate array (FPGA) logic devices. A case study of a closed-loop DC motor drive
design, comprising of a digital controller and analog power drive circuitry, is used to illustrate
the new co-simulation methodology. Using an NI Multisim SPICE simulation plug-in for the
LabVIEW graphical programming environment, the complete system was verified and optimized
using transient simulation prior to being implemented in hardware. All FPGA processing
elements were designed and simulated in the co-simulation environment before synthesis to
digital hardware, including the analog power stage modeled with SPICE.

The system simulation results were compared to the experimental measurements. It was
found that the measured motor speed and the DC motor armature current closely matched the
simulated results, supporting the method of co-simulation as a valuable, insightful and
productivity enhancing initial step prior to system implementation using physical hardware.

Author(s) Biographies
Muris Mujagic received his B.A.Sc. degree in computer engineering from the University of
Waterloo, Waterloo, ON, Canada, in 2005. He then completed his M.A.Sc. degree in electrical
(biomedical) engineering at the University of Toronto, Toronto, ON, Canada, in 2007. At
present, he works at National Instruments Toronto, as a member of the Simulation and Modeling
group. His primary responsibilities include enhancing and maintaining the Multisim SPICE
simulation engine.

Oleg Stepanov received his B.A.Sc. degree in Electrical Engineering from the University of
Toronto. In 2006, he joined National Instruments Toronto as a member of the Simulation and
Modeling group. His research interests are in the areas of analog circuit and electromechanical
system simulation.

Brian MacCleery received his bachelors and masters degrees in electrical engineering from
Virginia Tech where he completed his graduate research in electromechanical modeling and
simulation and led multidisciplinary student teams in the development of novel magnetic
levitation and propulsion designs for energy efficient rapid transit. Brian is the Principal Product
Manager for clean energy technology at National Instruments. His mission is to facilitate the
design, prototyping and deployment of advanced embedded systems technologies to make clean
energy less expensive and more abundant than fossil fuels.
1. Introduction
Dynamic systems are often represented by linear, time-invariant state-space or transfer
function models in the Laplace domain. But in practice dynamic system are much more
complex; the physical process that is being controlled is often non-linear and exhibits vastly
different behavior among various regions of operation. A particularly relevant example is a
switched-mode power conversion system. Such a system does not operate close to a single bias
point around which a linear model may easily be built. Furthermore, it contains a number of
elements that exhibit complex non-linear behavior including the power transistors and magnetic
components such as the transformer. Therefore, a non-linear multi-domain simulation helps to
more accurately analyze the behavior of such a complex system.

What’s more, as designs grow in complexity and engineering capital requirements, a deep
analysis and full scale simulation of the design prior to building the first prototype is changing
from a prudent practice to a necessity. New design tools are needed that enable all of the
software development, testing and validation effort made during the simulation stage to be
moved seamlessly into the physical prototype and through to commercial deployment. Thereby,
a single code-base can be designed, simulated, optimized and validated in a seamless iterative
development process [1]. This is in contrast to a process in which the code developed for
simulation purposes is different from that used for embedded system deployment; resulting in a
problematic disconnect in the design validation process that often leads to development
inefficiencies and costly or dangerous mistakes. If the embedded system code does not match the
code used during the simulation stage, design validation efforts based on simulation have
significantly reduced value.

In this paper, a case study of the design of a brushed DC Motor drive is used to illustrate
a novel multi-domain co-simulation method. NI Multisim, a SPICE-based circuit design and
simulation tool, was used to model and analyze the power stage. NI LabVIEW FPGA and the
LabVIEW Control Design and Simulation Module were used to design a digital controller.
Then, the entire system was simulated and optimized using the multi-domain co-simulation. In
co-simulation, the two respective simulators perform non-linear time-domain analysis
concurrently, exchanging data at the end of each time-step and negotiating future time-steps,
resulting in a tightly integrated and accurate simulation. This enables both solvers to execute in
a continuous-time fashion and enforce accuracy requirements that ensure valid simulation
results, even in the case of coupled differential equation relationships that span between both
solvers. Although it is possible to include both independent and coupled plant dynamics on both
sides, the simpler and more common use case is shown in Figure 1. In this case, Multisim
simulates the power stage circuitry and LabVIEW executes the FPGA-based control system
algorithms. In this configuration, the native strengths of each respective environment are
leveraged.
 Figure 1: Typical LabVIEW-Multisim co-simulation use case. In the illustrated scenario the control
code resides in LabVIEW, while the plant and sensor are modeled by Multisim.

With this new methodology a complete system, comprising of an analog stage and an
embedded FPGA controller, can be co-simulated in order to validate system connectivity, gain
insights into its operation, perform system optimization, and efficiently bridge the gap between
system design and the first physical prototype.

The paper is organized as follows. In Section 2 the high level requirements of the
brushless DC motor drive system are outlined. Prior to performing a full system co-simulation,
the individual parts of the system were designed and analyzed in isolation. The design and
validation of the analog power stage is presented in Section 3, and the digital controller design is
presented in Section 4. Once the constituent parts were designed, the complete system was
analyzed and optimized using co-simulation, as described in Section 5. After completing the
system optimization and validation, the control code was efficiently implemented on a physical
prototype as presented in Section 6. To demonstrate the value of system co-simulation, the
simulation and experimental results are compared in Section 7. Concluding remarks are
discussed in Section 8.

2. Brushed DC Motor Drive Requirements

The case study that is presented in this paper is the design and prototype of a digital
speed controller for a brushed DC motor. The application requirements for the design were:

• Spin an inertial load (0.001  ∙  ) periodically at 1200 RPM for 3 seconds and at
-1200 RPM for 3 seconds. The required speed profile is illustrated in Figure 2.
• Speed overshoot must not exceed 1400RPM.
• Motor must reach the final speed in under a second.
• Use 20 kHz for the PWM switching frequency.
• Reuse available brushed DC motor with quadrature encoder (see Appendix A)
• Run the motor using a 12 V supply.
 Figure 2: Speed profile requirements for the brushed DC motor controller.

3. Analog Power Stage Design and Analysis

Having established the system requirements, the analog power stage for the brushed DC
motor system was designed. In order to satisfy the bi-directional current flow requirement
(motor must spin in both directions) the power stage was designed around the common H-bridge
topology. A feasibility analysis was conducted in Multisim to determine whether the available
power supply is capable of accelerating the loaded DC motor to the required speed within the
required amount of time. This analysis also revealed worst case current conditions that would be
experienced by the switching elements, allowing for the preliminary selection of power
switching parts. The selected parts were subjected to a thermal stress analysis to validate their
suitability. Following these tests, a plant model of the power stage was designed for system co-
simulation.

3.1. Feasibility Analysis and Switch Selection

Simulation was used to determine whether the available power supply was capable of
accelerating the loaded DC motor to the required speed within the required amount of time. By
applying the maximum DC supply voltage (12 V) directly across the terminals of the DC motor,
the theoretical minimum time that it would take the motor to reverse directions from -1200RPM
to 1200RPM was measured. The circuit of Figure 3 was used to perform this test. The
description of the brushed DC motor model and its parameters can be found in Appendix A. The
resulting speed and current profiles are shown in Figure 4.
 Figure 3:: Circuit used to measure the theoretical speed and current response of the brushed DC motor.

Figure 4:: Theoretical speed and current response observed when driving the brushed DC motor from
an initial speed of -1200
1200 RPM to 1200 RPM. Due to the back
back-emf
emf generated by the motor at the initial
speed of -1200,
1200, the motor experiences a large inrush current of approximately 18 A when driven hard
in the opposite direction.

According to simulations, the motor is capable of reversing from -1200

1200 RPM to
+1200 RPM in 0.51 s. However, applying 12 V across an armature with an approximate
resistance of 1 Ω and a back-emfemf of approximately -6 V (resulting from the initial speed of -
1200 RPM) causes an in-rush rush current of over 18 A, which is above that available from the power
supply. To reduce the peak current demanded from the power supply the voltage to the armature
could be applied more gradually. Using simu simulation
lation it was determined that by applying the 12 V
supply with a slew rate limit of 34 V/s, the peak in in-rush
rush current can reduced to 13.5 A. With
slew rate limiting it takes 0.7 s instead of 0.51 s to reach the desired speed of 1200 RPM, which
still satisfies
ies the 1 second design requirement.
 Based on the operating voltage and the maximum expected armature currents, the
Infineon IPP126N10N3 100V, 58A, N-channel MOSFET part was selected as the low-side
MOSFET. For the high side switch, the Infineon SPP80P06P 60V, 80A P-channel MOSFET was
selected. P-channel transistors were selected for the high-side because of the simplicity of
controlling them. The International Rectifier IR2101PBF was selected as the gate driver for all
switches.

3.2. Power Transistor Thermal Stress Analysis

Using high-fidelity SPICE models of the driver and MOSFETs, worst case switching
losses were extracted. Using a combination of piece-wise-linear and behavioral modeling
sources, these switching losses, along with expected worst case conduction losses, were fed into
a thermal network representing the MOSFET package and heat sink. The junction temperature
was monitored to ensure that it did not exceed 125 °C, which was deemed the safe operating
limit of the device. See Appendix B for more details.

3.3. Plant Model for Controller Design

In order to design and test the controller using co-simulation, a plant model needed to be
designed. Figure 10 shows the plant model used for co-simulation. In the interest of simulation
performance, focus was placed on elements that would significantly affect the dynamic behavior
of the entire system. The gate drivers were not considered because their effect on the system
dynamics is minimal. Furthermore, their ability to drive the switches as well as their impact on
switching losses had already been investigated.

Figure 5: Plant model in Multisim for co-simulation

 The switches S1-S4 were represented using simplified resistive models because the time-
constants associated with the actual switches are much smaller than those associated with the
dynamic system at hand. These simplified models function as follows: if the control voltage is
5V or higher, then the drain-source path is a fixed resistance with a value equal to _
(12.3 mΩ for N-channel and 23 mΩ for P-channel MOSFET), and if the control voltage is 0V or
lower, then the drain-source path is a fixed resistance with a value equal to _ (1 MΩ for
the N-channel and P-channel MOSFET). The resistance varies exponentially for control values
in between 0V and 5V. The gate control signals U1, U2, L1, and L2 are driven by the controller.

M1 is the DC motor represented by the same linear model used in the feasibility test. J1
represents the moment of inertia of the load. U1 is a functional model of the optical encoder that
is present in the actual motor. The values of the signals Current, IdealSpeed, and A, B, and I
are sent to the controller.

4. Digital Controller Design

With the H-bridge topology selected for the analog power stage, the corresponding digital
controller was designed in LabVIEW. The controller consists of a quadrature decoder, a PI
controller, a PWM generator, and an H-bridge driver (items 1-4 in Figure 8). For this design, the
default on-board 40 MHz FPGA clock was chosen because it permitted the generation of a high
resolution 20 kHz PWM digital pulse with small duty cycles and dead-times.

4.1. Quadrature Decoder

The quadrature decoder calculates the position, velocity, and acceleration based on a
quadrature encoder signal (speed sensor data) from the motor. The velocity output is updated on
every falling edge of the clock input; however, by using the Clock Divider signal the time
interval between velocity updates was increased by N number of clock cycles. While this
increases the delay between velocity updates, as more encoder pulses are acquired during the
larger time interval, the accuracy of the measured velocity is improved.

The velocity is calculated in units of Counts/Interval. Using the conversion derived in

equation (1) this raw value was converted to revolution per minute (RPM).


 =  ! ∙ "#$%&'$&()

(1)
-./  0 -102 1  4 60 1
*ℎ, "#$%&'$&() = ∙ ∙ ∙
 03445 500  14 8
 For the design presented in this paper a  03445 of 20000 was chosen. This
amounted to an "#$%&'$&() of 30, and a new velocity update every 0.5 ms.

4.2. PI Controller
In order to prototype the controller on an FPGA the continuous time model for the
controller had to be discretized. To demonstrate the approach for custom fixed-point algorithm
development, the already available discrete time PID controller node was not used as part of this
brushed DC motor drive case study. The discretization approach presented can be used to move
any floating point algorithm to a fixed point representation for execution on an FPGA.

To make the PI controller design reusable, the controller was designed to operate at a rate
of 40 MHz (the default clock speed for most FPGAs). Any code executing at that rate must
compute its outputs within a single clock period of the FPGA. Such a fast controller was not
necessary for the brushed DC motor application presented in the paper (especially when the
brushed DC motor was loaded by a large inertial disk); however, a high speed controller offers
improved disturbance rejection, and can be used to maintain control of very high bandwidth
actuators.

The continuous time PI controller equation was discretized by using the backward Euler
approximation for the integral term, as shown here:

9: = ' 9: + & 9:

*ℎ, ' 9: = <' 9:
%
& 9: = <& = 9:5
>
3404?4: ' 9A : = 9A :
5& 9: (2)
= <& 9:
5
& 9A : − & 9ACD :
= <& 9A :
EF
& 9A : = & 9ACD : + <& EF 9A :
9A : = & 9ACD : + <' 9A : + <& EF 9A :

where, 9: is the controller output; ' 9: is the proportional portion of the controller output;
& 9: is the integral portion of the controller output; 9: is the control error (i.e. the difference
between the process variable and the desired set point); <' it the proportional control coefficient;
<& is the integral control coefficient; A is the discretized time; and EF is the sampling interval of
the discrete PI controller. Figure 6 shows the implementation of the discrete time, fixed point PI
controller.
 Taking advantage of the FPGA fixed point math the discrete time PI controller logic was
further augmented to include anti-windup. Anti-windup ensures that the integral part of the
controller is limited whenever the motor response saturates, thereby ensuring that the controller
is ready to resume action as soon as the control error changes. By enabling saturation in the
fixed point configuration of the high throughput math functions, the integral term, & 9A :, and
the controller output, 9:, were limited to a range of -1024 to 1024. This range was chosen
since it is a multiple of 2, and the PWM generator block which is fed by the PI controller
expected a value in the range 0 to 2000.

Figure 6: A 40MHz discrete PI controller, implementation according to equation (2). The fixed point
math precision was adjusted to implement anti-windup, with the integral term and the output terms
limited to a range of [-1024, 1024].

To reduce the propagation delay of the high throughput math functions, and thereby
ensure that the discrete time PI controller could execute at the required rate of 40 MHz, these
additional fixed point math precision limitations were placed:

• <' was limited to a range of [0, 63.8750], and could be changed in steps of 0.125, and
• for a 40 MHz clock, <& could be changed from 0 in steps of approximately 2.384.

These fixed point precision limitations did not impact the selection of the proportional and
integral coefficients of the PI controller. In Figure 7, the response of the discrete time PI
controller is compared to the continuous time PI controller. As seen in the image, when the
sampling time of the integral term is E = 2.5−8 (40 MHz FPGA clock), the discrete time
controller tracks perfectly the continuous controller output. Figure 7 also illustrates the anti-
windup behavior of the PI controllers, with the output limited to 1024.
 Figure 7: Comparison of discrete time PI controller to continuous time PI controller. With HI = J,
HK = LM, and NO = P. LQ−R the output of the continuous and discrete time PI controllers is nearly
identical.

4.3. PWM Generator and H-bridge driver

For the brushed DC motor speed control design the H-bridge was driven using lock anti-
phase mode. In this driving mode the four switches of the H-bridge are turned on and off in
every cycle, with the diagonal switch pairs of the H-bridge driven together. In this design, a
PWM duty cycle of 50-100% would spin the motor in the clockwise (positive) direction, while a
0-50% PWM duty cycle would spin the motor in the counter-clockwise (negative) direction. A
duty cycle of 50% resulted in no spin since the average voltage across the motor was 0 V (there
was no external torque applied to the shaft of the motor).

As per requirements, the PWM generator node (node 3 in Figure 8) was configured to
generate a 20 kHz digital pulse, with the duty cycle of the PWM regulated by the output of the PI
controller (node 2 in Figure 8). The H-bridge driver nodes (nodes 4 and 5 in Figure 8) convert
the PWM duty cycle into the drive signals for the H-bridge switches.

In order to prevent shoot-through, which can happen when S1 and S2 (or S3 and S4) of
Figure 5 are on at the same time, the H-bridge driver node implemented dead-time control. The
dead-time is inserted whenever the controller switches current between the diagonal switch pairs
of the H-bridge. During the dead-time all switches are off and the armature current flows
through the freewheeling diodes. For our design, 2.5 µs of dead-time was required in the worst
case. This value was originally determined using high-fidelity SPICE models in simulation, and
verified during prototyping.
5. System Co-simulation
With the analog power stage model and digital controller design complete, the entire
system was analyzed and optimized using co-simulated. In the co-simulation environment,
Multisim and LabVIEW concurrently perform a non-linear time-domain analysis, exchanging
data at the end of each time-step. What’s more, when LabVIEW is configured to use a variable
step size solver Multisim and LabVIEW are able to negotiate future time-steps, resulting in a
tightly integrated and accurate simulation. The result is that both tools can enforce accuracy
requirements that ensure valid simulation results, even in the case of coupled differential
equation relationships that span between both solvers. In the case of a brushed DC motor, such
coupled dynamics exist if the mechanical load system is modeled in LabVIEW and the electrical
system in Multisim. Because the mechanical torque of a motor is proportional to the electrical
current, the mechanical and electrical dynamics are inextricably linked. If a sufficiently fine
time-step is selected, as is necessary during the initial in-rush current startup behavior of the
motor, the simulation performance for the overall simulation will be much slower than
necessary. On the other hand, if a larger time-step is chosen, the simulation results may be
dangerously inaccurate. To further complicate the matter, the required step size varies
throughout the simulation run and depends on the nature of the control action. A higher
bandwidth control compensator or fast changes in the set point will necessitate a finer time-step.
Not surprisingly, designers must use fixed time-step co-simulation tools with caution; especially
in the case that dynamic coupling exists between the two tools. Since no coupled dynamics
existed in our case study of the brushed DC motor, using a variable step size solver was not
necessary; a fixed step size solver was adequate.

The simulation diagram of the complete brushed DC motor drive systems is shown in
Figure 8. Node 5 contains the power circuitry plant model designed in the Section 3.3. It is
simulated using Multisim. Everything else in the figure represents elements of the control
system (nodes numbered 1-4) or elements used to support the simulation, all of which are
simulated using LabVIEW.

The FPGA nodes in the simulation diagram (velocity decoder, discrete time PI controller,
PWM generator, and H-bridge driver) were configured for discrete time execution (indicated by
the ‘D’ glyph) in the upper right corner of each node. Configuring the discrete time execution
rate of these nodes for simulation was necessary in order to simulate the precise timing behavior
of the code as it executes on the FPGA.
 Figure 8: Closed loop system simulation of the brushed DC motor controller. The LabVIEW Control
& Simulation Loop (black) executes the simulation diagram. Nodes 1-4 are part of the digital
controller and are (in order): the speed decoder, continuous time PI controller, PWM generator, and
H-bridge driver. The plant model, node 5, consists of the MOSFET switches, brushed DC motor, and
an optical encoder executing in the Multisim SPICE simulation environment. The one time-step delay
added to the optical encoder outputs (A, B, and I) are necessary in order to perform a closed loop
simulation. The ‘Sim Tic Count’ variable was used to simulate the FPGA clock whenever the
simulation step size was larger than the FPGA clock period (N = P. LQCR ).

In order to closely replicate the synchronous sequential logic behavior of the digital
controller, the simulation diagram was solved using the Runge-Kutta 1 (RK1) fixed step size
solver. A fixed step solver has the advantage of accurately representing the actual FPGA
execution behavior; however, this comes at the cost of performance, since a step-size must be
chosen to match the FPGA clock period (2.5 CS for a 40 MHz clock). To get around this
problem the “Sim Tic Count” variable in Figure 8 was used. With this variable it was possible to
simulate the tic count of the 40 MHz FPGA clock even when a step size larger than the actual
FPGA period was used. This greatly improved simulation speed; however, it yielded an
approximation of the true cycle-by-cycle execution timing behavior of the FPGA code. In this
case study, the solver step size was typically chosen as either 2.5 CT or 2.5 CU , depending on
the desired accuracy. Using the smaller step size (2.5 CU : allowed for a higher resolution
simulation of the PWM signal (and hence better armature current prediction) at the cost of
simulation speed; however, for the purposes of selecting the PI controller coefficients the larger
step size (2.5 CT : was adequate.
 Throughout the system analysis, to gain insight into the brushed DC motor drive system
behavior, various signals inside the embedded FPGA control code and the analog plant model
were monitored during co-simulation. Having the ability to probe any signal (e.g.
currents/voltages inside a MOSFET/motor, or the dead-time behavior of the control code)
allowed for validation of system connectivity and a much deeper understanding of the system
behavior.

To perform system optimization, the behavior of the brushed DC motor drive system was
analyzed in simulation for various expected operating cases. These included:

• Start up (0 RPM to ±1200 RPM),

• Stopping (±1200 RPM to 0 RPM),
• Transitioning between 1200 RPM and -1200 RPM (and vice versa), and
• Transitioning between speeds lower than 1200 RPM.

Through an iterative process, the transient response of the system for these operating cases was
analyzed and appropriate values for the proportional and integral coefficients were determined.
It was found that selecting <' = 1, and <& = 50 allowed us to satisfy the brushed DC motor
drive requirements outlined in Section 2. These same PI controller coefficients were later used
in the physical prototype. The system co-simulation results are presented in Section 7.

In addition to optimizing the PI controller coefficient, co-simulation was helpful in

determining the type of drive mode to use for the H-bridge. After attempting to use the drive
mode implemented as part of the intellectual property (IP) libraries available in LabVIEW, it was
determined that this drive mode was inadequate for our needs and had to be redesigned. The
problem was further convoluted as the new drive mode (lock-anti phase, see Section 4.3),
necessitated a change in the dynamic range of the PI controller, signal level adjustment between
the PI controller and the PWM generator, and the ability to specify a dead-time for the controller.
All such significant changes to the controller were verified using system co-simulation.

6. System Prototype
After performing system co-simulation and attaining a high degree of confidence that the
complete brushed DC motor drive system would behave as desired, a physical prototype was
developed. The analog power stage was prototyped on a basic proto-board using discrete
components, including bypass capacitors on the power rails. To expose the prototype to a
mechanical load expected in the final application, a steel disk, whose moment of inertia can be
controlled by varying the radius according to equation (3), was machined and fixed to the shaft.

1 1
V&FW =  = 91.381 :90.0762 : = 0.00026714  ∙  (3)
2 2
 The controller was implemented on the CompactRIO FPGA-based based embedded platform,
platform
as described in Section 6.1. CompactRIO I/O modules were used to sample the armature current
and interface with the velocity encoder and the gate drivers on the proto
proto-board.
board. Note that since
the implemented controller strategy did not involve current limiting, the sampled armature
current was used for monitoring purposes only. Figure 9 shows the resulting prototype.
prototype

Figure 9: Brushed DC motor controller prototype.

6.1. Digital Controller Implementation

Figure 10 shows the digital controller as was it is implemented on the Xilinx Spartan-3
Spartan
2M Gate FPGA inside of the CompactRIO
CompactRIO. The controller is configured as a 3-stastage pipeline as
follows:

Stage 1: Quadrature decoder

Stage 2: Discrete time PI controller
Stage 3: PWM generator and H H-bridge driver

Each stage of the pipeline execut

executes in one clock cycle.
 Figure 10: The 40 MHz FPGA
PGA implementation of brushed DC motor controller, for the NI
CompactRIO-9074.. The numbered items are (in order) the speed decoder, discrete time PI
controller, PWM generator, and the H-bridge driver.

The FPGA nodes 1-4 in Figure 10 are the same nodes that were used for system
co-simulation (see Figure 8)) during system design. These FPGA control nodes were configured
in exactly the same way for the prototype as they were in simulation
simulation. The experimentally
measured data is compared to the simulation data in Section 7.

7. Results
Figure 11 shows the simulated and measured response of the brushed DC motor system
to a step change in the motor speed from 0 RPM to 1200 RPM. Figure 11A A is a plot of the motor
speed. The stair case effect that can be seen on the speed curve (moves up in steps of 30 RPM)
is the result of the quantization introduced by using a velocity decoder
decoder. The simulated speed
curve tracks very well with the experimentally measured speed response of the motor. Figure
11BB shows the simulated and actual armature current through the motor. The current peak,
during the period of inrush current resulting from the initial startup behavior of the motor,
matched very well between
tween simulation and experiment. Being able to predict this peak current
and how long such large current are sustained is important for preventing damage to expensive
parts (such as the motor), and determining whether the available power supply is able to keep up
with the current demand.

Figure 11: Simulated and measured response of the Brushed DC motor to a 1200 RPM step command.
The controller parameter were HI = J, HK = LM, and dead-time of 2.5 µs. The simulation data was
collected using the RK1 solver with a step size of P. LQC[ s.

Figure 11C shows the input signal of the PWM generator (the PWM duty cycle
command). As with the speed, the quantization introduced by the velocity encoder is responsible
for the stair case effect. Both in simulation and experiment the PWM duty cycle command
signal settled at approximately 1500. In order to achieve such good agreement, the static friction
torque of the motor (a measure of the resistance to angular motion) had to be taken into account.
This was achieved by augmenting the plant model of Figure 5 with a controlled current source on
the shaft of the motor. The effect of including the shaft friction in simulation was apparent in the
steady state armature current of approximately 0.4 A, which was also observed in the physical
prototype. The impact of the shaft friction was also apparent in the open-loop analysis of the
controller (these results are not presented here).

Overall, excellent agreement was observed between the simulation and experimental
results, and with the presented co-simulation method, the embedded system code matched the
code used during the simulation/design stage, thereby eliminating potential sources of error and
increasing our confidence in the value of simulation as a design tool.

8. Summary
This paper presented new co-simulation methodology that enables full system
verification of mixed signal designs on a standard PC. A case study of a closed-loop DC motor
drive was presented, which demonstrated that the co-simulation methodology can be used for
insightful evaluation of a complete mixed signal application prior to creating a physical
prototype. Furthermore, this methodology makes it possible to do complete system simulation
using the exact same FPGA code which can eventually be used to target the hardware. The
result is an improved design approach, reducing prototype iterations, improving digital design
and speeding time to implementation.

Excellent agreement was observed between the experimental and simulation results in the
case of the DC motor drive. In our design the digital controller operated at 40 MHz with very
low latency, while the analog drive circuitry was switched at a much slower maximum rate of
20 kHz. Since the analog switching frequency was a few orders of magnitude lower than the
digital, modeling FPGA timing in simulation was not necessary. For designs with similar
requirements, this new co-simulation methodology allows for rapid verification and
implementation of high fidelity prototypes.

In addition to the presented motor drive case study, co-simulation can be used for
studying other complex dynamic systems with coupled dynamics that cross the domain
boundaries between the digital software domain and the physical world, including switched-
mode power supplies, grid-tied inverters, and vector control of AC machinery.
Appendix A: DC Motor Model and Parameters
The equations that describe the behavior of the brushed DC motor model are [2]:

5^9: 5a9:
E\ 9: = ] + E_ + `\
5 5
549: 5a9: (A1)
b\ 9: = 49: + c + <(
5 5
E\ = <% 49:

where and c represent the resistance and inductance of the motor armature, respectively;
E\ 9: is the motor torque; ] is the rotor and mechanical load inertia; ^9: is the shaft velocity;
E_ is the load torque; `\ is the friction torque constant; a9: is the angular position of the shaft;
b\ 9: is the motor terminal voltage; <( is the back electromotive force (emf) constant; <% is the
torque constant; and 49: is the armature current.

The brushed DC motor that was used in this study was the Midwest Motion Products
D22-376D-24V brushed DC motor. The specs for the motor were supplied in the manufacturer’s
datasheet. The relevant parameters are summarized in Table A.1. The nominal motor
parameters of Table A.1 were used in all simulations presented in this paper. The friction torque
constant (`\ ) was not provided by the manufacturer and was not considered in the simulations;
however, the static friction torque coefficient which was supplied by the motor manufacturer
upon request was taken into account.

Table A.1: Datasheet parameters for the Midwest Motion Prodcuts D22-376D-24V brushed DC motor.

Performance Parameters Value Tolerance

Rated DC Voltage 24 V ---
Rated Continuous Current 4.1 A ---
Rated Speed 4700 RPM ± 15%
Back EMF Constant (<( ) 4.5 V/kRPM ± 10%
Torque Constant (<% ) 0.0431 Nm/A ± 10%
DC Armature Resistance (@1.5 A) 0.94 Ω ± 15%
Armature Inductance 0.85 mH ± 15%
Rotor Inertia 2.825E-5 Kg·m² ---
Static Friction Torque1 0.0141231 N/m ---

1
The approximate static friction was provided by the Manufacturer upon request.
Appendix B: Power Switch Thermal Stress Analysis
Without extensive design experience, using only a datasheet to determine the suitability
of a power transistor for application requirements can be problematic if the switch performance
outside a steady, continuous current mode of operation is considered. For instance, if the switch
carriers a transient burst of current, a designer may be able to use the dynamic thermal
impedance curves (or “Z-theta” curves) to predict the peak junction temperature, but only if the
designer knows the case temperature [3]. However, unless a very large heat sink is used, few
assumptions about the case temperature should be made. Another complication comes from
switching losses, which at high frequencies contribute significantly to the overall losses, raise the
junction temperature, and further de-rate the device

Fortunately, simulation models and tools can aid with the analysis in a way that considers
the coupled dynamic interaction between the electrical and thermal domains. In this case, high-
fidelity SPICE models of the gate driver and the switches are available. If long simulation times
were acceptable, it is possible to analyze the stress on the switches in a transient simulation that
models the exact application scenario. However, for faster results a simplified worse application
scenario was analyzed. If in the worst case scenario the switches are within operating limits, then
it should be expected that the switches will satisfy design requirements during less stressful
modes of operation. This was the approach taken.

In this approach, the end goal was to calculate the peak junction temperature and to
ensure that it was below 125 °C, which would indicate that the device is operating within safe
operating limits.

Based on the curves from the feasibility tests, a simplifying assumption was made that
any one of the switches conducts current only during the 0.7 second transient when the motor is
either accelerating or decelerating. This assumption was made because the overall motor load is
completely dominated by inertia (when the speed is not changing, the load from the inertia is
zero and therefore only enough current will flow to overcome friction and maintain constant
speed operation). It was also assumed that during the 0.7 s transient the controller would
exercise the switches in a way that produces both switching and conduction losses.

To simplify the analysis a theoretical worst case scenario was assumed. First, it was
assumed that switching and uninterrupted conduction losses accrue throughout the entire 0.7 s
transient. Second, it was assumed that switching losses occur at the maximum expected current
of 13.5 A operating point throughout the period. And finally, it was assumed that the MOSFET
drain-source resistance was at the design limit value of 125 °C. The analysis procedure is only
discussed for the P-channel MOSFET.

In order to construct a simplified circuit to calculate the worst case junction temperature,
worst case turn-on and turn-off losses first needed to be determined. To accomplish this, the
circuit of Figure B.1 was constructed and analyzed. The gate driver, U2, and P-channel
MOSFET, U9, were modeled using high-fidelity SPICE models provided by their respective
manufacturers. In addition to modeling electrical behaviour, the P-channel MOSFET models the
thermal behavior and self-heating of the device package. For this test, the P-channel MOSFET
was assumed to be operating in an environment with an ambient temperature of 25 °C through a
heat sink with a thermal resistance of 60 °C/W (a typical value if the device case is mounted to
the printed circuit board).

Figure B.1: A high-fidelity circuit designed to analyze the worst case turn-on and turn-off losses of the
P-channel MOSFET.

Using very small time-steps to capture the details of the switching events, a transient
analysis was run and the turn-on and turn-off switching losses of U9 were recorded for one
switching cycle. These are shown in Figure B.2.

Figure B.2: Worst-case expected switching losses.

 The electro-thermal circuit of Figure B.3 was then constructed to measure the junction
temperature.
Thermal network

Vds Tjunction
VIds
Rsink

60C/W
0V
U2
Rds P_cond P_sw
Icond Tambient
35mΩ R-C 25C
I = { I(vvids)*v(vds) } I = { v(P_sw)*v(isActive) }

P_sw isActive

V2
V1
0V1V
0.7 sec 7.4 sec

Figure B.3: Simplified electro-thermal circuit for determining junction temperature

The important elements of the circuit are:

• Icond models using a piece-wise-linear current source the armature current which was
recorded during the feasibility test. This current is injected into the switch, modeled as a
simple Rds resistor, for the 0.7 s transient. No current is injected during the remainder of
the 7.4s period when the motor is expected to be at steady speed or accelerating in the
opposite direction. This current can be seen in Figure B.4B.
• P_cond is a controlled current source that calculates and injects the conduction losses
into the thermal network.
• V1 is a piece-wise-linear voltage source that places on node P_sw a voltage signal that
represents the turn-on and turn-off power losses recorded using the high-fidelity models
(Figure B.1) and is used by current source P_sw. The losses are repeated at the switching
frequency of 20 kHz.
• V2 is a periodic voltage source that places onto node isActive 1V for 0.7 seconds, and 0V
for 6.7seconds. This is the same duty cycle and period as the conduction current in
source Icond. The voltage is used as a boolean by P_sw to blank out the injected
switching losses during the time when no current flows through the switches (i.e when
the motor is at steady speed or is accelerating in the opposite direction) This is shown in
Figure B.4C.
 • P_sw is a controlled current source that injects the switching losses into the thermal
network.
• U2 contains an RC ladder that represents the thermal network of the switch. It was taken
directly from the high-fidelity switch SPICE model.

The goal was to run a transient analysis until:

1. The voltage on the node “Tjunction”, which represents the junction temperature,
stabilizes.
2. To ensure that its peak value is below 125 °C (represented using Volts).

A transient analysis was conducted over 70 seconds. The junction temperature is shown
in Figure B.4A. Because the junction temperature did not exceed 120 °C, the switches were
deemed suitable for the application.

Figure B.4: Results of key signals following a 70 s transient analysis.

References
1. Brian MacCleery, Zaher M.Kassas. New Mechatronics Development Techniques for
FPGA-Based Control and Simulation of Electromechanical Systems. Peer review paper
published at IFAC 2008, the International Federation of Automatic Control World Congress.
July 2008.

2. Krause, Paul C., Wasynczuk, Oleg and Sudhoff, Scott D. Analysis of electric Machinery
and Drive Systems, Second Edition. Piscataway : Wiley-IEEE Press, 2002.

3. Divins, David. Simulation MOSFET Heating Caused by Inrush Currents. Power Electronics
Technology. June 2007.