Implementing Field-Oriented Control for a Motor on an FPGA
Overview
Engineers are developing high frequency switching power electronics and motor control systems driven by complex algorithms. To implement such algorithms, engineers are considering FPGA/System on Chip (SoC) devices.
In this session you will learn how to deploy motor control algorithms on Xilinx Zynq UltraScale+ MPSoC module from the Trenz Electronic motor development kit with minimal FPGA programming knowledge. Using a field-oriented control (FOC) algorithm as an example, we will demonstrate HDL code generation for the FPGA fabric of the development kit to drive a permanent magnet synchronous motor (PMSM).
Highlights
- Simulate Field Oriented Control (FOC) algorithm for PMSM.
- Partition the control algorithm in the model between the processor and FPGA.
- Generate optimized C & HDL code from the Simulink model for the Xilinx Zynq UltraScale+ MPSoC module.
- Automatically deploy the code to both the processor and FPGA.
About the Presenter
Swathy Pillai is a Product Manager at MathWorks focusing on Motor Control Blockset. She holds a master’s degree in Electrical Engineering with specialization in Power Electronics & Drives and has over 5 years of experience in Model-Based Design related to power electronics and motor control. Before MathWorks, she worked with L&T Electrical & Automation, Schneider Electric India in R&D division where she was involved in control algorithm development and coding for Low and Medium Voltage industrial drives and other power electronic converters.
Recorded: 19 Oct 2022
Hello, everyone, and welcome to this webinar. I am Swathy Pillai a product manager at MathWorks supporting motor control development. And to tell you a bit more about my background. So I am a post-graduate electrical engineer with specialization in power electronics.
And prior to joining MathWorks, I worked as a power electronics and control engineer focused on building control algorithms and code development for industrial drives and various other power converters. And today, we will look at how to implement a field-oriented control for a motor on FPGA.
So today's webinar is for engineers who are targeting FPGA and SoC for their high-switching and computation-intensive motor control algorithms. So with that, let's have a quick overview.
So to make your motor control journey on FPGAs and SoC's easier, this webinar will be covering a workflow which will be demonstrated with the help of a reference example, targeting a SoC-based FPGA so that you can deploy your algorithms on your FPGAs easily and get your motor spinning quickly using Model-Based Design with Simulink.
So what are the key steps which are essential when we are talking about Model-Based Design for SoC-based FPGA? The first step, as we all know, is that we begin by simulating a field-oriented control for the motor. And that's a glimpse of the model which we would be using.
And you can also see the device we should be targeting along with the motor. And yes, all the controls as well as the subsystems are built in Simulink. And it's a permanent magnet synchronous motor for which the controls are built.
Now, because of the device which we are targeting, partitioning of the control algorithm becomes essential. As to why this is needed, we will look at it as we proceed with this webinar.
So we move on to partitioning the control algorithm in the model as per our requirements. Once the partitioning is done and we are happy with the simulation results, we can move to generate code from the model itself. This will be finally deployed onto the device which we are targeting.
Thus, we can see that with the help of these steps, we can basically build an algorithm, deploy it onto a hardware, and get our motor spinning quickly. And all this without leaving the MathWorks environment. And the best part is that we do not have to be C or HDL coding experts to get this done.
So now that we have some idea on the steps involved, let's have a quick sneak peek of where we will end up at. So here's a video wherein you can see your motor spinning, your motor currents, and your motor speed feedback. So this is the motor which we would be using. And as sen, it's on no load. So we would be looking at that from the speed control perspective.
So now we are talking about the permanent magnet synchronous motor which would be controlled with the help of field-oriented control. And we would be looking at it from the speed control perspective. So we would be subjecting the motor to step changes in speed command. And from the results, it is clear that we have good response in both forward as well as reverse directions.
Now looking at the results, many of us would have a question. So is there a simplified workflow wherein we can build an algorithm in Simulink and get the motor spinning as shown? And that's exactly what we will be looking with the rest of this webinar.
So here is a simplified workflow when it comes to motor control development process, which is basically an extension of the steps which we went through with the overview. So as seen, this begins with calibration of sensors and ends deployment and validation-- exactly what we were looking for.
So we begin by calibrating our sensors so that we have the right signals measured. We then move on to identify our motor parameters, which would be used to model our motor and build our control algorithm. We can further work on fine-tuning our control algorithms on basis of our requirements.
Now, once the simulation is done and we are happy with the results, we can proceed to generate C as well as HDL codes from the model itself. This would be deployed on the device which we are targeting to test the algorithm against a real hardware.
So you can try out this workflow with Motor Control Blockset, which is an add-on to Simulink. So Motor Control Blockset basically simplifies the workflow by providing prebuilt control blocks used in motor control algorithm development.
And yes, these blocks are optimized for code generation. The library also includes sensor decoders and observers, which would be used in your sensor based and sensorless motor control applications.
In addition, there are features like motor parameter estimation and controller auto tuning capability included. And before we proceed further, let's have a look at the Motor Control Blockset library.
So here's the Motor Control Blockset library, wherein you can see different categories like controls, sensor decoder, sensorless estimators. And yes, the blocks are basically built to give you optimized code and are MISRA C compliant, as well.
With the 22B release, we have Motor Control Blockset HDL support algorithm, which has similar categories like the controls has controllers to math transforms like Clarke, Park And yes, this is basically developed to provide you with optimized HDL code.
And on top of this, the Motor Control Blockset provides you with multiple pre-built fully assembled reference examples, like the one which we are covering today to basically minimize the development time.
So there are reference examples covering deployment to many popular hardware kits with this add-on product. To know more, please explore the Motor Control Blockset product page. This reference example, which we are covering today, is available with the 22B release. And we will focus on the design and deployment part with this example.
When we are talking about deployment, let's have a look at what are the digital technologies which engineers are exploring to implement their algorithms. So the most popular choice right now with most of us is DSPs or Digital Signal Processors, which are programmed with C codes, which most of us are comfortable with. And hence, it's easier to design and modify.
And with C being a sequential programming language, debugging also comes easier. But yes, DSPs have fixed microarchitecture with fixed number of blocks and less number of IOs. And they also lack parallel capability which adds in to delays and in turn limits the sampling capabilities or timing performance.
This is where FPGAs or field programmable gate arrays came in with their flexibility to reconfigure hardware architecture, higher number of IOs, which help in applications like multi-level converters, and it also has large-scale parallel processing And thus, when the delay is gone, we get fastest loop rates.
Now, FPGAs are programmed with hardware-descriptive languages like VHDL or Verilog. And as someone who has worked on VHDL coding, I definitely felt it has a steeper learning curve as compared to C. Basically, since it's more difficult to visualize and troubleshoot, which makes it more challenging.
And yes, there are lesser ADC's and size constraints, too, which come into picture. Hence, optimization is of more essence for FPGAs because of the huge cost difference between the two technologies.
Now, you might be wondering why even with the higher cost and challenging designs, engineers are considering FPGAs? And why specifically for motor control applications?
So now when we are talking about motor control, you are aware that there are advanced algorithms involved with higher computation efforts, like field-oriented control in itself. Or else think about estimating the speed on top of this in sensorless control.
Further, there are cases where we need quick sampling, when we need to detect and take decisions, like in case of fault predictions or conditional monitoring scenarios, or further computation-intensive control algorithms, like multi-axis control for drones. So as we saw with digital signal processors, this becomes difficult.
And taking into account all of this, you may then have to settle for slower loop rates and thus sacrifice a controlled performance. Since this isn't one of the compromises we as engineers are happy to make, we started to look for more solutions. And this is how exactly FPGAs came into picture. Like now, many researchers and industrial applications have proved FPGAs are a good solution in such cases.
Another reason for this to happen is that engineers are always in search to attain higher energy efficiency. And for this, they are trying to replace the conventional semiconductors with wide bandgap devices. So wide bandgap devices like silicon carbide and gallium nitride are now, kind of the next step towards energy efficiency.
And again, with wide bandgap devices, we are looking at higher switching frequencies, higher loop rates. And this, again, brings us back to FPGAs. FPGAs, as discussed, with its parallel processing capabilities can shorten the computational time to a large extent which results in lower control delays and better dynamic performance. And hence, this definitely stands out as a better solution.
But we still have the cost problem to think about. And that makes us think. Is every portion of our algorithm complex, and does every portion of our algorithm require higher bandwidth? And the answer is definitely no. So is there a better solution?
And that's exactly where SoC FPGAs came into picture. Combining the capabilities of a processor and an FPGA, as seen, it's a single chip with both processor and an FPGA integrated into it. So now we have best of both worlds, wherein we have a IOs, ADCs, parallel processing capability, and all at a lesser cost than an FPGA. So yes, we are happy with this combination.
But we still have some pain points with this device too. So let's move on to look at the challenges which we face when we are thinking about implementing algorithms on an SoC-based FPGA.
To support this, we need to have a more detailed look at the device. So as discussed, we have a good number of configurable IOs. We have an ARM processor integrated on the device along with an FPGA fabric.
So since one portion is ARM processor, we are happy working on it with C code. But the other half is still FPGA fabric with HDL code, which many of us are not comfortable with. But before we go to generating codes, what does the setup itself tell us?
So as we see, we now need to work on two different architectures which are integrated on one chip. With that comes the first challenge as to identify which portion of the algorithm runs where and partitioning the algorithm accordingly. And yes, we definitely do not want them to be working isolated to each other. So partitioning is not the last problem.
What about communication between these parts? And hence, the second question rises up. Now this becomes complicated, as now we are not just talking about working on an individual processor or an FPGA. But now we need to think about how we can work with both of them, sync them up, and pass the information between them as needed.
But in other words, how do we set up AXI, or advanced extensible interface to do this? And I know these problems look complicated. And here's exactly where MathWorks products come to your help.
So with MathWorks products, you can not only work on simulating the algorithm to meet your requirements, but you can also auto-generate the C and HDL codes along with setting up your AXI stream for the communication between the processor and the FPGA.
And all of this is done as discussed without leaving the MathWorks environment and with minimum programming knowledge. So this definitely helps you to focus more of your time on getting control algorithm right, by giving you more time to fully test and optimize the controls further.
And that's exactly what Punch Powertrain did .So Punch Powertrain is a company specializing in electric and hybrid powertrains for consumer vehicles. So they were looking to work on a no magnet motor. And accordingly, they chose switch reluctance motors as the motor to work with.
So switch reluctance motors in general have higher torque ripple and are generally noisier in comparison. And when we are talking about consumer vehicles, we know that this needs to be minimal.
So to counter these issues, they planned to work on a new direct torque control algorithm, wherein they saw that the complexity was increasing. And there was a need to run these algorithms faster. And from the initial test, they were able to identify that even one microsecond of delay would cause an error up to eight amperes. And hence, there was a need to improve their sampling time along with the need for heavier computation.
So on similar lines to what we have seen with this webinar so far, they decided to work on Xilinx Zynq SoC to make this happen. But the engineers had limited or no prior experience with FPGAs. Now, this is definitely challenging to do, especially within a short time. Because of the lack of expertise with FPGA and HDL code. But using MathWorks products, they were actually able to complete and deliver the project within 18 months.
You can go through their journey with the help of this link provided. I think we all agree when I say that that's a perfect example for the workflow which we are discussing today in this webinar. And with that, let's have a look at how we can get our motor spinning using Model-Based Design with Simulink along with HDL coder and Embedded coder.
So we begin by building our model which comprises of the physical system that is the motor and inverter along with the control algorithm, which as seen is built using C as well as HDL-compatible blocks.
Now when we are talking about control algorithms, we need to decide how to partition it, as in which portion of the algorithm would be running on the FPGA and which on the ARM processor. These would be then grouped into separate subsystems on basis of this as shown. So let's dive deeper into how this is done by understanding field-oriented control and its requirements.
So field-oriented control or vector control is a technique used to control motors like PMSM as it provides good control capability over the full torque and speed ranges. In the speed control mode, which is the topic of discussion today, as seen, the outer velocity controller follows a reference speed value and generates a current reference for the current controller which forms the inner subsystem.
So for a field-oriented control algorithm, the inner current control group needs to run at a high rate, typically microseconds. Whereas the velocity controller must react to external events such as the speed command as shown and hence can run at lower rates, typically milliseconds.
Now that we know about our requirements, we can proceed to partitioning. And this is the structure of the partitioning scheme. As seen, the fast current controller is running on the FPGA, whereas this slow velocity controller is running on the processor. Thus, both control loops in field-oriented control algorithm can meet their requirements with this partitioning scheme.
Now that the partitioning is done, we can proceed with the simulation to gather our needed results. And once we are happy with the results, we can move to prototyping. And we begin this with HDL code generation for the FPGA fabric, which generates an IP core.
So if we consider a graphical description where the orange portion is the part of the algorithm to be deployed onto the FPGA fabric and the blue one is for the ARM processor, then this process basically generates the HDL code for the orange portion. And in addition, it also includes the AXI interface codes so that the IP code would be connected to the ARM processor.
And all this is done using HDL Coder. Now we can insert this IP core into a larger reference design of the device which we are targeting and build a bitstream, which would be deployed onto the FPGA fabric of the SoC device which we are targeting, as shown.
So now that's done, let's move on to software interface model generation. So what's a software interface model? As seen, it is quite similar to the model which we started with. But the HDL portion of this is replaced with an equivalent auto-generated AXI driver block. So now, where can this model be utilized?
Once your program is done, we can further fine-tune our algorithm on basis of how it's running on the hardware. So this is done using the external mode feature. This is exactly where we can use this model, wherein the HDL portion is replaced with equivalent auto-generated AXI blocks as shown.
Now, with this model and Embedded Coder, you can auto generate the C code and run the executable under Linux on the ARM processor. Now, the ARM processor of the SoC is linked by ethernet to the host computer on which the Simulink model is. And this is thus, useful for real-time tuning. So now we know how exactly the workflow works. But we do not need to write down these steps to follow them, as all these steps are part of the HDL workflow advisor.
So the HDL workflow advisor basically facilitates you to generate HDL code and get them deployed onto the FPGA using these set of steps. We will go through these steps and use them with the HDL workflow advisor for today's demonstration. Now that we have gone through the entire workflow, let's have a look at the development kit, which we would be using to illustrate this workflow.
So we will be using the trends electronic motor control development kit. And it comprises of the SoC module, which is the Xilinx Zynq UltraScale version. And along with it, there's a carrier board as well as a motor driver module. And it also includes a 53 Watt, 24 volt, 4,000 RPM permanent magnet synchronous motor, with 1,250 counts per revolution encoder included.
So now that you're done with the workflow, and we know that we will be using this development kit to illustrate the workflow, let's move on to the demonstration.
And we begin this by exploring the simulation model. So here is the simulation model. And this is a top-level model which serves as a test bench. And as seen, it includes system input as well as subsystems like controller algorithm and motor and load
So the system input basically provides inputs like speed command of the motor as well as inputs to the mode scheduler. So mode scheduler basically dictates whether the motor should be running or not. And when it is running, should it be running in the open loop mode, or calibration of encoder mode, or in the velocity controlled mode, which is the closed loop mode of operation.
We can view the signals here. And with that, let's run the simulation so that we can view the results and understand the mode of operation a little bit more. So we begin with calibration of encoder.
And we can also view our motor speed feedback, as well as our motor currents here. And as seen, the mode of operation changed to the velocity control mode. And here we can see that the speed feedback is tracking the speed command.
So while the simulation is running, let's have a look at the subsystems. And we begin this by exploring the controller algorithm subsystem. So this subsystem is where we can see how the control algorithm is partitioned. So if we remember, the control algorithm would be partitioned into subsystems on basis of where it will be deployed on the SoC.
So the outer speed controller would be deployed on the ARM processor. And the inner current controller would be deployed on the FPGA fabric. So here, we can see that on similar lines the outer velocity controller as well as mode scheduler is deployed onto the ARM processor. And it's implemented using a state flow chart. Whereas the inner current controller would be deployed onto the FPGA fabric.
So let's move on and look at the last but not the least subsystem. That is the motor and load subsystem. So here we have a mathematical model of the surface mount permanent magnet synchronous motor. Along with it, there's an inverter as well as all the signals which we would be measuring.
So let's have a look at the simulation results now. So from the results, we can see that our motor speed is tracking the speed command perfectly throughout. So yes, we have completed our desktop simulation with this test bench and are happy with the response. So now the next question is, how do we generate C and HDL code from this model and get it deployed onto the SoC?
So for this, we will have to look at the project in more detail. Now let's have a look at the project, that is the Simulink project for this demo, which we are looking at so. It has this plus task folder, which has a set of scripts to basically automate the various activities that needs to be carried out.
And now that you are done with the simulation of the test bench model, let's move on to generating C code by running this script. And as you see, it pops up the state flow model and starts building the code. And in a matter of a few seconds, you basically have your code generated, which is readable as well as portable ANSI code. And you have your code generation reports along with it.
Now, as we discussed, we will be using the HDL Workflow Advisor. So here's the script to basically open up the HDL Workflow Advisor. And I'm just running it. So we can see the HDL Workflow Advisor has popped up. And as we remember, it basically goes over a series of tasks to help to generate HDL code. And that's what we will be exploring now with this demonstration.
So the first step is setting the target. And if you remember, for the HDL code, we would be generating an IP code. So we select that. And the target platform which we'll be focusing on is the Trenz TE0820 kit. And the synthesis tool is Xilinx Vivado And the version is 2020.2.
Now, with the Vivado reference design, it basically contains the base of the hardware kit, like the ADC, the encoder, and the PWM components. And the IP code, which is generated, would be then integrated into this larger reference design.
So now let's run this first step. So now that it's run, we can move to the set target interface. And in that, we can see that the port names as well as the data types are all set from the model because HDL code is generated basically from the model. And the target interface platform basically gives you the interfaces which we have with the reference design.
And we basically will follow the steps and the process by the advisor to check the model compatibility and model settings next. And then we could finally move into the HDL code generation part and with the section 3.2 we can generate HDL code, wherein we finally get our HDL code as well as the HDL code generation report. So let's have a look at that.
And finally, the HDL code is generated. And we have the code generation report. And here we have the IP core generation report. So if we go through the report we can again see the port names, the data type, which is similar to what we saw from model as well as the target interface.
And we can have a look at the VHDL, which was being generated from this. And as you see, this is VHDL code generated for inverse clarke transform. And it's traceable as well. So once we can go from the code to the model. And that's what helps us during the debugging process.
Now, going back to the HDL workflow advisor, we still have a last step, which is the embedded system integration, which is basically used to finally deploy our codes to our target hardware. So herein we have the software interface module generation as well as building the FPGA bitstream to be finally deployed onto the target.
And once you run these tasks, as seen, you get the AXI interface portion, which is the auto-generated portion, which would be used to replace the HDL portion for the software interface module generation.
And this is the model which we were talking about. And it is called a FOC Zynq Arm deployment. And as you see, it is quite similar to the model which we began with that is the test bench model. The only difference is that the FPGA portion of the algorithm is now replaced with the equivalent auto-generated AXI interface block, which we saw. And this model can be used to basically further tune your algorithm on basis of how it operates on your hardware.
So with this model, you can basically compare your test results with your simulation results. And that's exactly what we are going to look at with the help of a video. So this is the video, which we were talking about.
And we begin by clicking monitor and tune. So this connects the simulation model with the hardware, which we are targeting. And once connected, it starts running your model. And you can see your actual motor spinning as well as your motor currents and motor speed feedback.
You can also use the Data Inspector to view these results. So this is the Data Inspector. And as you see, you can basically select the signals which you want to view or compare. We chose the controller mode to basically understand which mode the system is in. You can also compare the simulation's speed with your actual motor's speed, and also your actual motor currents with the simulation currents.
So from these results, it is clear that our test results and simulation results match in the closed loop mode. The difference which we see in the calibration of encoder mode is basically because of the difference in the initial position.
So since the initial position is different for the actual motor and the simulated one we have some difference in this mode of operation. But as seen, the closed loop mode of operation is exactly according to our requirements.
With that we have come to the end of this demonstration. Now that we know how Model-Based design can help us with our projects, I'm sure we would all use Model-Based design for our next projects.
So before we close it today, let's have a quick recap. So we begin with simulation, wherein we saw that we can also partition the control algorithm in the model according to our requirements. We proceeded to generate code from the model. And again, we saw that we can generate both optimized C as well as HDL code from the model.
And finally, this was deployed into the hardware, which we're targeting to get our motor spinning. And all of this was done with the help of the reference example from Motor Control Blockset with which we began with. So definitely a good way to get started with.
Now, what's next? Did you know that this reference example also has a floating point period for the HDL portion? Explore the documentation for this reference, example, to gain more such insights.
And yes, do check out our solutions page. To know more about our capabilities for power electronic projects, ranging from battery management, to power conversion, and definitely more on motor control.
You can further explore articles and tutorials to kickstart your journey on FPGA and this workflow. Download the pdf of this presentation to get direct links to all these materials. Thank you for joining this webinar. Thank you.