How to model switching losses when simulating high frequency converters on FPGA

Key Takeaways

• Switching loss scales linearly with frequency, so above a few hundred kilohertz it becomes the largest term in the efficiency budget.
• Ideal and averaged switch models report a conduction-only efficiency, which is why simulated designs pass while prototypes run hot.
• Efficiency numbers hold up when the loss model is calibrated on the bench and the solver resolves switching edges instead of averaging them.

A converter model that treats every switching event as instantaneous will report an efficiency figure your hardware never delivers.

Push a design past 100 kHz and the loss budget moves out of the conduction path and into the switching edges, where energy goes into output capacitance, current and voltage overlap, and reverse recovery. Silicon power converters generally run between 85% and 97% efficient, and wide bandgap parts reach 95% to 99%, so the entire quantity you’re trying to predict is only a few points wide. A model that drops switching energy doesn’t return a slightly optimistic answer. It returns an answer with the dominant term missing.

Real-time simulation on FPGA changes what you can measure, because the solver runs at a time step short enough to resolve individual edges instead of averaging across a switching period. That resolution earns its keep only when the loss model attached to it is parameterized from device data and checked against measurement. Efficiency estimation at high frequency is a modelling discipline before it’s a hardware problem.

Where converter losses actually go as switching frequency rises

Converter losses split into conduction, switching, and magnetic terms. Conduction loss scales with current squared and stays roughly flat against frequency. Switching loss scales linearly with frequency, so moving from 100 kHz to 200 kHz doubles it. Above a few hundred kilohertz, switching energy becomes the largest single term.

Consider a 10 kW silicon carbide inverter at 20 kHz that spends 60 W in conduction and 25 W in switching. Take the same power stage to 250 kHz and conduction barely moves while switching climbs past 300 W, which turns a 98% design into a 95% one. The thermal solution sized for the first case won’t survive the second.

That crossover reorders which modelling errors you can afford. At 20 kHz, an on-resistance value that’s 10% off matters more than a crude switching approximation. At 250 kHz the ranking inverts, and an energy curve read at the wrong junction temperature swamps everything else.

Why ideal switch models report efficiency that hardware never reaches

An ideal switch model has zero transition time, zero output capacitance, and no reverse recovery, so it dissipates nothing during commutation. The efficiency it reports is a conduction-only figure. At 20 kHz that error is small. At 500 kHz it hides most of the loss your thermal design has to remove.

Averaged models make the same omission in a different form. A state-space averaged buck converter at 1 MHz gives you control loop behaviour you can trust, and the loss figure it returns comes entirely from the resistive elements you added by hand. Nothing in it knows a transition took 15 ns.

The consequence shows up at thermal validation. Teams size a heatsink from simulated loss, build the prototype, and find junction temperature 30 degrees above prediction. There’s nothing wrong with the switch model itself. It answered the topology and control question it was built for, then got an efficiency question it was never parameterized to answer.

The scale makes that expensive. Data centre electricity consumption reached about 415 TWh in 2024, roughly 1.5% of global consumption, and high frequency conversion is heading into those rooms, so an estimate running a point optimistic multiplies across a fleet.

“It answered the topology and control question it was built for, then got an efficiency question it was never parameterized to answer.”

How FPGA time step and solver design bound loss resolution

FPGA solvers run converter models at time steps in the low hundreds of nanoseconds, and the fastest reach tens of nanoseconds. A 250 ns step samples a 500 kHz period only 8 times, which pins gate timing coarser than the duty resolution a loss calculation needs. Sub-step edge interpolation removes most of that error.

Without interpolation, a PWM edge falling between two solver steps gets snapped to the nearest one. The jitter is small in absolute terms and large as a fraction of an on-time only 400 ns long, and it lands in the switching energy accumulator as a duty cycle error. Repeat that across a few hundred thousand events per second and the error stops being small.

The eHS solver on OPAL-RT platforms resolves gate transitions between time steps and accumulates per-event switching energy in the same FPGA fabric, so the loss figure comes from the edges the model saw instead of a post-processed average. That decides if a 1 MHz converter study is worth running.

Comparing loss accounting methods for high frequency converter simulation

Three approaches dominate. Analytical energy equations compute loss from voltage, current, and transition time. Datasheet lookup tables interpolate measured turn-on and turn-off energy against current and temperature. Behavioural device models solve the transition itself. Accuracy rises across that list and so does the FPGA cost.

Most high frequency programs land on corrected lookup tables. They cost almost nothing at runtime, they carry the temperature dependence analytical equations drop, and the correction work is a one-time job. Behavioural models earn their cost when you’re studying the edge itself, and that’s a device question rather than an efficiency question.

Calibrating switching energy models against datasheet and bench measurements

Calibration ties simulated switching energy to measured energy under your own gate drive conditions. Vendor turn-on and turn-off curves come from a specific gate resistance, bus voltage, and loop inductance. Change any of those and the energy per event shifts enough to push the model outside the accuracy you need.

A double pulse test gives you the anchor. Run it on the actual power stage, capture turn-on and turn-off energy at two or three current levels and two junction temperatures, then scale the model’s lookup surface until simulation and bench agree. That afternoon of lab time removes the largest unknown in the loss budget.

Recalibration isn’t optional once the hardware moves. Temperature dependence is steep enough that a model calibrated at 25 degrees understates loss badly at the 125 degrees the converter runs at, so capture two temperatures and interpolate. Record the bus voltage as well, because switching energy scales with it.

Mistakes that make simulated efficiency look better than measured efficiency

Optimistic efficiency traces back to a short list of omissions, and every one moves the result in the same direction. Reverse recovery gets left out. Output capacitance is treated as lossless. Gate drive power sits outside the total.

• Reverse recovery charge dropped from the diode model, which removes a loss term that grows with frequency.
• Output capacitance energy treated as lossless, which understates hard-switched turn-on across the bridge.
• Gate drive power excluded from the efficiency total, though it scales linearly with frequency.
• Loss curves evaluated at ambient temperature instead of the junction temperature reached under load.
• Dead time set to zero, which removes body diode conduction and the commutation loss that follows it.

None of these is subtle once you go looking, and all survive review because the simulation runs and returns a plausible number. Confirm each term is present before anyone quotes an efficiency figure. A loss budget reported as separate conduction, switching, gate drive, and magnetic terms makes an omission obvious, because a missing term shows up as a round zero.

Turning loss accounting into efficiency numbers you can defend

An efficiency figure you can defend arrives with its loss breakdown, the conditions it was computed under, and a bench measurement it agrees with. Anything less is an estimate that happens to carry decimal places. Getting there costs a characterization campaign and a solver that resolves switching edges.

The teams who get this right treat the loss model as a deliverable with its own acceptance criteria. They record the gate resistance, bus voltage, and junction temperature behind every energy curve, and rerun the double pulse test when the layout changes. They report efficiency as a range across temperature instead of a single number, because that’s what the hardware will do under load.

Running the loss accounting inside the FPGA solver, as OPAL-RT does with eHS, keeps switching energy attached to the events that produced it, so the number you carry into a design review traces back to behaviour the model resolved. That discipline is unglamorous, and it’s the difference between catching a thermal problem in week 2 and confirming it in month 6.

“An efficiency figure you can defend arrives with its loss breakdown, the conditions it was computed under, and a bench measurement it agrees with.”