Bridging the Gap Between PLECS and SPICE(erickschulz.dev)
erickschulz.dev
Bridging the Gap Between PLECS and SPICE
https://erickschulz.dev/posts/plecs-spice/
20 comments
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.
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.
Thanks for clarifying. HN is ~generally more software centric, so this context is helpful.
So SPICE is a low-level circuit sim, and PLECS is a bit higher level as it ignores non-linearities at the device level. Does PLECS simulate at a level similar to that of the popular EDA tools like Cadence?
So SPICE is a low-level circuit sim, and PLECS is a bit higher level as it ignores non-linearities at the device level. Does PLECS simulate at a level similar to that of the popular EDA tools like Cadence?
Roughly speaking yes, but Cadence has a large offering of products, so I need to be a little more specific. Ultimately, when you design analog devices with Cadence's tools, their transient behavior is simulated by Spectre (or FastSPICE) for IC (very) low-level analog validation. This is still SPICE, but with an engine really tailored for reading Verilog-A or large netlist descriptions (a format to describe circuits with plain text). Let's call this level 1.
They also have PSpice. Here, we are already speaking mixed-signal (including digital) for board-level simulation and systems. It competes with the likes of QSpice, the very popular Ltspice, SIMetrix etc. This is level 2.
Before PLECS or SIMPLIS, system-level designs that include controller, power-plant, thermal behavior and magnetics were also simulated with those tools. PLECS went one more level of abstraction higher so that all these systems could be simulated together (including say the power-train of a power electronic system that comprises battery to wheels of an electric car). This is level 3. Think of it like Simulink (MATLAB) but dedicated to the challenges of power electronics (high frequencies are difficult to simulate with general off-the-shelf simulators).
What is new now is that within PLECS, you can import SPICE netlists, effectively enabling level 2 and 3 within one tool, and even to some extent together in the same simulation run (ideal switches coexisting with SPICE models). So you can design top-down. You start from the system, and then deep dive by replacing, in some sub-circuits you care about, the PLECS ideal switches by the detailed SPICE models of your real devices. These are often provided by semiconductor manufacturers (and they may have been generated by an analog design tool from Cadence).
They also have PSpice. Here, we are already speaking mixed-signal (including digital) for board-level simulation and systems. It competes with the likes of QSpice, the very popular Ltspice, SIMetrix etc. This is level 2.
Before PLECS or SIMPLIS, system-level designs that include controller, power-plant, thermal behavior and magnetics were also simulated with those tools. PLECS went one more level of abstraction higher so that all these systems could be simulated together (including say the power-train of a power electronic system that comprises battery to wheels of an electric car). This is level 3. Think of it like Simulink (MATLAB) but dedicated to the challenges of power electronics (high frequencies are difficult to simulate with general off-the-shelf simulators).
What is new now is that within PLECS, you can import SPICE netlists, effectively enabling level 2 and 3 within one tool, and even to some extent together in the same simulation run (ideal switches coexisting with SPICE models). So you can design top-down. You start from the system, and then deep dive by replacing, in some sub-circuits you care about, the PLECS ideal switches by the detailed SPICE models of your real devices. These are often provided by semiconductor manufacturers (and they may have been generated by an analog design tool from Cadence).
Cool! Does PLECS do any symbolic simplification for its equations? Without that step, we found it impossible to handle even the smallest examples for realtime audio circuit modeling.
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.
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.
[deleted]
Very nice read. I wonder, have you also investigated the coupling of thermal and electrical systems in these simulations using reduced order multirate techniques?
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.
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.
3 years seems like a long time (though to be fair, I know spectre has been around for decades). Were there any particular challenges that made it difficult?
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.
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.
Do you have any opinions on the use of frequency-domain/harmonics-based SPICE for high-frequency (relative to the transition frequency of the power and their pre-amp devices involved) fixed-frequency converters, particularly the resonant kinds?
At some point the gate signals become digital pre-distortion for the pre-amps ("gate drivers") and come out of a wave table like synthesizer, and sure, system-level behavior still matters...
At some point the gate signals become digital pre-distortion for the pre-amps ("gate drivers") and come out of a wave table like synthesizer, and sure, system-level behavior still matters...
I am not sure that I know what harmonics-based SPICE is. Is it about AC analysis?
A related mode is "11.3.12 .PSS: Periodic Steady State Analysis" in [1], though that's arguably "light mode"; the heavy mode is "HB (Harmonic Balance Analysis)
Calculates steady states of nonlinear circuits in the frequency domain.
General Form .HB <fundamental frequencies>" as implemented in Xyce[0]:
Harmonic balance (HB) is a technique that solves for the steady state solution of nonlinear circuits in the frequency domain. In harmonic balance simulation, voltages and currents in a nonlinear circuit are represented by truncated Fourier series. HB directly computes the frequency spectrum of voltages and currents at the steady state solution. This can be more efficient than transient analysis in applications where a transient analysis may take a long time to reach the steady state solution. In particular, HB is well suited for simulating analog RF and microwave circuits.
HB supports an unlimited number of independent input tones for driven circuits in both serial and parallel builds of Xyce. The output of HB analysis is the real and imaginary components of voltages and currents in the frequency domain. Xyce also provides time domain responses of a circuit. By default, the numbers of samples in both time and frequency domain outputs are the same. However, the number of time domain samples can be much larger than the number of frequency domain samples by setting numtpts in .options hbint. This enables the users to use a small number of harmonics for each tone and produce well-resolved results in time domain.
[0]: https://xyce.sandia.gov/documentation-tutorials/ [1]: https://ngspice.sourceforge.io/docs/ngspice-html-manual/manu...
Harmonic balance (HB) is a technique that solves for the steady state solution of nonlinear circuits in the frequency domain. In harmonic balance simulation, voltages and currents in a nonlinear circuit are represented by truncated Fourier series. HB directly computes the frequency spectrum of voltages and currents at the steady state solution. This can be more efficient than transient analysis in applications where a transient analysis may take a long time to reach the steady state solution. In particular, HB is well suited for simulating analog RF and microwave circuits.
HB supports an unlimited number of independent input tones for driven circuits in both serial and parallel builds of Xyce. The output of HB analysis is the real and imaginary components of voltages and currents in the frequency domain. Xyce also provides time domain responses of a circuit. By default, the numbers of samples in both time and frequency domain outputs are the same. However, the number of time domain samples can be much larger than the number of frequency domain samples by setting numtpts in .options hbint. This enables the users to use a small number of harmonics for each tone and produce well-resolved results in time domain.
[0]: https://xyce.sandia.gov/documentation-tutorials/ [1]: https://ngspice.sourceforge.io/docs/ngspice-html-manual/manu...
Conversely, traditional SPICE simulators embody an inherently bottom-up approach
- its a lower down approach, but far from the bottom!
- its a lower down approach, but far from the bottom!
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.
And apparently, this is PLECS: https://www.plexim.com/products/plecs