Improving PWM Resolution for Real-Time Power Electronics

Hello, everyone and welcome to the webinar, "Improving Resolution for Real-time Simulation," or as I like to call it, "Real-time Simulation for Wide-bandgap Devices," because that's typically when you need this type of modeling approach. My name is Joel Van Sickle. I'm an application engineer at MathWorks. Specifically, I work out of the Detroit area. I do a lot with our automotive customers.

But in general, support the Simscape electrical products and any of our electrical-focused real-time activities, both here in the US, but I also provide international support for those who are doing that type of work as well. We are going to be talking fairly specifically about simulating higher-switching frequency systems, so that's going to be 50 kilohertz and up, and what you need to do to accurately simulate a system like this in real time.

We are assuming that you already know what hardware in the loop testing is, that you're aware of what real-time simulations are, so we're not really going over any of that. We're really going straight into this more advanced modeling technique and how you can utilize it for your own simulation needs.

The example we're going to go over is a buck converter. We have much more interesting models for actual product demos using this exact same technology, so specifically Speedgoat has a webinar up already where we go and do a grid-tied inverter that can support these higher-switching frequencies. And there will also be material similar for traction motors and other more complex topologies.

But the one we're going to look at for today is it' a buck converter using a half bridge, so it's a synchronous buck converter. And the lovely thing about this buck converter is that it takes two gate signals in, they're a vector on this line, and then I have my current output through the inductor.

And I have my voltage measurement across my load, and that's four signals. And my oscilloscope that I have in my home grown lab has four channels. So this is the perfect example where I can show you everything that's going on simultaneously.

So that's what we're going to do. And I've got a video here where we can see what's going on. You can see the system behind me, but you can't see it very well. So this video is going to be much more useful. So this is not a Speedgoat system. And I've already got it running. It's running in steady states.

So I'm going to pause this video and quickly explain what's going on. So this is the capacitor voltage. You're not going to see much from it other than its magnitude changing when the duty cycle gets lowered. Here we've got the inductor current.

And this is where you can really see that this is a digital system because you can see every microsecond, the inductor current gets updated, because that's what I'm running my DACs at on my Speedgoat system. This is-- you can see this is a five microsecond division right here. And so we're updating that DAC every microsecond.

So that's the resolution of the peripherals on our real-time system. So that's what we're updating at, and our switching frequency is 50 kilohertz. So that's here. We've got switch 1 and switch 2, or upper or lower switch, whatever you like to call them. But that's what's going on there.

And so in this video, one of the first things we're going to do is change the duty cycle. And then after we change the duty cycle, we're actually going to increase the switching frequency and see how this model responds to faster switching frequencies.

But before we do that, let's lower the duty cycle. So I'm going to drop that. You can see the capacitor voltage drops. The inductor current changes. That's what's expected. But now we can go and we can also change with the switching frequencies. And you can see we're still capturing the ripple of that inductor current. But as the switching frequency gets closer to 500 megahertz, the ripple goes away and we get an average signal.

Now there's not really anything we can do about that because at 500 kilohertz and above, when we're only updating at one microsecond, we can't actually output the harmonics of that signal, but we can still output what the average value is. And so it's an interesting feature of these models in that you can actually use them to these very high switching frequencies should you need to.

You just have to be aware of once you're going close to your peripheral's update rate and your simulation time-step, you're going to be getting average values as opposed to the switching harmonics. But even that can still be useful because, especially at these higher switching frequencies, you're not necessarily sampling for your controller anywhere near that rate. I apologize to certain DC-to-DC converter and resident converter designers who vehemently disagree with what I just said.

So that's really how to do that. How the model accomplishes that kind of behavior and whether that's actually accurate behavior is what we're going to be talking about today, and we're going to do it by answering four questions. The first question is, why do we need faster real-time simulations?

Second question is, what is the difference between PWM resolution and simulation time step? So this one is important because for some people this difference is obvious, and for other people, it's just never come up that there should be a difference in their models between simulation time step and PWM resolution, because they're often lockstep in a simulation environment.

That discussion leads to a need for solutions to the problem to decouple those. and that of those solutions is called sub-cycle averaging. So we're going to talk about that. And then we're going to talk about how that can be used to build real-time simulations.

So why do we need faster real-time simulations? Well, CPU-based techniques, they were and are great for certain applications. There are certain systems, whether you're taking advantage of average models or there's high enough impedance in them, CPUs are great for the time steps required. And if you can use the CPU, you might as well use the CPU, but very large models on CPUs that you just can't run them as fast.

Simple FPGA techniques have been good for the 10 kilohertz switching range. I'm specifically saying simple FPGA techniques. You can optimize your models and you can use more advanced solver techniques to get beyond that. And that's one of the ways we're going to do that-- we're going to talk about.

But the simplest approach, you're around 10, 20 kilohertz, which worked great for a lot of silicon devices like IGBTs because you typically didn't want to switch them faster than 20 kilohertz anyway. But we have wide-bandgap devices now, and even with packaging and some of our silicon devices, the reality is we're pushing the switching frequencies.

And again, certain resonant converters and certain DC converter designers, they've been so past 50 kilohertz for so long that they would laugh at such a slow switching frequency. But one of the issues is that FPGAs haven't gotten much faster recently. Some of them have gotten bigger, that's for sure. You have a lot more logic gates you can use.

But their clock frequency hasn't really changed, so we can't really just take simple approaches and run them faster. We have to use more advanced approaches and optimize the models if we want to get better performance out of them. And so that's really what we're going to have to look at.

But before we look at some of the more advanced techniques, let's make sure we understand what the old technique was, this simple approach I mentioned that was great for 10 kilohertz. And so what happens when you have power electronics in your model, you can turn it on, you can turn it off. And that's all you got. It's on/off control.

So for those of us who do control and power electronics, all of our control information is in the timing of those PWM signals. It's critical when we turn them on, when we turn them off, how that relates to the other switches in the topology-- that's everything to us. So it's really important you capture when the signal turns on and when the signal turns off.

And so the easy way to do that is to just take a lot of slices and run your model at every division. So you read in your PWM signals. You simulate your model response to those PWM signals. You calculate your outputs You update your output. And then you rinse and repeat and do this over and over and over again.

If your model execution time is small enough that you get a lot of slivers per PWM signal, typically 50 to 100 for simple applications, that would work. And then the beauty of if this works, it means you can use completely standard solver techniques. It works regardless of number, PWM signals. It works regardless of number of switches, with the caveat that those additional devices aren't slowing the simulation down to the point where you aren't getting that PWM resolution.

And this is the issue that your PWM resolution is the exact same as your simulation time step with this type of paradigm. And that's going to be problematic because as the model simulation time increases, your PWM resolution gets worse. And what happens when your PWM resolution gets worse? Well, let's look at an exacerbated example of that.

So here our execution time has gotten so long, we only get two samples per cycle. That's not very good. So what are we going-- what's going to happen? Well, in the real world, if we apply this PWM signal, this orange signal could be what our inductor current is going to be. But in the simulated world of our virtual real-time simulation, when we're sampling, it's going to have us detect our edges here.

And so we're going to-- this green square is going to be what we simulate happens. And in red is going to be our simulated system response, which is very different from the correct response in gray. So this is what happens when you don't have an accurate enough PWM signal. Now a little bit of inaccuracy in your PWM signal can be compensated for by your closed loop controller, such that it's still very useful for testing.

But every power electronics converter has a certain PWM resolution where it will no longer be able to accurately control the system it's hooked up to. And so that makes PWM resolution incredibly important for your controller-- or sorry, your real-time system, working such that your controller can be tested on it.

But please note something. That PWM resolution is really important because we care a lot about the width and the timing of these PWM signals. The actual dynamics of the inductor current-- now granted, the dynamics of the current through a buck converter's inductor are pretty boring. So like the ripple on the capacitor is going to have a bit more dynamics to it, need a couple more data points than a straight line will.

But you don't need hundreds of data points to recreate the harmonics per cycle. 4 to 10 data points could be good enough to capture the harmonics pretty well, depending on your controller. But that's going to be nowhere near enough to capture your PWM wave accurately. So we really need to decouple time step and PWM resolution.

And so that brings us down to what is the difference between PWM resolution and simulation time step. Well, PWM resolution is how accurately can you measure the width of the PWM signal. Simulation time step is how often are you actually updating your model states. As I mentioned, in this simple approach where you just subdivide everything and synchronize them all, your PWM resolution and your time step are the exact same.

As mentioned, that's problematic, so we need to do something differently. We need something that lets us detect when these edges happen and calculate model updates. So your first thought might be like, well, we could just have something that's interrupt-driven, and whenever we detect this edge, we could calculate our model updates. It's like, OK, that could work.

But then one issue is, well, you never know when those edges are going to happen. So you could have really small PWM signals, so you're not going to be able to update before the next interrupt happens. And so maybe you build a system that can handle simultaneous interrupts. But then you have to think, well, I'm going to have multiple PWM signals and they're all going to have different interrupts.

And then you have to support two parallel interrupts per PWM signal. And then how do you actually calculate your state outputs and merge them all together in your solver. And that approach becomes a disaster. So an interrupt-driven approach isn't really going to work for us in a way that scales well. But it's a good way of thinking. It's getting somewhere closer.

But what we could do is we could schedule consistent model update times, but we could be polling the problem signal at a much faster rate. And this is easy, because for an FPGA, checking a TTL line to see if it's high or low is basically a free operation. It doesn't cost you anything, whereas checking that signal on a CPU actually is kind of complicated in what's going on.

For an FPGA, it's about as simple as it gets. And so you can do that at whatever the rate of your FPGA could be. So in a lot of these, there are Kintex-7 325Ks on most of your real-time hardware. They can sample at least between 5 and 20 nanoseconds, so that's pretty good resolution.

And then separately, when these thicker black lines happen, that's when you can update your model states. So you can capture when these edges happen, but you have a consistent time frame for when you can update your states.

However, there's still a problem in that how do you actually calculate the correct response, even though you know these times. And there's a couple different approaches for how you could do this. But one approach that can work particularly well, in scale as well, is called sub-cycle averaging. And it's going to take into account we're looking at the switching devices.

And they have a current and a voltage across them. And they're connected to predominantly linear devices, so inductors, capacitors, resistors, that kind of stuff. And what this means is that superposition actually works really well, averaging techniques work really well.

And so there's some mathematical tricks we can play that let us take these signals and use them in a model in a very useful way that gives us an accurate resolution-- PWM resolution, that is. So let's look at this a bit more.

Let's say we have this single PWM cycle. For the switch being off, there's going to be a certain dynamic voltage. So this voltage is not some constant voltage from a lookup table. This is actually the dynamic voltage calculated from the circuit as if the switch was closed-- sorry, open. Similarly, there's a voltage that would be across it when it's closed.

And there's the currents. And these can all be calculated. Now the nice thing is because we're on an FPGA, we can do these calculations simultaneously. And because of superposition, what we can do is we calculate them both simultaneously, and then when we know what the ratio of on and off is, we can essentially average them together. This is very similar to how you build average models.

And you would basically get the equivalent of this green signal being your duty cycle, because you're no longer simulating a switch on or off. You're simulating the switch being on or off for a certain percentage of time. Now when you're in these zones, you're just going to simulate the switch being on or the switch being off. So you are simulating the dynamics of individual switches.

But you're using this technique to give you a way to capture these transition edges so that the correct amount of energy is still flowing through your converter. And because you get the energy correct because it's flowing into these linear components, you're still going to get the correct response as far as ripple magnitude and dynamics and all that.

And the other nice thing about this is it scales up to more complicated topologies. Because one of the problems is you can't look at every switch and just look as a duty cycle. You have to know if certain switches were on or off at the same time.

Now this does make the approach more complicated. But that same table can have multiple switches in it so you can do the calculations for different permutations. And instead of doing a duty cycle for one switch and another switch, you're actually tracking what's the ratio for them both being off, what's the ratio for S1 being on, what's the ratio for S2 being on, and do they ever fault out.

And because if this ever happens, your system shorts. It's a bad time. And so you can do this, theoretically, for any size topology where the switches interact with each other. But as soon as that converter is hooked up to-- whether it's an inductor, capacitor, or something that isolates it from other converters, you can essentially split them and treat them separately.

Because, especially if you've got inductor in between them, you're no longer just going to be shorting directly through them. The circuit simulator will capture the current from one topology to the next one and give you the right results. So this is a really powerful technique that lets you get these simulations that decouple your PWM frequency from your model time step.

And now, I don't expect you to believe me. So what we have here, where I showed you that model, I've actually got-- it's the buck converter, the synchronous buck converter. I've got it on one side running in continuous mode, and the other side running in discontinuous mode.

So actually I'm not actually running it as a synchronous converter here. I'm basically running as a standard buck converter. I'm not turning this bottom switch on to get that effect. And to be clear, and I've already run this, but you can compare the results.

And so this is compared to continuous time, variable step simulation. So as accurate as we can simulate in yellow and our sub-cycle discrete model in blue. And you see that's really good matching for our highest fidelity model. It's not perfect, but it's definitely good enough for testing your control system. Sorry about that.

And similarly, you can do it for discontinuous mode. Now discontinuous mode is going to be a little less accurate, especially when you have fewer time steps per cycle because the dynamics are a little bit more complicated. So you are taking into account-- it's barely discontinuous, unfortunately, I really should have done something a bit more exacerbated.

But you can see it is pretty closely tracking those devices. But you do need to look at discontinuous mode and validate that it's going to be accurate because it is more sensitive to the model time step. So basically, as you increase your model time step, this would get more accurate. Whereas if you're in continuous mode, it's practically dead on up until you hit average mode.

And so that's just making you aware of what you can do with these types of approaches. These models, these sub-cycle average models are actually implemented in Simulink. They are white box. We can share these. You just need a Simscape license. You don't even need Simscape Electrical.

And you can go in and you can see the math that's going on, the logic that's going on, the rate transitions, and all of that, if that sort of stuff interests you. But you don't actually need to know what's going on, because you can just use it in your Simscape model as if it were a Simscape model, which is the whole point of this.

So when you have a model like this, you can now generate something that will be useful real-time for much higher switching frequencies. And the way you do that is we have a script here that walks you through the process of what you need to do. So first, I need to have a model that I'm going to take through the system.

So I have this model here. So I'm going to run and advance this section, get that loaded up. And then let me pull up that model. And we'll show you what we're going to actually generate HDL from and put on a real-time system. So you can see it here in the background. It's going to pull up this advisor in front of me, so I'm going to close that.

So here is again it's just a buck converter inside this system. It's a half bridge model, actually. Here I have a controlled voltage source, so I can do different voltages in. I actually apply-- instead of doing a current mode like I normally do, I put in a voltage load here. It makes it easier for me to control whether it's going-- the power's going in or out. And the standard, my inductor, my capacitor.

So again, this is very simple. You want something more complicated, we can show you that on some of the other webinars or on a call. But we want to take this and make it deploy to a Speedgoat. So let me go back here. Well, actually, it's already opened up the wizard for me. So this is the Simscape HDL workflow advisor.

So I could go through this one by one, but I really can just click "Run all." because I've already done this, so there shouldn't be any kinks while I'm doing this. Cross your fingers. This extract equation parts is what takes the longest because it's actually looking at the model and creating state-space matrices of it. But it's already done.

And that's going to generate this implementation model. And this implementation model is taking your Simscape network that was-- you actually had a schematic, and it's taking that and it's replacing it with a state-space equivalent of it. So we had a Simscape model. It's gone. And instead, I've got this system, which underneath the hood it's just a state-space model.

And then here, it's taken all of my Simulink and stitched it back in like it was connected to the Simscape model. So I've got my sub-cycle averaging topology in here, still connected to everything. By default, it leaves anything I've put in there. So it's got-- I've got some extraneous blocks that maybe I don't want.

So what I'm going to do is-- first, all of this stuff gets put in two different subdirectories that aren't necessarily obvious. So here there's some subdirectories that this stuff is being put into, and I'd rather have it come out to my working directory. So this script will take care of that for me. So I can move my models to my current directory. So I'll run that task.

And then if I go back to MATLAB, now what it's done is it's taken those state-space parameters, and it's taken the state-space model, and it's moved them out here. It's left a copy in the old place. And it's especially safe for me to do whatever I want to them. And we had those extraneous blocks in there. So let's just delete those so that it's just clean sections.

And this will give me a model that is now ready to go for HDL code generation. So this subsystem is good to go for HDL code generation, but I probably want to add interfaces to it. And so my recommendation for that is you leave this block untouched, because everything I've done up to this point I haven't had to manually adjust.

I can just use this script to clean everything up. So there's a function here that lets you update that specifically. Let's say I changed my Simscape model. I want to update all this. This destination will update that automatically. But then anything I do outside-- so I can add interfaces here, and that will go unchanged.

And so basically, you want to have the subsystem that has your auto-generated system in it. Don't touch the insides of that, but do whatever you want outside of it. And so I've created a model. Let's navigate it, under demos, where-- here we go. This. I have a tendency to call my systems wrappers for what's going to generate the HDL.

So in here I have that subsystem which I haven't modified, but I've added some interfaces. So it's pretty simplistic for this because I'm not doing much, but I have my sensor interface. So I'm defining what my max input is. So 100 volts to negative-- sorry, 100 amps to negative 100 amps will change to 10 to the negative 10 volts for my DAC.

And there's a couple of different options for the Speedgoat, but I just wanted to do something simple like that. It worked out as far as being visible on the oscilloscope. Another thing I did is this. If you remember, I demonstrated a variable switching frequency.

I don't have an embedded system that can do that. So I built my own variable frequency PWM generator. And I stuck that on the same FPGA and I just outputted signals to two TTL lines. And then I also let myself directly route it in here, so I can use either external signals or I can map this directly, for instance, if I don't happen to have wires. And that's what's going on in here.

This is just a little logic that lets me control the rate at which my DAC updates. So I can actually have changed my DAC to update at a slower rate. I don't really know why I would ever do that, now that it can, but I have that option.

And so at this top level, I can generate HDL from this model. Once you generate HDL from it, you will get a bitstream. And so I've saved that as my Speedgoat model. And it's pretty much the same model, only now you can see here I've got this, basically, Speedgoat I/O module system.

This has the bitstream. This will get loaded onto the Speedgoat FPGA. Everything else you see is executed on the CPU. This is interesting because I'm using the new operating system for Speedgoat. This is how you measure your execution time. You bring this block in, and you put a little scope block on it. So that's good to know because that's newer.

But everything else is standard Speedgoat approach. And I can-- this is also new, for the update to the operating system, is I open Simulink Real-time Explorer. I pick my system. I connect to it. And so I've already built this system, because that usually is a waste of time to watch me.

I mean, it only takes three or four minutes, but you don't want to sit here for three or four minutes while I build a system. You want to sit here for three or four minutes while I wait for my Speedgoat-- Oh. I have limited USB ports. Sorry about that. I needed to plug-in my ethernet adapter. I needed to have my headphones in because my other mic doesn't work. There we go. Let's try it again.

Now that I'm actually connected, there we go. So now it's connected. So you'll be able to see behind me, but I've already loaded this application. You can see it's loaded. But you go to load application and it'll bring up a list of applications you have. So I've got the Speedgoat model. It's already loaded.

So I can hit the Start button. And yeah, you can see the signals pop up on the oscilloscope. Hopefully you can see that behind me. It's just the exact same thing I showed on that video. So I'm going to stop it, shuts down. You don't need to see it again. It's literally just the exact same thing. So that's how it works.

And that really brings us to the end of the presentation. So the conclusion is we can support switching dynamics from 10 to 200 kilohertz with these approaches. It's for specific topologies. It's not for individual switches. Switching at 1 megahertz and above for average models is available. We do have some customers who actually just need average models, but they're switching so high they still need to use an FPGA to implement them.

Something I didn't really talk about, but it's fairly important is this is a hardware-agnostic approach. We prefer to do this on Speedgoat because the workflow is very streamlined and very easy. But the HDL I'm generating will run on pretty much any of the newer, at least moderately-sized FPGAs, Again, like Kintex-7 325K and equivalent-type FPGAs. You can run this on them.

So you can run this on pretty much anything you want. And that's very valuable for people who might have hardware in the loop labs and want to do something like this. But they didn't happen to have a solution for the power electronics. And this gives them a path forward, potentially without having to change the hardware they have in their system.

So the demo I showed you will, at some point, probably be publicly available. Right now it's publicly available as in you can get this if you contact your sales rep. If you don't happen to know who your sales rep is, you can contact me, at least for now.

I don't like to give specific links and locations for this type of content because the reality is it changes from year to year. And this is going to be online. So I don't know if you're watching this live or if you're watching this three years from its release.

So if you're going to search for it, look for MathWorks sub-cycle averaging. But more realistically, find who your sales rep is and please contact them. And if you're watching this live or within the year of it going live, feel free to use the email I have below to try and contact me. And thank you very much for your time.