Controller HIL Testing of Power Factor Correction Converters

Circuit Architecture, Control Topologies, and Operation of Bridgeless Totem-Pole PFC

The bridgeless totem-pole PFC converter architecture consists of a full-bridge switching structure split into two functional legs, an AC line inductor, and a DC output smoothing capacitor. Eliminating the front-end diode rectifier reduces the conduction path to a single high-frequency switch and one low-frequency switch at any moment, maximizing electrical efficiency.

Power Stage Structure and Wide-Bandgap Semiconductor Integration

The power conversion topology is formed by two half-bridge legs connected in parallel across the DC bus output:

• High-Frequency Switch Leg: Consists of two fast-switching power semiconductors configured as a half-bridge. Modern high-density designs employ wide-bandgap semiconductors, such as Gallium Nitride (GaN) high-electron-mobility transistors or Silicon Carbide (SiC) MOSFETs. Wide-bandgap devices offer low gate charge, low on-resistance, and minimal reverse-recovery loss, enabling operational switching frequencies ranging from 65 kHz to several hundred kilohertz without excessive thermal losses.
• Low-Frequency Synchronous Commutation Leg: Consists of two low-frequency silicon MOSFETs or ultra-low forward-voltage diodes operating at the AC mains line frequency (50 Hz or 60 Hz). This leg commutates electrical paths based on the polarity of the incoming AC voltage, connecting the neutral line to the negative DC bus return during positive half-cycles and connecting the line conductor during negative half-cycles.
• Inductive Storage and Capacitive Output Filter: An AC energy storage inductor is placed between the AC input source and the midpoint of the high-frequency switch leg to shape current ripple and store magnetic energy during the boost cycle. A large filter capacitor across the DC output bus suppresses double-line frequency voltage ripple and supplies energy during load transients.

During the positive half-cycle of the AC mains voltage, the lower switch of the low-frequency leg remains continuously closed, grounding the AC neutral line to the negative DC return bus. The lower switch of the high-frequency leg acts as the primary boost switch, storing energy in the AC inductor when turned on. When this active switch turns off, the upper high-frequency switch conducts synchronously, transferring the inductor energy into the DC output capacitor and load.

During the negative AC half-cycle, the switch roles reverse: the upper switch of the low-frequency leg grounds the line terminal to the negative bus, while the upper switch of the high-frequency leg operates as the primary boost control element.

Multi-Loop Continuous Digital Control Architecture

Regulating the bridgeless totem-pole PFC converter requires a cascaded control architecture implemented within the firmware of the embedded digital signal processor or microcontroller:

• Outer DC Voltage Loop: Operating at a lower sampling rate, the voltage loop monitors the output DC bus voltage, compares it against the target reference, and processes the error using a proportional-integral compensator. The output of this voltage regulator determines the current magnitude command required to maintain stable DC bus voltage under varying load demands.
• Grid Phase Synchronization and Reference Synthesis: The incoming AC grid voltage is sampled to track phase and frequency. The voltage loop’s current magnitude command is multiplied by a normalized sinusoidal phase template derived from the grid voltage, generating a synchronized AC current reference.
• Inner AC Current Loop: Operating at the rapid switching frequency of the converter, the inner current controller compares measured inductor current with the AC current reference. Control algorithms such as average current mode control, predictive current control, or hysteresis control generate pulse-width modulation duty cycles to force the AC inductor current to follow the sinusoidal reference.
• Supervisory State Machines and Safety Logic: Embedded routines control system startup, manage soft-charging inrush current limiters, oversee zero-crossing commutation logic to prevent current spikes, and execute fast hardware trips during overcurrent or overvoltage events.

Controller HIL Testing: Validate Early, Test Safely

Controller hardware-in-the-loop testing inverts the traditional approach. Instead of connecting the controller to a real power converter, you connect it to a digital twin of the converter — a real-time simulation model executing on dedicated test hardware fast enough that, from the controller’s perspective, it is indistinguishable from the physical plant.

The controller under test runs its actual production firmware on its actual silicon. It generates real PWM signals, reads real analog feedback voltages, and responds to real digital I/O — but the “converter” on the other side of those signals is a mathematical model running on an FPGA. The simulator captures the controller’s PWM outputs, computes the converter’s electrical response with nanosecond resolution, and drives the controller’s sense inputs with correctly scaled analog signals representing inductor current, bus voltage, and grid voltage.

This closed-loop arrangement delivers three decisive advantages:

Test faster, earlier, and with less hardware dependence. Controller validation no longer waits for power hardware. Firmware teams can begin closed-loop testing as soon as the control board exists — or even earlier, using rapid control prototyping. Design iterations that once took weeks compress into hours, because “rebuilding the plant” means updating a simulation model, not soldering a new board.

Inject faults safely and repeatably. Short circuits, open switches, sensor failures, grid collapses, harmonic distortion, frequency excursions — all can be injected into the digital twin at precisely defined instants, with perfect repeatability, and with zero risk to hardware or people. The controller’s protection logic can finally be tested exhaustively rather than anecdotally.

Achieve high coverage through automation. Because the plant is simulated, entire test campaigns can run unattended. Parameter sweeps across grid voltages, load steps, component tolerances, and fault timings execute automatically, with pass/fail criteria evaluated programmatically and full waveform data logged for every run. Regression testing after every firmware change becomes routine instead of aspirational.

Why PFC HIL Demands FPGA-Based Real-Time Simulation

Not every real-time simulator can test a PFC controller. The defining challenge is switching frequency.

A totem pole PFC built on wide-bandgap devices may switch at several hundred kilohertz. To capture the controller’s PWM edges accurately and reproduce the converter’s switching dynamics faithfully, the simulation must resolve events far faster than the switching period itself. CPU-based real-time simulation, with time steps in the tens of microseconds, is orders of magnitude too slow — an entire PWM cycle, or several, would pass between simulation updates, and the model would effectively see averaged, information-destroying snapshots of the controller’s behavior.

The answer is FPGA-based simulation. By implementing the converter model directly in FPGA fabric, simulation time steps shrink to just a few nanoseconds. At that resolution the simulator can:

• Capture PWM signals with sub-cycle precision, preserving duty cycle and dead-time information exactly as the controller produced it.
• Emulate inductor current and capacitor voltage dynamics between switching events, including the switching behavior of MOSFETs and body diodes.
• Represent short-circuit and open-circuit faults at the individual switch level, so protection logic can be exercised realistically.
• Drive analog outputs to the controller’s sense inputs with the low latency the closed loop demands.

Achieving nanosecond time steps requires careful model engineering. Practical FPGA converter models use switch-level linear representations of the power devices — capturing switching dynamics and fault behavior without the computational burden of fully detailed physics-based semiconductor models — and fixed-point arithmetic to optimize execution latency and FPGA resource usage. PWM sub-cycle averaging techniques preserve the effect of switching edges that fall between simulation steps, ensuring the emulated currents and voltages remain accurate even at extreme switching frequencies.

This is precisely the class of simulation the Impedyme CHP Series was engineered for. The CHP platform combines a real-time processor for system-level simulation with FPGA resources dedicated to ultra-fast power electronics models, along with the high-speed digital and analog I/O needed to close the loop with an external controller at full signal fidelity.

Real-Time Simulation Physics, Latency Limits, and Sub-Cycle Averaging

Simulating a high-frequency switching power converter in real time introduces computational demands that differ significantly from those of conventional real-time power grid or mechanical systems.

Microsecond Step Limits versus Nanosecond Execution Requirements

Standard real-time execution engines running on traditional central processing units typically operate with fixed integration time steps between 10 microseconds and 50 microseconds. While this resolution is sufficient for tracking low-frequency power grid dynamics or electromechanical drives, it is inadequate for high-frequency switching converters. At a switching frequency of 100 kHz, the complete switching period is 10 microseconds. Executing a simulation model at a 10-microsecond step size yields only one state update per switching period, introducing severe pulse-width modulation quantization errors, distorted duty-cycle measurements, and artificial numerical instabilities in the control loop.

Accurately capturing high-frequency switching behavior requires sub-microsecond execution resolution. Engineering guidelines recommend that a real-time simulator run at least twenty times faster than the target converter’s switching frequency. For converters operating at hundreds of kilohertz, the real-time simulation step must be reduced to the nanosecond domain.

Pulse-Width Modulation Sampling and Sub-Cycle Averaging

When an external physical controller sends high-frequency pulse-width modulation gate signals to a discrete-time simulator, the gate transitions rarely align with discrete simulation step boundaries. If the simulator samples these inputs asynchronously at coarse intervals, duty cycles are quantized into coarse discrete steps. This quantization causes artificial current oscillations, phase jitter, and false current spikes that destabilize the controller under test.

To resolve these errors without requiring unachievable sub-nanosecond simulation time steps, Field Programmable Gate Array (FPGA) logic engines employ sub-cycle PWM averaging:

• High-Speed Input Oversampling: Digital I/O channels on the FPGA sample incoming gate signals from the controller at high clock frequencies (e.g., 100 MHz clock rate), yielding 10-nanosecond temporal capture resolution.
• Sub-Cycle Duty-Cycle Calculation: Within each simulation time step, an internal hardware counter tracks the exact duration the gate signal remains high versus low, calculating a fractional value representing the relative on-time duty cycle over that step.
• Volt-Second Synthesis: The calculated fractional duty cycle is applied directly to the switch-linear circuit equations, preserving the exact volt-second balance across circuit inductors and capacitors. This method eliminates duty-cycle quantization errors and maintains accurate current and voltage representations even when the overall model execution step is larger than the sampling clock.

Switch-Linear Fixed-Point FPGA Modeling

Continuous, highly non-linear semiconductor models that account for complex physical phenomena—such as non-linear junction capacitances and continuous i-v curves—require iterative numerical solvers. Iterative solvers have variable execution times, making them unsuitable for deterministic real-time execution where missed time steps cause simulation failure.

To ensure deterministic nanosecond execution on FPGA hardware, the totem-pole PFC topology is implemented using switch-linear fixed-point mathematical representations. In a switch-linear framework, power switches and diodes are modeled as state-dependent linear circuit elements that transition between discrete conduction states. The state equations governing inductor currents and capacitor voltages are formulated as fixed-point matrix equations. Fixed-point arithmetic optimizes digital logic resource utilization, minimizes latency, and guarantees that the entire power stage mathematical model updates within a fixed clock cycle.

The Controller HIL Test Setup for a Totem Pole PFC

A representative controller HIL setup for PFC testing consists of four elements:

1. A development computer, hosting the modeling environment, instrumentation panels, and test automation — the engineer’s window into the real-time system.
2. An Impedyme CHP Series real-time simulator, running the totem pole PFC digital twin on its FPGA fabric with nanosecond time steps.
3. The device under test — the microcontroller or digital signal controller executing the production PFC control firmware.
4. Measurement instrumentation, such as an oscilloscope connected to the simulator’s analog outputs, for observing the emulated converter’s switching dynamics exactly as one would probe a physical converter.

The controller connects to the simulator through appropriate cabling and interface hardware that maps its PWM outputs, analog sense inputs, and digital I/O to the simulator’s high-speed interfaces. Impedyme’s signal conditioning and breakout options streamline this connection, matching voltage levels and pinouts between common controller development boards and the CHP platform. For larger programs, the same components scale from a desktop setup into full rack-based test systems integrating signal conditioning, fault insertion units, and breakout panels for connectivity with additional external hardware.

Inside PowerHIL Studio, the test application is organized around two main components: an interactive instrument panel — virtual dashboards for adjusting references, toggling faults, and monitoring waveforms in real time — and the power converter system model itself, comprising the totem pole power stage and the voltage and current control structure.

A Progressive Validation Workflow: From Desktop to HIL

One of the most valuable aspects of a well-structured HIL methodology is that it supports iterative, progressive validation. Rather than jumping straight to closed-loop testing with the physical controller, teams move through a sequence of simulation modes, each building confidence and each validated against the last.

Step 1: Desktop Model-in-the-Loop — Establishing the Golden Reference

The journey begins entirely on the development computer. Both the totem pole PFC converter and its controller run in offline simulation, with the converter represented at high fidelity — including detailed, non-linear switching device models. This desktop model is far too computationally heavy for real-time execution, but that is not its purpose. Its purpose is truth.

Running this model and archiving its simulation results establishes a golden reference baseline: the definitive record of how the converter and controller should behave. Every subsequent design stage — the FPGA-optimized real-time model, and ultimately the closed-loop HIL results with the physical controller — is compared against this baseline to confirm consistency and accuracy as the design progresses.

Step 2: Building the FPGA-Ready Real-Time Model

Testing a controller that switches at hundreds of kilohertz requires a converter model suitable for nanosecond-precision real-time simulation. One path is to adapt the golden reference model by hand — incorporating PWM sub-cycle averaging, explicit switching logic, and I/O connectivity. A faster path is to start from a pre-built, FPGA-optimized converter model.

Impedyme provides ready-made FPGA power converter models covering established power electronics topologies, including the totem pole PFC. The totem pole example includes:

• Two half-bridge legs combined into a full bridge, implemented as a switch-level linear model capturing MOSFET and diode switching dynamics.
• Built-in short-circuit and open-circuit fault modes on the switching devices, individually controllable at runtime.
• A line inductor model at the AC input and an output capacitor in parallel with a resistive element and a load modeled as a controlled current source.
• Fixed-point implementation throughout, tuned for minimal execution latency and efficient FPGA resource usage.
• An internal PWM generation block that emulates controller switching signals when no external controller is connected — allowing the plant model itself to be validated standalone.
• Digital-to-analog scaling that converts simulated current, voltage, and power signals to analog outputs, correctly scaled to the voltage ranges the controller’s sense circuitry expects.
• A frame-based data streaming subsystem that transfers high-rate FPGA signal captures to the main processor, enabling waveform logging at nanosecond resolution.

From this model, an automated deployment workflow generates target-optimized FPGA logic, maps the model’s inputs and outputs to the CHP Series’ physical interfaces, and packages the result as a reusable block ready to drop into the system-level real-time application. Teams that run this flow regularly can script it end-to-end, turning FPGA regeneration into a single automated step in their build pipeline.

Step 3: Real-Time Model-in-the-Loop — Verifying the Deployment

Before connecting the physical controller, the deployed FPGA model is verified in real-time model-in-the-loop mode: the converter runs on the FPGA while a simulated copy of the controller runs on the real-time processor. This closed loop — entirely inside the simulator — confirms that the FPGA design was generated and deployed correctly.

The results are compared against the golden reference baseline. Some differences are expected and understood: the desktop model uses detailed device physics, while the real-time model uses a switch-level fixed-point representation. The comparison confirms that these differences remain within acceptable bounds, and that the real-time plant reproduces the essential dynamics the controller will interact with.

This mode is also where the high-speed logging infrastructure earns its keep. Frame-based capture — for example, streaming frames of hundreds of samples at intervals of tens of microseconds — lets engineers reconstruct the original FPGA-resolution waveforms in the data inspection tools, examining voltage and current switching dynamics in fine detail. The simulator’s analog outputs can simultaneously drive an oscilloscope, giving hardware engineers the familiar experience of probing “the converter” with lab instruments.

Step 4: Closed-Loop HIL — The Real Controller Meets the Digital Twin

Now the physical controller enters the loop. The simulated controller is disabled, the device under test is connected through the interface harness, and the application is rebuilt and launched in HIL mode. The real microcontroller, running real firmware, now closes the loop around the FPGA-based digital twin.

The first and most fundamental check is equivalence: do the output waveforms produced under external controller operation match those from the real-time model-in-the-loop run? When they do — when the physical controller produces waveforms identical to its simulated counterpart — the team has powerful evidence that the control implementation faithfully realizes the control design, and that the entire signal chain between controller and simulator is correctly configured.

From there, dynamic testing begins. Typical scenarios include:

• Reference tracking. Step the DC bus voltage reference — for example, commanding a new bus voltage partway through a run — and verify the voltage loop settles cleanly to the new setpoint without excessive overshoot or oscillation.
• Power and load transients. Reduce the power reference mid-run and confirm the current amplitude scales down correctly while the bus voltage remains regulated.
• Grid disturbances. Apply voltage sags, frequency shifts, and waveform distortion to the simulated grid and verify the controller maintains current shaping and ride-through behavior.
• Fault injection. Activate a short-circuit fault on one leg of the converter’s full bridge and observe the response: the inductor current and output capacitor voltage collapse as expected, and — critically — the controller’s protection logic must detect the condition and react correctly. Open-circuit faults, sensor faults, and combined scenarios follow the same pattern.

Every one of these tests is scripted, repeatable, and safe. A short-circuit test that would destroy a physical prototype becomes a routine regression case that runs on every firmware commit.

Where PFC Controller HIL Testing Delivers the Most Value

EV onboard chargers. The totem pole PFC is the front end of choice for onboard chargers, and its bidirectional capability underpins vehicle-to-grid functionality. Automotive validation demands enormous test coverage across grid conditions worldwide, and functional safety processes require documented, reproducible fault-response evidence — a natural fit for automated HIL campaigns on Impedyme systems.

Server and telecom power supplies. Data center power supplies push efficiency targets that only totem pole architectures reach, at power densities that leave no margin for control error. HIL regression testing protects firmware quality across the rapid product cycles this market demands.

Solar inverters and energy storage. Grid-tied converters face stringent grid-code compliance requirements covering harmonics, ride-through, and anti-islanding behavior. Testing these behaviors against a simulated grid is dramatically faster and safer than arranging real grid-disturbance testing.

Motor drives and industrial power. Active front ends in motor drives perform the same power factor correction function and inherit the same validation challenges, particularly around regeneration and fault handling.

Across all of these, the shared theme is the same: the controller is the product, and controller HIL testing is the fastest, safest route to proving it.

Experimental Validation, Dynamic Transients, and Automated Fault Injection

C-HIL testing enables complete evaluation of controller dynamic performance and safety functions under transient and fault conditions without risking hardware damage.

Dynamic Setpoint Tracking and Load Transients

To verify the controller’s transient response during real-time C-HIL execution, dynamic operational step changes are commanded through the real-time target interface:

• DC Bus Voltage Reference Step: The target output voltage reference is stepped dynamically (e.g., from an initial baseline up to 500 V at 0.1 seconds). Real-time data capture demonstrates the controller’s response: the outer voltage loop increases the commanded current reference, smoothly raising the inductor current envelope while maintaining sinusoidal phase alignment with the grid voltage. The output voltage settles at the 500 V setpoint with minimal overshoot.
• Active Power Reference Step: The commanded active load power is reduced rapidly (e.g., stepping power down to 800 W at 0.4 seconds). The microcontroller’s voltage regulator responds by scaling down the amplitude of the current reference. Waveforms captured on the oscilloscope confirm an immediate reduction in current amplitude, maintaining stable DC bus regulation and near-unity power factor without triggering overvoltage protection trips.

Automated Fault Injection and Safety Logic Verification

Testing protection logic on physical power converters carries high risk, as software errors can lead to component destruction. In the Impedyme C-HIL environment, electrical faults are introduced safely into the FPGA model during real-time execution:

• Bridge Leg Short-Circuit Fault Injection: A short-circuit fault is injected across a switch in the first leg of the converter’s full-bridge network. Upon activation, the FPGA model updates its internal switch-linear matrix to simulate a shorted switch path.
• Circuit Dynamic Response: The simulated inductor current increases rapidly, and the output filter capacitor discharges into the fault path, causing the DC bus voltage to drop.
• Controller Protection Response: The rapidly rising simulated current feedback trips the overcurrent protection comparator pins on the physical microcontroller. The C-HIL test verifies that the controller latches fault flags, disables PWM outputs within microsecond deadlines, opens isolation relays, and initiates a safe shutdown sequence.
• System Setup Form Factors: While initial development uses compact desktop C-HIL test units, production validation environments can integrate real-time target components into standard equipment racks. Rack-mounted systems combine target simulators, signal conditioning panels, fault insertion units, and breakout connection panels to facilitate automated, multi-channel testing across diverse operational conditions.

Best Practices for PFC Controller HIL Programs

Teams that get the most from controller HIL testing tend to follow a consistent set of practices:

Anchor everything to a golden reference. Maintain the high-fidelity desktop model as the single source of truth, and version its baseline results alongside the firmware. Every model simplification and every deployment step is validated against it.

Understand your model’s fidelity boundaries. Know exactly which behaviors the switch-level real-time model captures and which it abstracts. Document expected differences from the golden reference so genuine regressions are never mistaken for known modeling deltas — and vice versa.

Verify the deployment before blaming the firmware. Real-time model-in-the-loop runs, executed before every HIL campaign, isolate simulator-side issues from controller-side issues. When a HIL test fails, you want certainty about which side of the loop to investigate.

Automate from day one. Script the FPGA build flow, the test execution, and the results evaluation. Manual HIL testing captures a fraction of the value; automated HIL testing turns the simulator into a continuously running quality gate.

Log at full resolution. Use frame-based FPGA logging to capture switching-level detail for every test run. When an intermittent anomaly appears once in ten thousand automated runs, the waveform record is the difference between a fix and a mystery.

Treat fault scenarios as first-class test cases. Build a fault catalog — device shorts and opens, sensor failures, grid events — and run it as part of standard regression, not as an occasional special exercise.

Plan for scale. A desktop HIL setup is ideal for a firmware engineer’s daily work; rack-integrated systems with fault insertion units and breakout panels serve team-level validation and pre-compliance campaigns. Choosing a platform that spans both, as the Impedyme CHP Series does, avoids painful mid-program migrations.

How Impedyme Supports the Complete PFC HIL Workflow

Impedyme’s controller HIL solution brings together every element of the workflow described above:

• CHP Series real-time systems provide the FPGA fabric for nanosecond-time-step converter simulation, the processor resources for system-level models and instrumentation, and the high-speed analog and digital I/O to close the loop with any external controller.
• PowerHIL Studio， hosts the modeling environment, interactive instrument panels, simulation-mode management from desktop model-in-the-loop through closed-loop HIL, high-resolution data logging, and test automation.
• FPGA-optimized converter model libraries — including the totem pole PFC with built-in fault modes — eliminate months of model development and come pre-validated for the CHP platform.
• Signal conditioning, fault insertion, and breakout hardware streamline the physical connection between controllers and the simulator, from a single desk setup to full test racks.
• Impedyme-RT and FPGA Scope extend the toolchain with real-time execution management and deep signal visibility into the FPGA fabric.

The same platform extends naturally beyond PFC: the CHP Series and Studio suite support DC-DC converter testing, motor drive HIL with MotorSim Studio, battery system validation with BatterySim Studio, and grid-interactive converter testing with GridSim Studio — so an investment in PFC controller HIL becomes the foundation of a lab-wide validation capability.