How to simulate power electronics on FPGA for nanosecond timesteps

Key Takeaways

• Fast converter accuracy is set by the shortest switching event, so timestep selection starts with commutation timing.
• Moving the switching power stage to FPGA hardware restores the resolution a CPU solver loses between fixed samples.
• The best results come from disciplined partitioning, clean state mapping, careful numeric scaling, and closed-loop timing checks.

Nanosecond timestep simulation matters because a fast converter stays accurate in real time only when its switching stage runs on an FPGA instead of a CPU.

Power electronics teams hit this limit as soon as device speeds rise. Global electric car sales reached nearly 14 million in 2023, up 35% from 2022, which means more traction inverters, on-board chargers, and DC/DC stages are moving into tight validation loops. A CPU solver still works for slower plant models, but switch-level converter behaviour gets lost when commutation happens between discrete software samples. You recover that missing resolution when you put the power stage on FPGA fabric and keep the control loop synchronized in real time.

Fast switching sets the timestep your solver must meet

Your timestep must be short enough to catch every switch transition that changes circuit state. That limit comes from switching frequency, dead time, and edge placement. A solver that samples slower than those events will blur them and shift the converter response. Power converter accuracy starts with timing resolution, not average waveform quality.

A two-level inverter at 100 kHz gives each full switching period only 10 microseconds. Dead time inside that period can shrink to tens of nanoseconds, and the current path can flip during that small window. You will miss that shift if your solver checks the network only every few microseconds. The waveform can still look smooth while the switching event is already wrong.

Wide bandgap semiconductors raise the pressure further because they can switch up to 10 times faster than silicon devices. That pushes converter validation away from averaged models and toward switch-resolved execution. You are no longer sizing timestep for a sine wave or an output ripple estimate. You are sizing it for the shortest event that changes loss, current, or device stress.

“Power converter accuracy starts with timing resolution, not average waveform quality.”

CPU solvers miss converter events between fixed sample points

A CPU solver misses switching detail because it evaluates the model at ordered sample instants instead of at each hardware edge. Events that occur between those instants are reconstructed after the fact. That reconstruction smooths the transient and hides short commutation effects. Your controller then sees a plant that reacted later than the physical converter would.

Take a half bridge that commutates during a 1 microsecond PWM interval while the plant solver runs at 5 microseconds. The switch state changes, the freewheel path shifts, and diode recovery starts before the next CPU update arrives. Current spikes and voltage overshoot are then folded into one coarse result. You can still close the loop, but you won’t trust the stress picture.

This gap matters most during hard switching, short circuit testing, and pulse skipping. A CPU can model slower thermal states, mechanical loads, and supervisory logic very well, yet it struggles when electrical state changes several times inside one sample. That is why teams often see stable average currents but wrong instantaneous peaks. The mismatch usually comes from resolution, not from poor control design.

FPGA execution restores switching resolution at nanosecond timesteps

FPGA execution restores resolution because the switching network is evaluated with hardware-level parallelism on each clock step. State updates happen deterministically instead of waiting for a software thread. Nanosecond-class timesteps become practical for the electrical stage under closed-loop conditions. That is the key reason FPGA power electronics simulation stays aligned with fast converter physics.

A three-phase converter illustrates the gain clearly. Each leg can change state at nearly the same moment, and each path influences the others through the DC link and machine currents. A CPU tends to serialize those calculations, but FPGA fabric processes many paths at once. You get timing that matches the gating logic rather than timing shaped by processor scheduling.

This is also where execution method matters more than board marketing. OPAL-RT eHS runs the power electronic network on the FPGA so switching events stay resolved in real time instead of being averaged away. That lets you keep the controller under closed-loop test while the plant still honours dead time, device commutation, and topological state changes. Once the switch network is solved at that speed, the rest of the model becomes much easier to trust.

Place the switching power stage on the FPGA fabric

The best partition places the switching power stage on the FPGA and leaves slower subsystems on the CPU. Electrical commutation needs the finest timestep. Thermal states, mechanical shafts, and supervisory logic do not. A mixed architecture keeps each part of the model on hardware that suits its timing needs and latency limits.

A motor drive model is a useful example. The inverter bridge and DC link belong on the FPGA because they react at each gate edge. The motor’s magnetic dynamics can stay on a slower solver if their bandwidth is lower than the commutation events. Your control loop still sees a coherent plant because the fast and slow domains exchange signals at fixed boundaries.

This partition also keeps FPGA resources focused on the part that benefits most from them. Trying to move every plant equation onto the FPGA can waste logic and memory without improving the answer. You want the hardware budget spent on switch states, network updates, and low-latency I/O. The rest belongs where model flexibility is easier to maintain.

Map discrete switch states into FPGA ready logic

Power electronics models run well on an FPGA when switch positions are expressed as discrete states with deterministic update rules. Each gate edge must select a valid circuit path immediately. Ambiguous switching logic causes timing drift and illegal states during commutation. Clean state mapping is what turns a schematic into a reliable hardware solver.

A simple bridge leg shows the method. The upper device, lower device, dead time, and diode conduction must be represented as explicit conditions, not as loosely timed software flags. Gate commands arrive, the state machine evaluates legality, and the network conductance updates on the next hardware cycle. That sequence keeps shoot-through protection and freewheel paths consistent.

Fault behaviour needs the same discipline. Desaturation trips, blocked gates, and open-circuit conditions should enter the logic as direct state changes with known latency. You can’t leave those cases to a slow supervisory pass if the goal is nanosecond timestep simulation. The model earns trust when every discrete event has one clear electrical consequence.

Fixed point arithmetic sets accuracy on the FPGA

Fixed point arithmetic sets FPGA accuracy because every signal uses a limited word length and scaling choice. Bad scaling will clip peaks or bury small ripple in quantization. Good scaling preserves the events that matter to control and protection across operating range. You need a numeric plan before you judge waveform fidelity.

A current loop with a 1,200 V DC bus and milliamp-level sensing can’t share one careless scale. The bus voltage needs headroom, while current error needs fine resolution near zero. You will usually tune word lengths around the most sensitive internal variables first. This short checklist keeps that work disciplined.

• Set ranges from worst-case transients instead of nominal steady state.
• Reserve margin for overshoot, faults, and sensor offset.
• Use more bits where current error affects control action.
• Check accumulator growth in filters and integrators.
• Compare fixed point results against a high precision reference.

Those checks matter because quantization mistakes hide in places that look stable. A converter can pass average power tests while still distorting threshold crossings in protection logic. You’re validating edge timing as much as amplitude. Numeric format is part of the plant model, so it deserves the same care as topology and timestep.

Select an FPGA board that fits model size

The right FPGA board is the one that meets your model’s timing, logic, memory, and I/O limits with margin. Device speed matters, but usable resources matter more. A small model on a large board wastes budget. A crowded model on a small board won’t close timing once switching logic and interfaces are compiled.

A grid-tied inverter with a few PWM channels asks for something very different from a multi-converter test bench with many sensors, fault inputs, and low-latency outputs. You should estimate switch count, state update complexity, memory use, and I/O rate before picking hardware. The checkpoint below keeps the selection practical instead of vague.

Board choice is really a timing budget choice. You are buying enough deterministic hardware to preserve electrical events at the resolution your converter requires. If you size only for nominal operation, the first added fault case will expose the gap. A good fit leaves room for timing closure, not just model compilation.

Verify timing fidelity with closed loop hardware tests

Timing fidelity is verified when the simulated converter reacts to controller commands with the same sequencing and latency you expect from hardware. Closed-loop tests expose missed edges, delayed state updates, and weak numeric scaling quickly. This step turns a fast model into a trusted test instrument. You are checking causality, not just waveform shape.

A practical test starts with one PWM leg, one current measurement, and one protection path. You compare gate timing, current response, and trip behaviour against a reference model or measured hardware capture. Jitter, delayed turn-off, or a missing dead-time effect will show up immediately in that small setup. Starting small keeps debugging tied to one clear electrical path.

That discipline scales better than chasing pretty plots from a large integrated model. Once the fast stage behaves correctly, the rest of the plant can be added with confidence because the switching foundation is sound. OPAL-RT fits this work when you need the FPGA to carry the power stage at nanosecond-class timesteps while the broader test remains closed loop and deterministic. Good converter simulation is less about raw compute and more about keeping every critical switching event where physics says it belongs.

“Good converter simulation is less about raw compute and more about keeping every critical switching event where physics says it belongs.”