Close

Let's talk about the FPGA...

A project log for Axiom: 100+kW Motor Controller

High Power, High Performance 400V 300A 100+kW Motor Controller fully compatible with VESC®

marcosMarcos 06/14/2019 at 11:292 Comments

In the early days...

Axiom originally started with discrete logic that was in charge of 2 specific tasks:

Avoiding shoot-through

A shoot through happens when both TOP and BOTTOM switches in a leg turn ON at the same time, creating a dead short across the 400Vdc input.

If that would happen and no protections were in place, your vehicle would become a ball of fire. We want to make sure a '1' is never commanded on both top and bottom switches at the same time, even in case of a firmware bug or microcontroller damage.

This was our hard solution to a hard problem:

Input pulldowns make sure the signals stay in '0' while the microcontroller is under reset and during GPIO initialization. If you follow the logic, it will set both top and bottom to '0' when both inputs are '1'.

This takes 3 logic ICs (U5, U6 and U7) plus bypass capacitors, but it had the extra benefit of level shifting the signals from 3.3V to 5V for higher noise immunity.

Latching faults

When a fault happens, we don't want to rely on the firmware to keep things safe. In this context a fault can mean 2000+ Amps flowing close to the microcontroller with very high, and possibly damaging levels of EMI.

With that in mind, our analog signal chain has comparators that will trip a fault when a voltage, current or temperature signal goes beyond design limits, like this example: (Temperature signal path is simpler than voltage and current)

The problem here is that the comparator will only assert a fault while the fault is present and then return to the normal state. With the temperature it can be a few seconds, but in case of voltage and current, those are likely microseconds and we can't afford to miss that signal.

Enter discrete fault latching:

This bit of schematic was taken from an ancient forum post of our power electronics guru, it latches a fault until the CLR_OC_Fault is cleared, and we had a latch circuit for current and another for voltage because we need to know why it faulted in the first place. We leaved overtemperature unlatched because it was quite a lot of parts, this discrete solution already takes 7 ICs.

Let's talk about the FPGA...

Despite there are many FPGA manufacturers out there, there is one that is special.

They all require you to install gigabytes worth of software just to create the simplest logic, but in case of the ice40 family, there is a interesting open source effort to reverse engineer their logic and create an open source toolchain, just like gcc, but for FPGA's. Its called Project Icestorm.

And now that we have a backend, 2 other projects emerged to make it more user friendly:

Icestudio allows you to easily draw your logic circuit, like their example from their frontpage:


Yes, its that easy and the whole software package only takes a few megabytes! And it won't bother you with licenses, activation, sign ups, ads, newsletters.

I chose the ice40up5k, its not automotive grade but its low cost, and at 5k logic cells it has potential to fit some promising logic. I ran the awesome risc-v core in our Axiom board and developed delta sigma demodulation on this fpga, its good stuff.

Shoot through elimination, FPGA-style

Remember the discrete implementation? Axiom board recreates that hardware inside the FPGA

And we can easily simulate the behavior by just typing "apio sim", icestudio creates a testbench template for you.

Latching!

In a similar way, we can implement a latch circuit like this

Note that now we do have a temperature fault latch, this time for free.

With apio we can again simulate the behavior of the block:

And because I have the ice40up5k evaluation board, I can actually measure the signals in the hardware using a logic analyzer for validation.

I hope this shows how easy and promising it is to develop on an FPGA nowdays, especially for the simple stuff.

As Axiom FPGA code grew in features we left behind the pretty icestudio and we now run a full featured verilog HDL project because a GUI makes simple tasks simple, but complex tasks impossible.

We can make the FPGA to work as an external watchdog, a coprocessor, accelerator, deadtime monitor or whatever we need, its really valuable for a research team to have all this integrated and ready to go, and its placed in just the right spot where all the critical control data flows:

The FPGA configuration is stored in the MCU flash memory and can be updated from the GUI, and is key to protect any special IP we develop in-house.

Verilog allows Axiom to go way beyond replacing a few logic ICs, it can make obsolete the whole analog signal chain by demodulating and sinc-filtering a delta sigma stream, in all 7 analog input channels, which is unheard in motor control industry. We'll get there someday, it just needs software, hardware is ready!

Discussions

MingfeiHuang wrote 11/25/2020 at 08:18 point

where can we find the FPGA code for this project?

  Are you sure? yes | no

sabahvs wrote 05/11/2020 at 06:33 point

where can we find the VHDL code for this project?

  Are you sure? yes | no