Convert Electrical Plant Models to HDL Code | Simscape Electrical Modeling Practices for Fast Simulation - MATLAB & Simulink
Video length is 13:01

Convert Electrical Plant Models to HDL Code | Simscape Electrical Modeling Practices for Fast Simulation

From the series: Simscape Electrical Modeling Practices for Fast Simulation

In this example, you learn how you can use the linearized switch approximation method to convert a Simscape™ motor model to an HDL implementation model for HDL code generation and synthesis. First, you replace the Simscape switches with linearized equivalents and generate an HDL implementation model. Then, you generate the HDL code and synthesize the results by using the guided steps in the HDL Workflow Advisor. Finally, you can deploy the FPGA bitstream onto a Speedgoat® FPGA I/O module.

Published: 7 May 2024

Hi, everyone, this is Pablo Romero speaking. And I would like to guide you through a demo, a very good example of how to use Simscape to HDL not just to make your electrical simulation go faster, but actually so that you can simulate and test your models containing Simscape switches in real time. For that, I have created this project where you can use different files to go through the example on your own.

To do so, once you start and unzip the project, you can go to Project Shortcuts, and you will find the most relevant shortcuts in this tool strip. You can also check the different folders to go through all the structure of the project. I will start opening the PMSM Inverter Guide, which is the topology that we are using for this demo.

In this live script, you will find all the relevant information, some technical background, as well as all the different commands and steps you have to take so that you can start from desktop simulation, applying different simplification, knowing the trade-offs that you have when you are running or when you are converting Simscape models very much tailored for positions that can be executed faster on FPAs.

We will guide you through the conversion to a state space representation and eventually the HDL code generation and deployment to an FPA. We will start with some desktop simulation. This is something that you can see on the top of the live script because it's essential that we have what we call the golden reference, OK? Every trade-off that we are going to make, every modification in the fidelity of the switches and so on, this needs to be validated with respect to the original model that we have.

This is something that we can do, as you see here. Let me make this a bit larger. And this is our model. Of course, as I said, we can go this step-by-step or run the sections as we need it. For example, if I start with the first model, this is basically a snapshot of the model that we have in Simulink. This represents an inverter-- a two-level inverter with a permanent magnetic synchronous motor you can see on the right side. And we have on the top side of the screen relatively simple control logic based on some field-oriented control.

What we want to do is run this on the FPA so that we will have to generate HDL from the part that I am highlighting on the bottom of the snapshot. We can follow inspecting the Simscape converter. This is something that you see in here. This is the inverter that we have and some mapping of the gates. This is important because we will have the different levels of fidelity so that you can see how we can represent an inverter.

Here it comes-- the model I was opening. Here, we can see the inverter in different levels of fidelity. I have already selected something in this model. But if we go back one step, you can see the different levels of fidelity that we are applying in this live script. It's better to go step-by-step, checking the live script as I'm showing on the screen right now. We have automated as well the simulation so that you can create these reference data, and also plot the most relevant signals of your simulation.

In this case, the inverter currents. We can see the three phases very clearly in here. And that will be the reference. Of course, we can obtain some macroscopic data. For example, how the motor is accelerating. This is something as well we can see for the torque. Eventually, if we zoom in, we can see the current ripple very clearly, which is the consequence of the switches-- the two switches that we have for every phase, right? So this is not perfectly smooth, but it's a consequence of the switches.

Of course, this is something that our control logic, based on the time, based on the switching frequency, this may look different, OK? This is an example. But when we are generating HDL code, when we are running this in real-time on FPAs, we try to capture this effect as well, even when simulating on hardware. So to do so, we need different approaches.

So, for example, the first one that we are trying to do is understand what there is behind this converter block. So at the end, what we have is single switches, right? Here, we have a representation. If we simulate this again, we will obtain the same results than before. Basically, this is what we can find under the mask, to say in some words. The results are identical, as you can see.

However, when we take the first step towards HDL code generation is linearizing the switches using the Pejovic approximation, OK? This is something that has been explained in some papers. And it's a technique that we have captured in our recent documentation, and you can also see in this demo. Basically, we replace every Simscape switch with a certain representation that you can inspect in Simulink.

However, this is the representation I was mentioning that you can inspect. And eventually, we have one variant for the different types of switches that you may have in the model. Eventually, we can simulate this. And you can see that we will obtain the same or very, very similar results depending on some parameters of the Pejovic switch that we will have in the total simulation. At the end, if we convert these to the these dynamic switches, we will see that we capture the-- sorry, we captured the current ripple. So this is the effect that we wanted to retain and is essential for real-time simulation.

Actually, we can convert by superposition the two currents. And we see that the results are almost identical. This is something that, don't forget, you can reproduce on your own just running the different code snippets that you will find in the live script. Eventually, once we have this, we can convert the rest of the Simscape network to a state space representation, which is going to be compatible with automatic HDL code generation.

This is something that you will find documented in here. But, first of all, we take one step back because we are applying Simscape to HDL Workflow Advisor, which is tool that will guide you through the conversion process in the original model. So we will compare what happens if we apply this as it is in our first model, and what happens if we apply the same workflow advisor, but in the model after replacing the Simscape switches with the Pejovic approximation.

So in the first case, we will do that. And after simulating what we have, the standard inputs, we will have a total number of six modes and different combinations of the Simscape network. The more switches we have in our model, the larger our state space representation will be, and therefore the more FPA resources it will require. So that's why it's important that we are conscious about the advantages of applying this simplification, or this linearization, in the Simscape model.

So if we come back to the former desktop model, but we activate the second level of fidelity, or the second implementation based on these linear switches, we will see that now we have a line time invariant, a linear time invariant system, because we have one single mode. So this give us very much optimized state space representation that will be much smaller when we are generating HDL code and deploying to the FPA.

Still, what we get at the end is something that we can simulate and we should validate even before going to the FPA, OK? Our representation, which is the source for the HDL code generation, can also be validated on desktop simulation, as it were the original Simscape network. This is actually, as I said, very much recommended. So here, we have the second model, which represents the original one, but now everything is HDL code capable.

So basically, if we zoom in, we will see that now our FPA representation contains the plot model, of course, so the inverter. And the motors are represented in here, but we have some other subsystems that will help us so that we can, on the one hand, represent-- or deploy this to the FPA, capturing the different signals that we have, like the PWM gate commands, but also other signals that will help us to connect the FPA to the rest of the model that may run on CPU.

This is everything explained in here. As you can see, of course, this is something that you can also reuse for other of your projects. And eventually, if we simulate this, we will have the same results that we had with the model which was made up completely of Simscape switches. We can zoom in, and we will see the same current ripple than before.

And if we add this to this plot, we see that the trade-off that we have done in terms of using Pejovic and converting to the state space representation is still very, very good because we captured the same dynamic effect. And actually, the error is very small when we take the right set of parameters and sample time. Eventually, we can directly generate HDL code from this model. And we will see that our representation, especially when we are comparing to the original one which consists only on Simscape switches, is approximately the same size, but has the half of the critical path.

That means that it will allow us to run the FPA model right approximately twice as fast on the FPA, and therefore has full resolution of the PWM. The same process of validating the model on desktop simulation is something that we should do with the FPA model. In this case, we have replaced the FPA source model with its actual bitstring. This has already been synthesized and it's ready to be deployed to the Speedgoat FPA. This is our preferred solution for real-time. And this is what we are using in this example.

So what you see in here will run on the FPA, whereas the rest will be automatically deployed to the CPU after generating C-code. This is some model that if you have an IO334 available, you can also run and reproduce. This is all about the main model. So if you want to know more about other techniques to keep accelerating further your model, especially your models containing Simscape switches, please don't hesitate to read, to access to this second example that you have where we dive into other techniques, like subsequently averaging.

Thank you very much for your attention. And hope you have enjoyed and learned a few things with my demo. Thank you.