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.
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.
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.
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?
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).
Conversely, traditional SPICE simulators embody an inherently bottom-up approach
- 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.
I did a double take at your name. Hello doppelganger!
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.
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.
I know what SPICE is: https://en.wikipedia.org/wiki/SPICE
And apparently, this is PLECS: https://www.plexim.com/products/plecs
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.
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?
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).
Conversely, traditional SPICE simulators embody an inherently bottom-up approach
- 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.
I did a double take at your name. Hello doppelganger!
Hello! Haha