IEEE Power Electronics Magazine - June 2016 - 20

conjunction with the SE allow for code generation that has
(Rockville, Maryland)-is used as the SE. The system
all the configuration code for the MCU. It allows the users
presented in this article is deeply integrated with PSIM
to simulate the power stage along
and leverages multiple features of
with the MCU peripherals and use the
the software. It uses the various
SimCoder module to generate the
circuit blocks in PSIM (to describe
code for MCU configuration. The genthe power stage), the stepwise simuThe PIL system
erated code is directly imported into
lation capability of PSIM, and the
presented in this
Code Composer Studio (CCS), the
SimCoder plug-in, an autocode genintegrated development environment
eration module that has built-in feaarticle is designed
developed by TI for programming
tures of code generation for multiple
to work with almost
the MCUs.
hardware platforms [16]. The PIL
any fixed-point or
The SimCoder-generated code
system is integrated with the Simcan
be compiled and can be used for
Coder module from PSIM to minifloating-point
PIL simulations after making some
mize the code development efforts.
processors by Texas
minor modifications such as removThe PIL system presented in this
ing the code pertaining to ADC conarticle is designed to work with almost
Instruments of Dallas.
figuration, reading the data from the
any fixed-point or floating-point proADC, and variable scope of some varicessors by Texas Instruments (TI)
ables. The user also has the option to
of Dallas. The examples have been
write his or her own code for the PIL system, using the
provided using the TI F28335 Delfino 32-bit floating point
MCU or PSIM libraries in accordance with the guidelines
MCU processor. It uses TI Debug Server Scripting (DSS)
for the PIL system. The basic difference between PIL and
for facilitating the data exchange between the software and
SimCoder is that SimCoder uses coded hardware periphthe MCU. DSS is a collection of custom application program
eral models in simulation. A SimCoder simulation occurs
interfaces (APIs) developed by TI for controlling the MCU
completely in the SE and does not require an MCU. On the
during code execution. PSIM's SimCoder module is utilized
other hand, PIL brings the actual MCU into the simulation
to generate custom code for the control algorithm. After it
loop, which allows platform specific code to be tested.
is compiled with an appropriate compiler, the PIL system
can use this generated code for programming the MCU.

Development Methodology
SIL and SimCoder to PIL
SIL simulations are composed of coded models of the hardware peripherals and the power converter. The control
algorithm is implemented using these models. These coded
blocks (typically in C or C++) are then inserted into the
simulation environment and used as a part of the circuit.
This approach is a step closer to the real environment
when compared to the MIL, as it requires actual implementation or modeling of the block in code and is not merely a
model describing inputs and outputs, as is MIL. This
approach is used to detect coding failures that may appear
in the algorithm. At this stage, the coded algorithm is not
platform or MCU specific and is used for multiple design
iterations to eliminate the failures in the system. As a result
of a more detailed control algorithm implementation, the
simulations are slower than an MIL simulation. The blocks
required for SIL simulations can be built in the SE or can be
programmed into the software by the user. PSIM has multiple blocks that can be interconnected to represent the control system and also has blocks that accept custom C code
for any features that may not be present in the SE. PSIM
also has SimCoder, an automatic code generation feature
for different microcontrollers that has been utilized for generation of the code for the control algorithm. The SimCoder
module is made up of dedicated blocks for MCU peripherals such as ADCs, PWMs, and digital input-output that can
be used in the simulation. These peripherals blocks used in

IEEE PowEr ElEctronIcs MagazInE

z June 2016

The PIL system requires continuous communication
between the SE and the MCU. However, there is no
direct communication between the SE and the MCU. The
SE communicates only to the control script (CS), which
controls the data flow between the SE and the MCU. The
CS is also software that may or may not be integrated
with the SE. It serves as an intermediary between the SE
and MCU. This is necessary because there can be many
differences between the processing of the simulation by
the SE and the MCU. For instance, the precision of floating-point numbers is usually different between the SE
and the MCU. The data flow between them can be
achieved through multiple means. The data exchange
can be facilitated by using text or XML files or by network-based sockets or pipes. Both approaches were
used and the pipe method was chosen, as it had better
performance in terms of speed and reliability. For the
file method, the data exchange is depicted in Figure 2. In
this method, the software instance running on the personal computer (PC) writes its data into text or XML
file(s). The CS then reads the files and transfers the read
data to the MCU. After the MCU finishes its processing,
the CS reads the data from the MCU memory and writes
it to the same or a different text or XML file. The SE
instance then reads the files, updates its buffers, and
processes the data. After the data is processed, the new
values are written to the file being monitored by the CS,

Table of Contents for the Digital Edition of IEEE Power Electronics Magazine - June 2016