Bridging the Gap Between PLECS and SPICE

SPICE uses modified nodal analysis (MNA), which leads to differential algebraic equations (DAEs). This is very well-suited to detailed semi-conductor models (a bunch of convergence helpers are used behind the scenes to make the simulation of extreme exponential transients possible).

PLECS, on the other hand, uses ideal switches (on/off) for MOSFETs, diodes, etc. This is, in a way, the "most extreme" form of nonlinearity. But by leaning into it, we can solve more efficiently the resulting circuit equations using far fewer degrees of freedom. PLECS uses a piecewise state-space fomulation (ODEs). A simplified approach like that is basically essential for high-frequency power electronics at system-level if you don't want to wait all day for your waveforms. But obviously the trade-off is that you can't see the switching transients, because they are instantaneous.

To get both type of analyses (zoomed in device-level v.s. multi-physics system-level), we had to build the complex schematics in two different softwares (PLECS and SPICE). This took a long time. It's also quite error prone, especially when complicated initialization or post-processing scripts are involved. With PLECS Spice, we solved our problem. We can build one schematic in PLECS and "spice-ify" the bits we care about within it using a configurable subsystem.

We could call the state-space approach of PLECS quasi-symbolic, because it reduces circuits with linear components to state-space equations. As a result, it needs to solve for much fewer variables. The price to pay is that the obtained system is dense. But for power electronics, this is great, because a tailored implementation of RADAU5 can be used (one of the gold standard for very stiff ODEs). For real-time though, the system has to be built differently with companion models for the swtiches, especially to be able to run it on the FPGA.

On the SPICE side of PLECS Spice, we also perform this kind of reduction for some components if we can, using graph algorithms. For instance, a basic SPICE solver would use a zero voltage source as an ammeter, which adds not only a current variable, but also a nodal voltage because the element has two terminals. Currents can be bad for Newton's method, because they have a very different scale. Often, we can completely avoid this by computing the current from surrounding components. But SPICE is very far from anything real-time.

It was brought to our attention that it would be interesting to have a good interface for ROM models. It seems like POD-based dimensional reduction is widely used in the industry.

On the other hand, PLECS does have clever way to simulate thermal losses from ideal switch models:

https://www.plexim.com/products/plecs/thermal

Since simulation with standard PLECS ideal switches is so much more efficient than SPICE, it allows validation of thermal behavior at system-level.

But PLECS Spice does come in the picture here. What the above technique needs is a LUT table (XML) for the losses, and this can be extracted from SPICE. Now that PLECS Spice is part of PLECS, you can do it in the same tool. The idea is to prepare a simulated test bench for a double pulse test with the detailed SPICE model provided on the semiconductor manufacturer's website.

Then, you can use the data sheet impedance data (or generate the step-response curve yourself from experiment, the finite-elements method, etc) and fit an RC thermal network to it. I built a python tool for that available here:

https://thermal-network.pages.dev/

I wish I had a little more time to improve on the API, but I think it's very convenient. It is also possible to fit impedance data directly in PLECS. Cross-talk for spacial coupling can also be modeled there using similar strategy. The end result is a high accuracy thermal simulation at system-level.

There are some limitations to the approach, and if a full bi-directional coupling is needed (where the energy is taken out of the analog system) you can get more complex behavior by staying within PLECS Spice and modeling the thermal behavior there. It is slower though.

There was a lot of learning and reinventing to do. It started with a team of 1, and we eventually grew to a team 5. We all started working on it more or less fresh out of university. We were trained as mathematicians, physicists and computational science engineers, not electrical engineers. So just that was a journey. Along the way we learned about SPICE, PLECS, power electronics, and how to manage ourselves. In the end, it turned out to be quite a strength to come from the outside and give the field a fresh look.

But there were serious technical challenges too.

- Most circuit simulators use either trap or BDF methods for stepping in time. Most are 2nd order. It has been the case for many decades. We went ahead in the end with modern 3rd order (E)SDIRK (Runge-Kutta) methods. It took a lot of digging, research and trial and error to make that work. But we basically had to, because since we wanted PLECS models to run alongside SPICE circuits as a whole system (just straight up coupling the two formulations together into one set of equations, avoiding the synchronization required by bi-directional coupling strategies or relaxation methods), we needed a memoryless solver that was tough enough to handle the very frequent discontinuities from the ideal switch models of PLECS. To compensate for the implicit steps, we needed to develop a strategy to track convergence rates and reliably bypass Jacobian computations when possible (and inform the convergence detection). The new solver has an embedded error estimator, an optimized PPID stepsize controller, a discontinuity detector and dense interpolation for zero-crossing detection built-in (to handle those ideal switches and discontinuous pulses from system-level power electronics and digital controls). Each components also inform the stepsize control.

- We have implemented condensed MNA to reduce the number of degrees of freedom (from the capacitor currents), and implemented and tested different recent research suggestions from Sandia Labs, e.g. different forms of PCNR for voltage limiting. We had to reinvent convergence helpers (homotopy) that worked with our formulation. And since PLECS was originally designed to solve ODEs, it started with initial conditions, while SPICE typically starts performing an operating point. So we needed there too to invent a graph algorithm that could initialize the combined formulations (MNA + piecewise state-space) consistently in a way that avoids over-determined states.

- A major endeavor was also the netlist parser. It was built from scratch and handles many dialects. Rather than making yet another rigid set of rules and push another syntax to the SPICE world, we wanted a parser that could parse it all, so that most semiconductor manufacturer's netlists could be used. It also comes with a simple netlist editor that gives you line feedback with detailed warnings and errors when something goes wrong.

- Netlists in SPICE aren't full descriptions based on elementary elements. They often assume built-in compact models, which are standardized models of semiconductors like MOSFET, diode, etc., that are parameterized by users (or automatic generation tools). Rather them wrapping existing code, we built them from scratch to be able to optimize and regularize problematic equations. We could improve on the basic compact models and adopted charge-conservative formulations.

Then, there was the UI integration into the PLECS schematic editor, optimization, parallelization etc. Overall, the result is quite a modern take on circuit simulation.

Hello! Haha

Haha, ok fair enough. In the world of system-level integration of power electronics, SPICE is often considered the bottom. There is already a long way from an ideal on/off switch to a SPICE model of a MOSFET with a gate driver featuring 15 000 variables. Especially for a model that wants to include everything like the controls, the converter, the mechanical load, the thermal and magnetics. But I know that IC design go much lower down. I believe I have seen articles from Xyce pushed to many millions of variables and more. I forget the details, but I think I remember seeing an article somewhere for a benchmark of KLU of an integrated circuit with over a billion variables. We are definitely not at such a low level with our tool.