Should I use an FPGA for this project?

[Dmeads]

I am designing a mini electric car model complete with a battery, charging controller, and mulitple BLDC or Induction motor controllers (I haven't decided which yet), and boost stages. I might do 4 motor controllers and see how to manipulate the controllers to make the car reverse and turn and stuff.

This is going to be a pretty long term project.

For the battery charger, I was just gonna use a LiPo charge controller IC, but to deliver all the switching signals to the boost converters, as well as the PWM or SPWM signals to the 4 motor controllers, I was wondering if I should use an FPGA.

I was thinking a Micro might not be able to handel all that stuff, especially if I am doing high speed switching on many outputs.

I dont have any experience with FPGA, and only minor digital logic experience (I get the theory, but have never built any of the gates or circuits in hardware).

I have heard that FPGAs are faster, but is this the right tool for my project? Or should I spend some more money on multiple micros with higher speed clock crystals and larger memory.

I don't really have a ton of time to spend learning something new right now, so I only want to get into FPGAs if it is a must for this project, otherwise I might wait until next year or so.

Also, wondering about the MKR VIDOR 4000 from Arduino. It has an FPGA on it, and I dont need a bunch of buttons and LED's and extra stuff on my boards, I'm really just interested in looking at the output signals.

Has anybody used this? would it be worth buying for my project?

thanks!!

[hamster_nz]

That is not an FPGA friendly project. Use a few descrete chips, and a micro to drive it.

[Dmeads]

thanks I think Im gonna just use a micro with a bunch of PWM pins and a high clock speed

[Berni]

This is not the right project for a FPGA.

You wouldn't want to design your own BLDC controller as that gets pretty complicated while you can buy ready made BLDC controllers really cheaply.

As for the rest doing control and sending commands to the motor controllers could be done using a 8bit AVR running at 1/10th the full clock speed if you are efficient with your programming.

FPGAs are not just simply some sort of "faster microcontroller", they work in a fundamentally different way and this is what gives them the ability over tight timing control and the ability to do a lot of things in parallel. For tasks of very sequential nature they are not really much faster since internally signals are still typically in the order of 100 to 600MHz depending on what chip it is and what logic you are using. Infact for very sequential workloads its common practice to actually build a little microcontroller inside the FPGA because at some point it becomes easier to implement a whole computer in logic rather than implement a very complex sequential task in raw logic.

[rstofer]

You will probably get into floating point math at some point and this brings a lot of baggage to the FPGA solution.  OTOH, you can have as many PWM channels as you wish.  Need 10?  20? 50? No problem!  As long as there are pins left, you can keep adding more PWMs.

I would think you would be well served to create a block diagram of the overall system and estimate interconnections and responsibilities.  How can the system best be partitioned?  You mention a battery charger.  Why does the main CPU need to get involved with this?  Can a very small PIC or ATmega independently handle this problem?

I wouldn't set a goal of having one all-powerful CPU because the system can become too complex to manage.

Before I decided on FPGA versus ARM M4 Dual Core with built-in floating point unit I would want that diagram.  The ARM chips are likely more than fast enough.  Still, it takes careful coding and probably an RTOS  like FreeRTOS which just about every manufacturer has ported.

I would be looking at the various ARM chips, probably in the STM32F famiy.  I would want something with hardware floating point.

The FPGA offers parallelism which can certainly boost overall performance.

[PCB.Wiz]

I am designing a mini electric car model complete with a battery, charging controller, and mulitple BLDC or Induction motor controllers (I haven't decided which yet), and boost stages. I might do 4 motor controllers and see how to manipulate the controllers to make the car reverse and turn and stuff.

This is going to be a pretty long term project.

For the battery charger, I was just gonna use a LiPo charge controller IC, but to deliver all the switching signals to the boost converters, as well as the PWM or SPWM signals to the 4 motor controllers, I was wondering if I should use an FPGA.

How 'mini' is this electric car ?  Is there anything unusual/special about it ?
Motor drive is a very common problem that MCUs solve, so you should have the FPGA as a back up plan, should you hit a problem 1 or 2 MCUs cannot solve.
In a high current/noisy system you might like to look at 5V operating MCUs and the high current cabling may dictate ho many MCUs you use.
Copper cable costs a lot more than MCUs so you may decide to place a MCU on each motor, to simplify the power and emc side of things.

As well as a MCU, you can also look at parts like this AP1050
https://www.akm.com/akm/en/aboutus/news/20181018AP1050_001/
"The AP1050 is a pre-driver for a 3-phase brushless motor with built-in power supplies, which operates motor drive voltage in range of 8V to 36V. It incorporates a step-down DC-DC converter and LDOs to
generate the power supply that the motor drive system requires.  The bootstrap circuit is embedded and it enables to use N type MOSFET for both low side and high side."

that may be too new to design in right now, but you can see it includes the FET pre-drivers and operates up to 36V, and just needs a simple SPI link to the MCU.

Companies like Infineon also have higher voltage Power-included MCUs

[NorthGuy]

You could do it in FPGA - it has lots of pins and each pin may be controlled independently. If you want to do lots of things in parallel to the extend that it forces you into multiple MCU, FPGA might be a good choice. However, FPGA excells at digital stuff, not the analog - you may need external ADCs.

I dont have any experience with FPGA, and ...

I don't really have a ton of time to spend learning something new right now ...

Then FPGA is completely out of the question.

[a59d1]

ATMega2560 (or Teensy) is probably perfect for this - whole bunch of ADC pins, decent clock rate, tons of of program memory, 30-50 I/O pins. An FPGA is super overkill, very annoying to program, and will be extremely inconvenient to work with.

[rstofer]

An FPGA is super overkill, very annoying to program, and will be extremely inconvenient to work with.

But an FPGA will score quite high on the 'cool' factor.

The STM32F411 has floating point, 16 analog inputs (multiplexed), DMA, gobs of other peripherals and runs at 100 MHz.  There are plenty of tools around for this chip series.  It looks like there are at least 9 channels of PWM, probably 12 as there are 12 timers.  There's 128k of SRAM (that's a LOT for an embedded application) and 256k or 512k of Flash.

https://www.st.com/en/microcontrollers-microprocessors/stm32f411.html

The Discovery board is just $15 and this board brings out a LOT of pins
https://www.digikey.com/product-detail/en/stmicroelectronics/STM32F411E-DISCO/497-15211-ND/5131480

The Nucleo board is just $14 and may be more useful in that it has an Arduino style layout (plus other headers)
https://www.digikey.com/product-detail/en/stmicroelectronics/NUCLEO-F411RE/497-14711-ND/4866485

Either of these boards would make a good starting point.  There are hundreds of alternatives but one of the nice things about the Nucleo board is that it is 'mbed' compatible.  There are varying opinions on the choice of web based development, and it certainly doesn't allow real-time hardware level debugging, but it also doesn't imply the use of STM's libraries which aren't universally well accepted.  If you're going to start from bare iron, there's nothing wrong with using the online compiler.  There is no need to install a toolchain and you can reach your source from any browser in the world.  Yes, I know, this will start a flame war among those who haven't used it.

This is a pretty small chip and without a block diagram, it is impossible to say whether it has enough IO.  But there are others in the family.

It really isn't hard to find a uC capable of handling this application.

[NiHaoMike]

You will probably get into floating point math at some point and this brings a lot of baggage to the FPGA solution.

Better to learn fixed point math since that's something that works on any microcontroller. Really, it's just like integer math except each step is something other than 1, usually much smaller.

[Berni]

Floating point math and FPGAs don't get along very well anyway.

It takes way more logic cells in a FPGA to build floating point adders and multipliers so this slows it down a lot and fills up the space in the FPGA quickly. Okay integer multiply is still a bit big to implement in logic, but for this reason FPGAs always have hardwired multiplier blocks, and those only work on fixed point.

This is no longer the case for MCUs tho!

For example a lot of the before mentioned STM32F4 F7 H7 etc have a hardware FPU for double precision float. This lets them do single precision MAC in 1 cycle or double precision MAC in 2 cycles. I was doing heavy FFT processing on a STM32H7 that was doing pretty hefty correlation on 16bit 2MSPS ADC data in real time. I tried both fixed and floating point to try and get the most speed i can out of it. Turned out single precision float was the fastest. This is likely because floating point has separate extra registers to work with and keeps other parts of the CPU free to shovel data around and count loops along with the fact that ARM CortexM7 doesn't really have any proper SIMD instructions for speeding up fixed point math.

[mac.6]

Take a look at dedicated microcontroller like NXP KV series. They are tailored for power and motor control.

[NorthGuy]

I tried both fixed and floating point to try and get the most speed i can out of it. Turned out single precision float was the fastest. This is likely because floating point has separate extra registers to work with and keeps other parts of the CPU free to shovel data around and count loops along with the fact that ARM CortexM7 doesn't really have any proper SIMD instructions for speeding up fixed point math.

If you have FP mac instruction, but not the integer mac instruction, then FP will certainly be faster at doing macs. I don't know if M7 has integer macs, but I suspect it doesn't.

There are very few cases where FP are really needed. In the majority of cases, integers will work better. If FPGA has integer DSP blocks, using FP instead of integers is pure madness (although it doesn't take as much logic as you describe).

There's absolutely no way a CPU can outperform FPGA in computing power. If your FPGA has 10 DSP blocks (such as the smallest $15 Spartan-7), running at modest 300 MHz, it'll give you 3G macs per second. You'll need a very big and expensive CPU to match that.

[rstofer]

Here's a quick video on using Xilinx HLS to implement floating point.  Sometimes the operations are synthesized, for others there are built in logic blocks.



XAPP599 covers the material in more depth:

https://www.xilinx.com/support/documentation/application_notes/xapp599-floating-point-vivado-hls.pdf

I succeeded in getting VHDL from a C file provided as an example.  I haven't gone any further and that's all I know about the process.  Exactly nothing...

But it seems like you create your application (or chunks of it) in C and convert it to VHDL using HLS.

There are several other videos...

Yes, fixed point is better/easier but only if the number range makes sense.  Also, fixed point code may not be obvious to the most casual observer.

[Berni]

Yes when it comes to DSP performance its hard to beat a FPGA, but i didn't quite need as much grunt in that project so i went with the STM32H7 and its pretty powerful for just a MCU. These MCUs are getting so fast that memory bandwidth is again becoming a problem like it was in computing 40 years ago. You can get quite noticeable speed improvements by keeping often used things in memory closer to the CPU, executing from RAM instead of flash, configuring caching correctly, doing things in ways that don't trash the cache so much etc.

I haven't investigated deeply in why float was faster. I was mostly using the CMSIS Math library provided by ARM that is hand optimized for these CPU families. The Cortex M7 does have a few different MAC instructions and can even do two 16bit multiplies in a single instruction so it sort of has SIMD but very narrow, but i have not looked into the cycle timings of them. My guess is that ether doing heavy integer math in rapid succession fills up the CPUs pipeline in a way that causes wait states because some component of the CPU gets too many things to do per cycle, or that the FFT library requires extra things around the math to prevent overflows. This perhaps adds extra scaling multiply operations, or uses the 64bit multiply result instruction that might be slower than a regular multiply. Just found it surprising that i couldn't get fixed point to run as fast as floating point, let alone faster. We always tended to associate float with being slow (Then again we used to not have FPUs and software float is horrendously slow).

I'm not trying to say FPGAs can't do float. Just that in most cases it makes more sense to use fixed point if speed is important. Its often better to simply use more bits and add scaling to accommodate large numbers and still have it run significantly faster and fit into a smaller cheaper FPGA. Tho these days there are some FPGAs that contain hardware floating point DSP blocks, so float is just as fast as integer there, tho this feature doesn't tend to come cheap.

[Sal Ammoniac]

I am designing a mini electric car model complete with a battery, charging controller, and mulitple BLDC or Induction motor controllers (I haven't decided which yet), and boost stages. I might do 4 motor controllers and see how to manipulate the controllers to make the car reverse and turn and stuff.

This is going to be a pretty long term project.

For the battery charger, I was just gonna use a LiPo charge controller IC, but to deliver all the switching signals to the boost converters, as well as the PWM or SPWM signals to the 4 motor controllers, I was wondering if I should use an FPGA.

Use an FPGA? It depends. Do you want to get something up and running quickly? If so, then a microcontroller coupled with a few commercial motor controller boards is the way to go.

If the purpose of this project is a learning experience, then by all means use an FPGA! Here's how I'd do it: I'd use an FPGA to implement motor sensor decoding and PWM generation for the motors. You can easily do this for four motors (and even more, if you needed to) with an FPGA. I'd then implement a slave-mode SPI port on the FPGA and use that to communicate PWM duty cycles from a microcontroller. I'd implement the rest of the control logic on the microcontroller (PI controller(s), etc.)

As you probably know, there are two basic categories of BLDC motors: sensored and sensorless. Sensored motors typically have three Hall sensors whose outputs change state every 60 degrees of motor rotation. Decoding the Hall outputs into one of six states and using that to generate PWMs would be relatively simple on an FPGA. Sensorless is a different kettle of fish altogether as you have to monitor the undriven phase with an ADC and sense the back EMF and use that to determine rotor position. Some FPGAs have built-in ADCs, but even so that makes things more complicated.

For induction motors, I wouldn't bother with an FPGA. Induction motors are typically driven with three sine waves 120 degrees out of phase using a technique called Field Oriented Control (FOC). Controlling three sinusoidally varying phases simultaneously with PI controllers requires a really fast micro and even then it's not easy. What you do is use Clark and Park transforms (and their inverses) to transform the three sinusoidally varying currents into two DC currents (Id and Iq). Controlling two DC currents with a PI controller is much easier. You typically use space vector modulation (SVM) to generate the three PWM outputs required to drive the motor. Just like with BLDC motors, you can get induction motors with and without rotor position sensors. While you can control an induction motor without a rotor position sensor, this is an advanced exercise--I'd recommend motors with quadrature or sine/cosine position sensors.

[Doctorandus_P]

BLDC motors are also driven with FOC.

Both ST and TI have loads of information of designing FOC based motor controllers for BLDC / PMSM (The'yre the same) and other uC manufacturers probably also have similar info, but I have not checked. They also sell demo board for such projects.

For this project I would not use an FPGA, but a single uC for every motor (controller) and an extra controller for "the rest".
Microcontrollers are cheap. You can buy a uC with specialized timers for motor control (3-phase output, dead time insertion in hardware) for EUR2 or so. There are many commercial controllers available, but also a number of high quality open source projects, and free stuff.
Just do a search for BLDC, or motor controller on github. Some of those projects may be a dump of sourcecode, while others are complete with nice documentation, schematics and PCB layouts.

Think about what direction you want to go. Designing / modifying a BLDC controller & software is doable, but it is not trivial and can easily be a project for a few months or half a year, with no guarantee you will get it to work by yourself.

If you're interested in FPGA's though, then buy some relatively cheap FPGA board anayway, and play with it. Having some decent experience with FPGA's looks good on your CV and will open more job opportunities for you.