VHDL–AMS Modeling and Simulation Support for SoCDesign and Implementation of AC Motor Drives

Juan R. Pimentel and Arturo Rojas–MorenoKettering University, 1700 W Third Avenue Flint, Michigan 48504, USA

Universidad Tecnologica, corner 28 de Julio Ave. with Petit Thouars Ave., Lima 1, Peru

Abstract— This paper details how the VHDL–AMS lan-guage can be used to support steps I through IV of a sixstep SoC (system on chip) design and synthesis methodol-ogy with high productivity gains. This is because about80 to 90% of the VHDL code used for synthesis in phasesV and VI is the same code developed in phases I throughIV with the VHDL–AMS language. A case study involv-ing the motor drive of a hybrid electric vehicle is used todemonstrate the details of the methodology. The SoC is aSpartan 3A FPGA of Xilinx. Detailed models, simulations,VHDL–AMS code and VHDL synthesis code is included.

Index Terms—System on chip, system level design, based–FPGA motor drive implementation, VHDL–AMS.

I. Introduction

In some industries, e.g., hybrid electric and electric ve-hicles, there is a need to design and implement AC mo-tor drives with high performance while optimizing cost [1].However these systems are complex and designing and im-plementing them with high productivity gains poses signifi-cant challenges [2]. These challenges are particularly severeif the design and implementation is to be done by juniorengineers or even upper classmen engineering students be-cause they do not have enough knowledge and/or experi-ence. To overcome these challenges a design methodologyusing system level design (SLD) or system on a chip (SoC)has been proposed [3]. For many applications, FPGAs of-fer advantages over traditional microcontrollers in terms ofcost and performance. SLD or SoC implementation of ACmotor drives on FPGAs are becoming attractive because oftheir potential to achieve high performance at a relativelylow cost [4].

The system design methodology described in [3] helpsto undertake complex projects even by engineers with lim-ited knowledge or experience. This paper details how theVHDL–AMS language can simplify the entire process andin fact produce target code that can be directly synthesiz-able on the FPGA, thus achieving high productivity gains.This is because VHDL, the primary synthesis languageused in many designs, is a true subset of VHDL–AMS [5].By using a tool such as SystemVision (from Mentor Graph-ics), one can begin with VHDL–AMS simulations and grad-ually convert the simulation models to VHDL taking intoaccount the hardware details of the particular FPGA. Thusthe final VHDL–AMS code can be directly synthesizableusing the FPGA vendor tools.

The main elements of AC motor drives are the AC motor,the motor controller, the power inverter, and the inverter

Work on this paper was supported in part by a grant from MentorGraphics to Kettering University.

firing controller as shown in Fig. 1 that pictures how thesecomponents are configured to build the powertrain for ahybrid electric vehicle (HEV). VHDL–AMS is a relativelynew yet powerful language that is a superset of the widelyused simulation and synthesis language VHDL. As such, ithas several features that make it advantageous to providea high level of support to SoC design and implementationmethodologies. In this paper, we discuss a number of is-sues related to the use of VHDL–AMS as the primarilylanguage to support the modeling, design, simulation, andimplementation of ac motor controllers using FPGAs. Thesimulation tool is SystemVision that implements VHDL–AMS.

Fig. 1. Main components of HEV powertrain.

II. SoC Implementation of AC Motor Drives

The objective of the SoC design and implementation ofthe motor drive is the FPGA design and synthesis of theAC motor controller including the inverter firing controller.A number of authors have proposed the use of a phased ap-proach in the SLD or SoC design methodology such as theone describe in the following consisting of six phases [3]:

• Phase I: Behavioral VHDL–AMS modeling and simula-tion.• Phase II: Behavioral VHDL–AMS architectural model-ing and simulation.• Phase III: Digital properties modeling and simulation.• Phase IV: Synthesizable modeling and simulation.• Phase V: Logic Synthesis.• Phase VI: Overall final test, verification, and validation.

Phases I and II aim at modeling the behavior of the entiresystem in a monolithic fashion and architectural fashion re-spectively. Whereas phase I is done any which way, phaseII introduces structure through architectural components

as shown in Fig. 2. In fact VHDL–AMS supports thesetwo phases almost naturally through a behavioral architec-ture and a structural architecture respectively [5]. The aimof phases I and II is to obtain an intuitive understandingthrough modeling and simulation independently of the im-plementation platform. Thus, phases I and II are usefuleven if the implementation is done with microcontrollersor other means other than FPGAs.

Whereas phases I and II are independent of the imple-mentation, phases III and IV are specific to the synthesisplatform and details of the specific FPGA are necessaryfor their completion. In this paper, we are using the XilinxSpartan 3A FPGA, thus a great deal of the details are spe-cific to this SoC. Nevertheless, phases III and IV are stillin the modeling and simulation domain. Thus, althoughthe details correspond to a specific FPGA, they are stillgeneral models that can be executed in any VHDL–AMStool such as SystemVision.

Fig. 2. Architectural constituent components of the motor controllerand inverter firing controller.

The final phases V and VI are no longer modeling andsimulation, rather they correspond to the actual synthesison a specific SoC. These phases are outside the scope ofthis paper and of a tool such as SystemVision and theyare carried out by tools provided by the vendor of the SoC(e.g., ISE from Xilinx).

It is important to note the role of modeling and simula-tion in phases I through IV of the design methodology. Inthis paper we describe how VHDL–AMS can be effectivelyused in phases I through IV of the design methodology toachieve high productivity gains. This is because about 80to 90% of the VHDL code used for synthesis in phases Vand VI is the same code developed in phases I through IVin VHDL–AMS.

III. Role of VHDL–AMS in the DesignMethodology

As noted, VHDL-AMS can be effectively used to supportphases I through IV of the SoC design methodology. Themain idea is to start with a behavioral and architecturalVHDL–AMS model of all HEV components in phases I and

II of the design methodology then gradually convert theVHDL–AMS models into a pure VHDL model by replacingthe analog components with equivalent digital componentsin accordance with the specifics of the SoC to be used inthe synthesis. Thus, at the end of phase IV we end upwith VHDL code specific to the FPGA in question butthat can be simulated with a VHDL–AMS tool such asSystemVision. This is significant because in the last phasesof the methodology (V and VI) we simply tweak and/ormake minor modifications to the VHDL code from phaseIV to meet tool or design constraints. Such process resultsin significant reduction of complexity and high productivitygains.

More specifically, VHDL–AMS is advantageous to sup-port the above SoC design methodology involving HEVcomponents such as ac motors, motor controllers, powerinverters, and inverter firing controllers [6]. VHDL–AMSis ideally suited for modeling and simulation of phasesI through IV because the language supports behavioralmodels and architectural models. This is advantageouswhen analyzing the behavior, performance, and architec-tural properties of a design. VHDL–AMS is also ideal formodeling phase III: digital properties modeling and simu-lation. The synthesizable modeling and simulation step inphase IV involves both digital and analog (e.g., DSP algo-rithms) components that must be gradually converted tofully digital. In the following we provide details on howVHDL–AMS supports phases I through IV of the SoC de-sign methodology. The details are illustrated for the HEVcomponents shown in Figs. 1 and 2.

A. VHDL–AMS Support for Phase I

Phase I of the SoC design methodology basically involvesthe use of top level behavioral models in VHDL–AMS andthere are many examples in textbooks and websites that il-lustrate this level of modeling and simulation [5]. The mod-els are simplified to keep the entire simulation simple (e.g.,model of an AC motor in synchronous coordinates in thed-q axis) [7]. The emphasis is on an intuitive understand-ing of the behavior of each component as well as the entiresystem. In the context of the modeling and simulation ofHEV components, this phase is particularly important forthe modeling, simulation, and design of ac motor controlsystems. It is important to keep in mind that this phase isindependent from the target implementation (e.g., micro-controller or FPGA), independent of the implementationarchitecture, and not directly related to synthesis.

A.1 Modeling and Simulation of the AC Motor and MotorController

To illustrate the typical models considered in phase I weprovide an example that corresponds to an AC inductionmotor modeled in actual three phase coordinates (A, B, C)with a FOC (field oriented control) speed control systemmodeled in synchronous coordinates (d, q).

The operation of the AC motor control system is summa-rized next. The actual motor speed (VR_V) is subtractedfrom the reference speed or velocity (V_CND) and the er-

ror signal (V_ERR) is used as the input to the PI controller.The output of the PI controller (IEQS) represents the refer-ence current iq. A transformation is used to convert fromsynchronous coordinates iq (IEQS) and id (IEDS) to sta-tionary coordinates ISA, ISB, and ISC. The motor modelaccepts three-phase motor currents in stationary coordi-nates to generate angular velocity ω, motor shaft angle θ,and torque.

The graphical depiction of the model in SystemVision isshown in Figs. 3 and 4. The results of the simulation isdepicted in Fig. 5 showing the reference and actual mo-tor speed on the top (w_cnd and w_r), followed by thesynchronous currents ieds and ieqs, and followed by asuperposition of the three phase stationary currents of themotor isa, isb, and isc.

B. VHDL–AMS Support for Phase II

In phase II, structure is introduced to what is modeled inphase I by means of an architecture, its constituent compo-nents, and interfaces between components. In this phase,the component interfaces of the architecture are carefullydefined. The overall system is decomposed into constituentarchitectural components related to final implementationbut still independent from the target implementation (e.g.,microcontroller or FPGA) and independent from synthesis.

To illustrate this phase, we provide results of an archi-tectural model that corresponds to the power inverter andpower inverter firing controller of Fig. 2. The architecturalmodel that includes the motor but not the motor controlleris shown in Fig. 6.

The inverter is a standard 3–leg, 6 switch power inverterthat drives the three inputs of the three phase AC motor.Two types of inverters can be modeled: ideal switch andIGBT switch. Fig. 7 shows an inverter model based onideal switches. The inputs to the model are the three dig-ital control signals SA, SB, and SC, while the outputs arethe three phase motor stator voltages VA, VB, and VC. Thepower inverter accepts a generic DC battery voltages of Evolts.

Fig. 3. SystemVision model of a FOC for an induction motor (Leftportion).

Fig. 4. SystemVision model of a FOC for an induction motor (Rightportion).

B.1 Modeling and Simulation of the Power Inverter

Fig. 5. Simulation results for the SystemVision model of a FOC foran induction motor.

Fig. 6. Test bench for testing the inverter firing controller, powerinverter, and motor.

B.2 Modeling and Simulation of Inverter Firing Controller

We have developed a generic model for the inverter firingcontroller that is capable of working with a wide variety ofpower inverters that includes an arbitrary number of sam-ples of the sinusoidal signals (variable frequency). The ini-tial simulations use the standard six–step inverter based on

Fig. 7. Details of the ideal switch model of the power inverter.

6 samples per period. As depicted in Fig. 2, the inverter fir-ing controller consists of two blocks, the pulse control blockand the PWM control block. Whereas the latter block cal-culates the duty cycles (i.e., widths) and the timing, thepulse control block actually generates the digital controlsignals Sa, Sb, and Sc,. The inverter firing controller usesthe following as input parameters in their calculations: In-verter DC voltage E, motor frequency f , sampling periodTs, motor speed ω, and rotor angle θ. The inputs to the in-verter firing controller are the voltage outputs generated bythe control algorithm block. The three-phase duty cyclesare:

Dα =Tα

TsDβ =

Tβ

TsDγ =

Tγ

Ts(1)

where

Tα = Ta + Tb + Tc Tβ = Tb +To

2Tγ =

To

2(2)

Ta =(

Vref

E

)√3Ts sin(π/3 − θ)

Tb =(

Vref

E

)√3Ts sin θ Tc = Ts − Ta − Tb (3)

and Vref is the magnitude of the three phase reference volt-ages (Va, Vb, Vc) given by the motor control algorithms. Forexample, for the open loop system of Fig. 6, with f = 20Hz, T = 0.05 sec, E = 200 V, Vref = 43.478 V, Ts = T/6= 8.333 ms, the width of the PWM signals Ta, Tb, and Tc

with their corresponding duty cycles are given in Table I.

TABLA I

Width of the three-phase PWM waveforms

Ta Tb Tc Duty Duty DutyCycle Cycle CycleDα Dβ Dγ

0.003138 0.003138 0.002058 0.876533 0.5 0.123467

The simulation results are shown in Fig. 8 where we cansee validated waveforms for Sa, Sb, and Sc on the top, fol-lowed by two of the three phase voltages given by the powerinverter (Va and Vb), and followed by the motor speed ωr.It can be noticed that the motor speed has an average value

of −124.85 rad/s but has a significant high frequency rippledue to high frequency harmonics of the switched voltagesgiven by the inverter. This high frequency noise needs tobe reduced by proper control methods.

Fig. 8. Waveforms of test experiment depicting Sa, Sb, Sc, Va, Vb,and motor speed ωr.

C. VHDL–AMS Support for Phase III

Since the final FPGA design is digital in nature, we be-gin by modeling and simulating the digital properties of thesynthesizable design in phase III. This is important becausethe VHDL–AMS model at the end of phase II contains bothdigital and analog components. We need to gradually re-place the analog components with digital components tak-ing into account the detailed characteristics of the targetSoC. Of course the exception is the analog componentsthat correspond to physical devices such as the motor orthe power inverter which do not need to be synthesized bya SoC.

A SoC device such as an FPGA is a purely digital systemand any analog component must be provided externallyto the FPGA. For example, the Xilinx Spartan 3A deviceneeds external devices for analog to digital conversion, pro-viding outputs for a video monitor, or driving communica-tion channels such as Ethernet or CAN.

The typical digital properties considerations in thisphase include whether an embedded processor is to be used(e.g., microblaze of Power PC), the accuracy of the analogto digital converters, whether fixed point or floating pointis to be used for signal processing, the accuracy of the cal-culations, and the digital architecture of the digital DSPcalculations.

For example, Figs. 9 and 10 correspond to the entityand architectural model of two analog to digital convertersavailable on the Spartan 3A. Note that the detailed modelsconsider actual hardware items such as clock (i.e., aclk_i)and reset (rst_i) pins. The architecture rt1 of the entitya dc_interface has three processes: clk_gen, conv_ctrl,and data_read. For space considerations, only portions ofthe the data_read process is detailed. Note that the finaldigital 12 bit representation of the converted analog signalsch0_s, and ch1_s are read from a long shift register namedshift_reg_s.

entity adc_interface isport

(clk_i : in std_logic;rst_i : in std_logic;sck_o : out std_logic;ad_conv_o : out std_logic;sdo_i : in std_logic;ch0_o : out std_logic_vector(11 downto 0);ch1_o : out std_logic_vector(11 downto 0));

end; -- entity adc_interface

Fig. 9. Analog to digital conversion entity.

architecture rtl of adc_interface issignal ad_conv_s : std_logic;signal ch0_s : std_logic_vector(11 downto 0);signal ch1_s : std_logic_vector(11 downto 0);signal clk_cntr_s : std_logic_vector(7 downto 0);signal conv_cntr_s : std_logic_vector(11 downto 0);signal rd_cntr_s : std_logic_vector(7 downto 0);signal sck_fe_s : std_logic;signal sck_q1_s : std_logic;signal sck_re_s : std_logic;signal sck_s : std_logic;signal shift_reg_s : std_logic_vector(33 downto 0);

begin -- rtl-- Drive output ports.sck_o <= sck_s; ad_conv_o <= ad_conv_s;ch0_o <= ch0_s; ch1_o <= ch1_s;-- ADC Clock Generation--clk_gen : process (clk_i, rst_i) isconstant clk_tmo_c: std_logic_vector(7 downto 0):=x"18";begin

-- . . .end process; -- clk_gen-- Conversion Control--conv_ctrl : process (clk_i, rst_i) isconstant conv_tmo_c: std_logic_vector(11 downto 0):=x"1FF";begin-- . . .end process; -- conv_ctrl-- Data Read--data_read : process (clk_i, rst_i) isconstant rd_tmo_c: std_logic_vector(7 downto 0):=x"22";--34begin

if (rst_i = ’1’) thenrd_cntr_s <= rd_tmo_c;shift_reg_s <= (others => ’0’);ch0_s <= (others => ’0’);ch1_s <= (others => ’0’);

elsif (rising_edge(clk_i)) then-- Load read counter when a conversion is commanded.---- Shift ADC data into shift register and read data--if (sck_fe_s = ’1’) then

if (rd_cntr_s /= 0) thenshift_reg_s <= shift_reg_s(32 downto 0) & sdo_i;

end if;end if;if (sck_fe_s = ’1’) then

if (ad_conv_s = ’1’) thench0_s <= shift_reg_s(31 downto 20);ch1_s <= shift_reg_s(15 downto 4);

end if;end if;

end if;end process; -- data_read

end rtl;

Fig. 10. Portions of the analog to digital conversion architecture.

D. VHDL–AMS Support for Phase IV

In this phase, the VHDL–AMS model of phase II is com-pletely converted to VHDL (i.e., from a combination ofdigital and analog to a strictly digital model) taking intoaccount the modeling considerations of phase III. Thus,this phase is target dependent as it takes into considera-tion, for example, how a specific SoC converts analog todigital, the nature and speed of clock signals, the hardwareinitialization handshake, PWM channels, synchronizationsignals, and data buffering.

For example, Fig. 11 shows a listing of the pwm entityin VHDL–AMS used for generating a PWM signal on theSpartan 3A. The corresponding architecture rt1 that im-plements the way the PWM signal is actually generated islisted in Fig. 12.

library ieee;use ieee.std_logic_1164.all;use ieee.std_logic_unsigned.all;

entity pwm isport (

clk_i : in std_logic;rst_i : in std_logic;f3_i : in std_logic_vector(11 downto 0);fout_o : out std_logic);

end; -- entity pwm

Fig. 11. Definition of the pwm entity.

architecture rtl of pwm issignal duty_s : std_logic_vector(11 downto 0):= x"FFF";signal fout_s : std_logic := ’0’;signal pwm_cntr_s: std_logic_vector(11 downto 0) := x"FFF";signal pizza: std_logic_vector(10 downto 0):= "11111111111";signal pancake : std_Logic_vector(11 downto 0):=x"FFF";

begin -- rtlfout_o <= fout_s;pwm_ctrl : process (clk_i, rst_i) is

beginif (rst_i = ’1’) then pwm_cntr_s <= (others => ’0’);

duty_s <= (others => ’0’); fout_s <= ’0’;elsif (rising_edge(clk_i)) then pwm_cntr_s <= pwm_cntr_s+1;

if (pwm_cntr_s = 0) then duty_s <= f3_i;end if;---- Initialize the PWM output when the counter rolls over

pizza <= x"7FF" - duty_s(11 downto 1);pancake <= ’0’ & pizza;

if (pwm_cntr_s = pancake) then fout_s <= ’1’;elsif (pwm_cntr_s =(x"FFF" - pancake)) then fout_s <= ’0’;

end if;end if;end process; -- pwm_ctrl

Fig. 12. Portions of the architectural implementation of the pwm

entity.

E. VHDL–AMS Support for Phases V and VI

There is no direct support of VHDL–AMS for phases Vand VI as these phases are done using the tool provided bythe SoC vendor (e.g., ISE of Xilinx). As noted, if all previ-ous phases are done correctly, then about 80 to 90% of thesynthesizable VHDL code in phases V and VI are obtainedfrom executing phases I through IV. As such, phases V andVI are outside the scope of this paper.

IV. Discussion

The complexity of the simulation, design, and implemen-tation of a HEV powertrain is well acknowledged. Suc-cessfully designing a complete HEV powertrain requiresextremely knowledgeable people with a great deal of ex-perience. The needed resources in terms of time, devices,components, and qualified personnel is high thus resultingin a low productivity gain. The challenge is to successfullycomplete and test a design with personnel having an av-erage level of knowledge and experience and in a shortertimeframe, thus increasing significantly the productivitygains. If this is accomplished, then it would be easier tocomplete designs in a shorter time frame with less experi-enced personnel resulting in lower costs.

The methodology used in this paper has been proven ef-fective in reducing the complexity of the design and imple-mentation of HEV components and achieving productivitygains. One of the main advantages of the methodologyis that the code developed through modeling and simula-tion using the VHDL–AMS language through phases I toIV is the final target code (with minor editing) used tosynthesize the FPGA. Thus, another outcome of using themethodology is that it results in software reuse. Since thedesign is architectural, the various elements can be easilychanged resulting in an extremely flexible, modular, andscalable system. The modular approach makes it easy forlarge teams working on various aspects of a typical project,e.g., hardware, wiring, software, communications, testing,validation, and system integration working almost simul-taneously. But the methodology only works if appropriatemodels and tools are available. In this paper we have pre-sented models in the VHDL–AMS language well supportedby the tool SystemVision of Mentor Graphics. The simula-tion can be done at various levels of accuracy but requiresadditional modeling effort and simulation time.

The cost, speed, and performance of FPGA based con-trollers is promising, particularly for playing an importantrole in the electronics of HEVs. The testing of individualcomponents and the entire system is simplified (e.g., test-ing the ADC or PWM ) because they can be tested viasimulation, before they are synthesized. Of course the ac-tual components and final system needs to be thoroughlytested but this process is simplified by the testing done insimulation mode.

Vendor tools used in phases V and VI (e.g., ISE) alsohave some powerful simulation features. But these syn-thesis and simulation tools lack analog features and theycannot be used for simulating the entire system includingthe power inverter, battery, and motor. Having analog fea-tures and the capability of simulating components otherthat what is synthesized is perhaps the main advantage ofthe VHDL–AMS language and associated tools in the con-text of the SoC design methodology. In this paper, we haveextended the use and advantages of VHDL–AMS modelingand simulation to directly support SoC synthesis on targetsystems.

V. Summary and Conclusions

The use of VHDL–AMS in the context of a SoC designmethodology can be effective in reducing and managingthe complexity involved in the overall SoC design and im-plementation of entire systems such as an AC motor drive.More specifically, in the case study presented, VHDL–AMShas simplified most steps in the SoC design methodologygiving the designer confidence in all phases of the design.In addition it has helped to test, verify, and validate theentire design before implementation. At the implementa-tion stage it has helped to design and validate the digitalportion of the SoC synthesis (e.g., the inverter firing con-troller). One of the main advantages of the methodology isthat the code developed through modeling and simulationin the VHDL–AMS language through phases I to IV is thefinal target code (with minor editing) used to synthesizethe FPGA.

One advantage of simulation is that it gives considerablefreedom to try a variety of algorithms, architectures, mod-els, design properties, implementation properties, tradeoffsthus offering the possibility of improving or optimizing de-signs and saving considerable time.

Acknowledgements

The authors thank the assistance provided by KevinKlopfenstein of Xilinx and Mike Biggs of Avnet with someFPGA programming aspects of phases III and IV. Addi-tional thanks go to D. Teegarden and S. Cooper from Men-tor Graphics for their help on VDHL–AMS programmingaspects. In addition, the great effort by the following Ket-tering University students: Anthony Lane, Tim Masters,Nathan Nephew, Brett Ponton, Barry Troxell, and KurtWachowski who participated in a capstone senior designproject that used the methodology described in this paper,is also acknowledged.

References

[1] A. Haddoun, M.E.H. Benbouzid, D. Diallo, R. Abdessemed, J.Ghouili, and K. Srairi, A Loss–Minimization DTC Scheme forEV Induction Motors, IEEE TRANSACTIONS ON VEHICU-LAR TECHNOLOGY, VOL 56; NUMB 1, pages 81-88, 2007.

[2] A. Sangiovanni–Viccentelli, Quo Vadis, SLD? Reasoning Aboutthe Trends and Challenges of System Level Design, Proc. IEEE,Vol. 95, No. 3, pp. 467-506, March 2007.

[3] S. Jovanovic, and P. Poure, Design of power electronic digital con-troller based on FPGA/SOC using VHDL–AMS language, ISIE2007, IEEE International Symposium on Industrial Electronics,pp. 2301-2306, June 2007.

[4] L. Idkhajine, M-W. Naouar, E. Monmasson, and A. Prata, Stan-dard FPGA–based or Full FPGA–based Controllers for Electri-cal systems, two viable solutions, ISIE 2007, IEEE InternationalSymposium on Industrial Electronics, pp. 2332-2337, June 2007.

[5] P. J. Ashenden, G. D. Peterson, and D.A. Teegarden, The SystemDesigner’s Guide to VHDL–AMS, Morgan Kaufmann Pub., 2003.

[6] P. Poure, and S. Weber VHDL–AMS modeling for virtual pro-totyping of Very Large Scale Integration architecture for DirectTorque Control of an AC machine, IECON 2006, pp. 2979-2984,Nov. 2006.

[7] J. Solsona, M. I. Valla, and C.Muravchik, Nonlinear Control of aPermanent Magnet Synchronous Motor with Disturbance TorqueEstimation, IEEE Trans. on Energy Conversion, Vol. 15, No. 2,pp. 163-168, June 2000.