Introduction

Power electronics has always been an interesting area for me, particularly the design of inverters and their switching mechanisms.

For this project, I want to explore the design of a three-phase Sinusoidal Pulse Width Modulation (SPWM) inverter using a hybrid microcontroller–FPGA architecture.

The idea is to investigate how a microcontroller and programmable logic can work together to manage the control and switching requirements of an inverter.

Rather than immediately building the power stage, I am starting by understanding the architecture, exploring suitable electronic components, and identifying the requirements for a practical hardware design.

At this stage, I have not implemented the complete inverter or generated working SPWM gate signals. I am still in the initial research and component-selection phase, just before beginning the circuit schematic in KiCad.

1. Why explore an FPGA-based approach?

Microcontrollers are already capable of generating PWM signals. Advanced timer peripherals in devices such as STM32 microcontrollers can generate complementary PWM outputs and support hardware dead-time insertion.

So, why consider an FPGA?

An FPGA offers a different approach to digital hardware design. Instead of relying entirely on predefined peripheral functions, it allows custom digital logic to be configured for a particular application.

For an inverter controller, some of the functions worth exploring include:

• Complementary PWM signal generation.
• Programmable dead-time insertion.
• Synchronised switching signals.
• Hardware interlocking between complementary outputs.
• Fault-related signal blocking.
• Deterministic handling of digital switching events.

The objective is not to assume that an FPGA is automatically faster or better than a microcontroller. I want to investigate whether a hybrid architecture provides useful flexibility and predictable timing for this particular application.

A fair comparison would eventually require measuring timing resolution, jitter, PWM frequency, pulse-width resolution, synchronisation, and fault response.

2. Understanding complementary switching

A three-phase inverter generally consists of three half-bridge legs. Each leg has an upper and a lower power switch.

This means that a conventional three-phase, two-level inverter requires six switching control signals.

The upper and lower switches in each half-bridge operate complementarily. When one is commanded ON, the other must remain OFF.

However, switching devices do not turn off instantaneously. If the lower switch turns ON before the upper switch has completely stopped conducting, both switches may conduct simultaneously.

This condition is known as shoot-through. It can create a very large current through the DC bus and potentially damage the power devices.

This is why dead-time control is an important consideration in inverter design.

What is dead time?

Dead time is a short interval inserted between turning OFF one switch and turning ON its complementary switch.

During this interval, both switches are commanded OFF.

For example:

• The upper switch S1 turns OFF.
• A short dead-time interval begins.
• Both S1 and S2 remain commanded OFF.
• After the dead-time interval, the lower switch S2 can turn ON.

The same principle applies when switching in the opposite direction.

Dead-time waveform

The following waveform illustrates the concept of complementary switching signals with a dead-time interval.

Figure 1 — Complementary switching signals showing the dead-time interval between S1 and S2.

Dead time must be selected carefully. Too little dead time can increase the risk of shoot-through, while excessive dead time can introduce output-voltage distortion and affect inverter performance.

The actual dead-time requirement depends on the selected power semiconductor devices and gate drivers. Their propagation delays, turn-off characteristics, and timing differences must be considered.

The FPGA digital output timing alone does not determine when a MOSFET or IGBT has physically stopped conducting.

For this project, I intend to investigate programmable dead-time generation as one of the functions of the proposed FPGA logic.

3. Introducing the Vicharak Shrike-Fi

For this experiment, I will be using the Vicharak Shrike-Fi development board.

I was interested in exploring a platform that combines the flexibility of a microcontroller with the configurability of programmable FPGA hardware.

Shrike-Fi brings these two elements together on a single development board:

• ESP32-S3: The microcontroller responsible for higher-level system control, configuration, communication, and parameter management.
• Renesas ForgeFPGA SLG47910V: The programmable logic device that can be configured to implement custom digital hardware functions.

The ForgeFPGA provides 1,120 five-input Look-Up Tables (LUTs), making it a compact programmable logic platform for experimenting with custom digital architectures.

Figure 2 — Vicharak Shrike-Fi development board, showing its front and rear sides.

You can explore the platform through the following links:

• Vicharak Shrike-Fi development board
• Official Vicharak Shrike GitHub repository

4. Proposed MCU–FPGA division of responsibilities

One of the main things I want to explore is how responsibilities can be divided between the ESP32-S3 and the ForgeFPGA.

The proposed architecture is:

ESP32-S3 — System-level control

The microcontroller could handle:

• Configuring operating parameters.
• Managing system states.
• Sending control and configuration information.
• Communicating with a computer.
• Monitoring system status and reporting faults.

ForgeFPGA — Digital switching logic

The FPGA could be explored for:

• Generating complementary PWM signals.
• Implementing programmable dead-time.
• Managing switching interlocks.
• Synchronising digital switching events.
• Blocking switching signals during fault conditions.

This division would allow the microcontroller to manage the overall system while the FPGA handles the custom digital logic.

These are proposed responsibilities, not implemented features at this stage.

MCU–FPGA communication: The four-bit interface

An important aspect of the Shrike-Fi architecture is its four-bit MCU–FPGA communication interface.

This is particularly relevant to the proposed division of responsibilities because the ESP32-S3 and ForgeFPGA need a way to exchange information.

I want to investigate how this four-bit interface can be used to transfer configuration data, control information, and status information between the two devices.

The exact communication protocol, signal direction, timing, and data format will need to be established from the board's hardware documentation and verified during implementation.

This interface will be an important part of understanding how the microcontroller can configure and coordinate the FPGA logic.

5. FPGA GPIO voltage considerations

Another important hardware consideration is the FPGA's GPIO voltage level.

The FPGA GPIO operates at 3.3 V logic levels. This means that external components must be checked for electrical compatibility before connecting them directly to the FPGA.

For example, the selected gate-driver IC must have input thresholds compatible with the FPGA's output levels.

If an external interface requires different voltage levels or additional drive capability, suitable buffering or level-shifting circuitry may be required.

It is also important to distinguish between the digital control side and the power-switching side.

The FPGA will only generate low-voltage control signals. It will not directly drive the gates of the MOSFETs or IGBTs.

Dedicated gate-driver circuitry will be required between the digital controller and the inverter power stage. Depending on the selected topology and devices, isolation and appropriate gate-drive supplies may also be necessary.

These requirements will influence the components selected for the circuit design.

6. Startup sequence and fault-safe operation

Generating the correct PWM signals is only one part of designing an inverter controller.

The system must also behave predictably during power-up, shutdown, and fault conditions. This is particularly important in power electronics, where unintended switching can damage components.

Some of the behaviours I intend to consider in the design are:

Safe startup

All gate-control outputs should remain in their inactive state during power-up, FPGA configuration, and controller initialisation.

Controlled PWM enable

Switching should only be enabled after the controller and required hardware conditions have been checked.

Fault shutdown

Conditions such as overcurrent, undervoltage, or an emergency-stop input should disable the gate-control signals.

Fault recovery

The system should not automatically resume switching after a serious fault without an appropriate reset or recovery procedure.

Hardware interlocking

The design should prevent complementary switches in the same half-bridge from being commanded ON simultaneously.

These behaviours should be considered in both the digital logic and external hardware.

In particular, critical protection should not depend solely on a software command. Independent hardware protection and a suitable gate-driver shutdown mechanism will also need to be considered.

7. Exploring the hardware components

Before drawing the circuit schematic, I need to identify the major sections of the inverter and explore suitable components for each.

Some of the areas I am currently investigating include:

• Power switches: Selecting suitable MOSFETs or IGBTs based on the intended DC bus voltage, current, switching frequency, and power requirements.
• Gate drivers: Finding suitable gate-driver ICs with appropriate input logic levels, gate-drive capability, and protection features.
• DC bus: Understanding the requirements for DC-link capacitors and bus-voltage handling.
• Power supplies: Planning the required regulated supplies for the controller, FPGA interface, and gate drivers.
• Voltage and current sensing: Exploring suitable sensing circuits for monitoring the inverter.
• Protection: Considering overcurrent, undervoltage, emergency shutdown, and other necessary protection mechanisms.
• Isolation and interfacing: Identifying where isolation, buffering, and level shifting may be required.

The final component selection will depend on the intended operating conditions and the electrical specifications of the individual devices.

I do not want to select components independently without considering how they interact as a complete system.

8. Current project stage and next steps

At this point, the project is still in its initial research and hardware-planning phase.

So far, the focus has been on understanding the switching requirements, studying dead-time control, exploring the Shrike-Fi architecture, and identifying the hardware considerations that will influence the inverter design.

The next steps are:

1. Finalise the system block diagram.
2. Decide the intended inverter specifications and operating conditions.
3. Select suitable MOSFETs or IGBTs and gate-driver ICs.
4. Identify the required power supplies, sensing, protection, and isolation circuits.
5. Design the circuit schematic in KiCad.
6. Review component compatibility and the overall schematic before proceeding to PCB design.

Only after the hardware architecture and circuit design have been reviewed will I move towards implementation and testing.

Conclusion

This first blog entry is about understanding the problem before attempting to build the solution.

The combination of a microcontroller and a compact FPGA provides an interesting platform to explore custom digital switching logic for power electronics.

However, there are several things to consider beyond PWM generation itself: communication between the MCU and FPGA, GPIO voltage compatibility, gate-driver requirements, dead-time selection, startup behaviour, and fault protection.

The immediate goal is to turn these requirements into a practical circuit design in KiCad.

There is still a lot to explore, and this is only the beginning of the project.

Project: PROJ001 / 3-ϕ Inverter SPWM
Platform: Vicharak Shrike-Fi — ESP32-S3 + Renesas ForgeFPGA
Engineering log: Project Logs