Picking a DSP MCU for Power Conversion - Experiences?

[uer166]

One of the big reasons I'm not trying FPGAs for power conversion is lack of mixed-signal peripherals. I can get many opamps, comparators, DACs, and ADCs in a single STM32G4 that costs $3. All these analog peripherals are interconnected within the MCU fabric to create mostly autonomous control and it's much cheaper than having all that as separate ICs.

It is my understanding that currently there are no workable FPGAs that embed configurable analog logic and peripherals. While you can do anything you want in digital domain in an FPGA, you will need a bigger and more expensive solution overall since you'll need to provide all the analog glue.

[gnuarm]

One of the big reasons I'm not trying FPGAs for power conversion is lack of mixed-signal peripherals. I can get many opamps, comparators, DACs, and ADCs in a single STM32G4 that costs $3. All these analog peripherals are interconnected within the MCU fabric to create mostly autonomous control and it's much cheaper than having all that as separate ICs.

It is my understanding that currently there are no workable FPGAs that embed configurable analog logic and peripherals. While you can do anything you want in digital domain in an FPGA, you will need a bigger and more expensive solution overall since you'll need to provide all the analog glue.

That is true.  Only one company has an FPGA with significant analog components, but it is expensive.  I'm not familiar with the devices you are talking about.  I assume the analog must be fairly low end as it is not easy to mix quality analog with quality digital.  Every such device I've ever seen has compromises in either the analog, the digital or both. 

Cypress has PSOC devices with an MCU, programmable analog and digital.  Not an FPGA, but their first generation were pretty limited devices.  The CEO insisted they pull out all the stops and build a combined chip with "No Excuses!"  What they got was ok, but still nothing special. 

If saving the cost of the low end analog is significant then I suppose FPGAs are not for you.  But don't think you can't do ADC and DAC in FPGAs.  I think I mentioned I am presently working on ADC and DAC in an FPGA design.  The ADC are reading sensors and the DAC is to drive audio output.  Not high end, but adequate.   This is all a soft design, not using any hard IP in the chip.  Oh, most FPGAs do have comparators.  They call them LVDS receivers, but they work very well and high speed!  That's the inputs for the ADCs I'm building.

[sandalcandal]

Thanks for the detailed response gnuarm!

One issue with comparing FPGAs based on price is that the vendors only give discounted (meaning realistic) prices by quote.  The numbers you see at distributors' web sites are typical qty 1 pricing with no one giving numbers for qty 1k.  LCSC has amazing prices for some Spartan 6 devices in the $5 range (XC6SLX16-2FTG256C, big enough for literally any DSP effort you might want to tackle, 32 DSP units), but I don't know for sure they are through proper channels.  I personally have been given prices that were less than half the qty 1 list price.  If I were a large company buying 10's or 100's of thousands, I could do better.

Interesting to hear FPGAs can be had so much cheaper from non-authorised sources. The lack of freely available quantity pricing is also a bit strange. Any ideas why? Can you say what qty you were asking to get discounted quotes? The 1ku being less than half the single unit cost isn't unusual or any different for MCUs. Even at a third of the $26 single unit price, the XC6SLX16-2FTG256C is still much more expensive than available MCU options which are close to $6 single unit price manufacturer direct.

You can construct any peripheral you wish from the FPGA fabric, even ADC.  I am presently working on an ADC for a ventilator.  It only needs to sample at 200 SPS, but it will be high resolution.

[...] Only one company has an FPGA with significant analog components, but it is expensive.  I'm not familiar with the devices you are talking about.  I assume the analog must be fairly low end as it is not easy to mix quality analog with quality digital.  Every such device I've ever seen has compromises in either the analog, the digital or both. 

Cypress has PSOC devices with an MCU, programmable analog and digital.  Not an FPGA, but their first generation were pretty limited devices.  The CEO insisted they pull out all the stops and build a combined chip with "No Excuses!"  What they got was ok, but still nothing special. 

If saving the cost of the low end analog is significant then I suppose FPGAs are not for you.  But don't think you can't do ADC and DAC in FPGAs.  I think I mentioned I am presently working on ADC and DAC in an FPGA design.  The ADC are reading sensors and the DAC is to drive audio output.  Not high end, but adequate.   This is all a soft design, not using any hard IP in the chip.  Oh, most FPGAs do have comparators.  They call them LVDS receivers, but they work very well and high speed!  That's the inputs for the ADCs I'm building.

I don't doubt you can flexibly implement nearly any digital function in FPGA fabric but as mentioned by uer166, integrated analog peripherals such as programmable gain amplifiers, comparators, fast high-res DACs and ADCs are all important peripherals for the application being discussed (digital power conversion) and these peripherals come integrated in DSP MCUs. You don't seem convinced yourself that such required functions can be had more efficiently by using an FPGA based solution.

Conversely, these DSP MCUs particularly the TI C2000 family (including the aforementioned $3.55 TMS320F280049) feature "Control Law Accelerators" that perform math processing independent of the CPU and configurable logic blocks which enable "the calculations to be done in a more logic oriented way". Admittedly, some of the digital design knowledge avoided by using vanilla MCUs is required here but the disadvantages in processing power compared to FPGAs is narrowed whilst still being overall more efficient in cost (and part count, footprint etc.).

I've never needed licensed IP.  There's so much open source or I write my own.  What examples?

True, I should have realised there would be plenty of open sources IP cores out there though I lack familiarity. Do you have preferred communities/collections?

I have no idea what you mean about configuration errors???  Configuration is similar to a CPU booting code, but more simple.  What is your concern?

I won't argue that there aren't more sequential software programmers than HDL programmers.  So sure, you will find one more easily. 

Configuration errors are one failure point I've seen in discussion of FPGA reliability and would seem more different compared to a program memory error in an MCU? (not the crux of my point though) I don't doubt one can learn and use good practice to avoid device/design failures but my point is there are barriers to obtaining competency. These barriers are present regardless of whether or not they "should be" present in industry but they are there and I'm not about to go changing the status quo. If you have specific training or resources you would recommend for helping bring an engineer up to scratch though, I would love to hear.

... FPGAs by their nature have fewer problems (if any) with real time work and that's the real difficulty in this work, finding people who can program real time control...

...
I would point out that part of this thread is discussing how hard it is to meet real time requirements in DSP and MCUs.  That's not a problem with FPGAs, not much of a consideration really.  You just focus on your computations and the speed comes for free.

This I'm not so convinced about. My take from discussion in this thread (as well as the other thread) was that I was over estimating the performance needs and digital power conversion can be achieved with less performance and features than I thought necessary or otherwise nice.

I'm still unconvinced FPGAs would be a better solution or the majority of my concerns are invalid. There's a bit of how long is a piece of string but it still doesn't look to me like FPGAs are a better cost-performance choice to meet my requirements by any means.

None the less, thankyou for your responses and I'll edit my OP to link your differing opinions.

[gnuarm]

Thanks for the detailed response gnuarm!

One issue with comparing FPGAs based on price is that the vendors only give discounted (meaning realistic) prices by quote.  The numbers you see at distributors' web sites are typical qty 1 pricing with no one giving numbers for qty 1k.  LCSC has amazing prices for some Spartan 6 devices in the $5 range (XC6SLX16-2FTG256C, big enough for literally any DSP effort you might want to tackle, 32 DSP units), but I don't know for sure they are through proper channels.  I personally have been given prices that were less than half the qty 1 list price.  If I were a large company buying 10's or 100's of thousands, I could do better.

Interesting to hear FPGAs can be had so much cheaper from non-authorised sources. The lack of freely available quantity pricing is also a bit strange. Any ideas why? Can you say what qty you were asking to get discounted quotes? The 1ku being less than half the single unit cost isn't unusual or any different for MCUs. Even at a third of the $26 single unit price, the XC6SLX16-2FTG256C is still much more expensive than available MCU options which are close to $6 single unit price manufacturer direct.

Yeah, there are other devices at that price or lower.  I just mentioned that one because it's on the LCSC site and can be assembled by JLCPCB I believe. 

The close to the vest pricing is a result of the FPGA market being dominated by the major telcom equipment makers.  They buy the big dollar chips giving the vendors their biggest profits.  That's why FPGAs are right up there with the mainstream CPU makers on the leading edge technology.  That promotes very competitive pricing, but not giving anything to the enemy that you don't have to.  So no public pricing. 

Some years back I worked on a product by my company that I expected to sell a couple thousand per year.  This was the time of the dot-com bubble and the vendors were eager to get any startup they could, literally.  A few months before I had interviewed with a startup in Rockville, MD and in six months they no longer existed.  lol 

The other quotes I got were working for a  telcom test equipment maker who was a big account of both FPGA vendors.  They did not focus on one group specifically so they could continue to beat one against the other on price. 

I don't think I've ever worked on anything where the difference in price of a dollar or two was a deal breaker.  I guess my jobs have been different than yours.  I try to work in ways I have confidence will work.  I've seen lots of MCU projects have issues from timing, problems that just don't exist in FPGAs. 

In the sort of stuff I've built the FPGA does the real work and the MCU handles the user and I/O interfaces like USB updates, etc.

You can construct any peripheral you wish from the FPGA fabric, even ADC.  I am presently working on an ADC for a ventilator.  It only needs to sample at 200 SPS, but it will be high resolution.

[...] Only one company has an FPGA with significant analog components, but it is expensive.  I'm not familiar with the devices you are talking about.  I assume the analog must be fairly low end as it is not easy to mix quality analog with quality digital.  Every such device I've ever seen has compromises in either the analog, the digital or both. 

Cypress has PSOC devices with an MCU, programmable analog and digital.  Not an FPGA, but their first generation were pretty limited devices.  The CEO insisted they pull out all the stops and build a combined chip with "No Excuses!"  What they got was ok, but still nothing special. 

If saving the cost of the low end analog is significant then I suppose FPGAs are not for you.  But don't think you can't do ADC and DAC in FPGAs.  I think I mentioned I am presently working on ADC and DAC in an FPGA design.  The ADC are reading sensors and the DAC is to drive audio output.  Not high end, but adequate.   This is all a soft design, not using any hard IP in the chip.  Oh, most FPGAs do have comparators.  They call them LVDS receivers, but they work very well and high speed!  That's the inputs for the ADCs I'm building.

I don't doubt you can flexibly implement nearly any digital function in FPGA fabric but as mentioned by uer166, integrated analog peripherals such as programmable gain amplifiers, comparators, fast high-res DACs and ADCs are all important peripherals for the application being discussed (digital power conversion) and these peripherals come integrated in DSP MCUs. You don't seem convinced yourself that such required functions can be had more efficiently by using an FPGA based solution.

You use programmable gain amplifiers for control functions???  How do you handle the variable scale factor in the software? 

As I mentioned, pretty much every FPGA has comparators built in. 

When you say fast and high res ADC and DACs, how high and fast are you talking?   I've never seen that in any sort of MCU/DSP device.  I've seen lots of 1 MHz 12 bit ADCs and 16 bit sigma-delta converters, but they are usually not so fast.

Conversely, these DSP MCUs particularly the TI C2000 family (including the aforementioned $3.55 TMS320F280049) feature "Control Law Accelerators" that perform math processing independent of the CPU and configurable logic blocks which enable "the calculations to be done in a more logic oriented way". Admittedly, some of the digital design knowledge avoided by using vanilla MCUs is required here but the disadvantages in processing power compared to FPGAs is narrowed whilst still being overall more efficient in cost (and part count, footprint etc.).

I don't claim the speed of FPGAs are what the advantages are about.  It is the ease of coordinating the calculations without worrying that sharing a CPU between tasks will mess up timing.  Interrupts are a necessary evil in CPUs.  But they really mess with hard real time design. 

I've never needed licensed IP.  There's so much open source or I write my own.  What examples?

True, I should have realised there would be plenty of open sources IP cores out there though I lack familiarity. Do you have preferred communities/collections?

What are you referring to exactly?  If you mean CPU designs, I don't use them. 

I have no idea what you mean about configuration errors???  Configuration is similar to a CPU booting code, but more simple.  What is your concern?

I won't argue that there aren't more sequential software programmers than HDL programmers.  So sure, you will find one more easily. 

Configuration errors are one failure point I've seen in discussion of FPGA reliability and would seem more different compared to a program memory error in an MCU? (not the crux of my point though) I don't doubt one can learn and use good practice to avoid device/design failures but my point is there are barriers to obtaining competency. These barriers are present regardless of whether or not they "should be" present in industry but they are there and I'm not about to go changing the status quo. If you have specific training or resources you would recommend for helping bring an engineer up to scratch though, I would love to hear.

I don't know what you are talking about with the configuration errors.  That is what happens when you are working in the lab perhaps but otherwise they configure just fine.  In fact, in space applications a problem is radiation induced soft errors altering the configuration.  Rather than trying to fix or prevent them they periodically reconfigure the FPGA which clears out the soft errors.  I thought that was pretty crazy, but they design the system so any part can be shut down without impacting anything else.  So the FPGA can be taken off line for a few milliseconds to reconfigure every minute or so to mitigate the soft errors.  If configuration was not reliable obviously this would not work.

... FPGAs by their nature have fewer problems (if any) with real time work and that's the real difficulty in this work, finding people who can program real time control...

...
I would point out that part of this thread is discussing how hard it is to meet real time requirements in DSP and MCUs.  That's not a problem with FPGAs, not much of a consideration really.  You just focus on your computations and the speed comes for free.

This I'm not so convinced about. My take from discussion in this thread (as well as the other thread) was that I was over estimating the performance needs and digital power conversion can be achieved with less performance and features than I thought necessary or otherwise nice.

I'm still unconvinced FPGAs would be a better solution or the majority of my concerns are invalid. There's a bit of how long is a piece of string but it still doesn't look to me like FPGAs are a better cost-performance choice to meet my requirements by any means.

None the less, thankyou for your responses and I'll edit my OP to link your differing opinions.

It's not really speed as such.  It's the issues created from trying to make a sequential processor look like it is doing things in parallel while in an FPGA things can literally happen in parallel.  In essence, FPGAs take the "hard" out of hard real time.  Consider it risk mitigation.  That's the sort of thing I focus on rather than extracting the last penny from the BoM.

I never have a problem with the labor pool.  I'm the labor pool. 

[Siwastaja]

FPGA is a dream device for designing power conversion controllers, such controllers tend to be relatively simple when drawn as a logic diagram, and such diagram can be transferred to HDL almost directly. Often there is no complex state, so a perfect fit for FPGA. The question about "peripherals" is weird, peripherals are the fixed parts in the MCUs that try to address certain common needs. With FPGA, you write your own logic, you can do anything with it, and because it can be just application-specific and nothing more, the logic design will be much simpler than what the MCU peripherals internally are.

Why I never use FPGA for power conversion projects? Some reasons come into mind,
1) FPGAs are more expensive. Even if you can find a $5 deal and it happens to work out, it's still more expensive than a $2 MCU,
2) Most FPGAs require external ICs like configuration memory/controller, or multiple voltage domains, not all of course,

but even more importantly,
3) they tend not to come with built-in SAR ADCs, comparators, opamps, etc., so you need even more external parts,

and finally,

4) the microcontroller designers have come up with quite some good power conversion peripherals that happen to do the job for me, so there is no need to DIY it on FPGA.

So, for 99% of power conversion needs, you can buy a classical dedicated IC. For the rest 0.99%, something like STM32F334 does it fine, and for the remaining 0.0099%, you can then use an FPGA, and then for 0.0001%, better to design a full custom mixed signal ASIC.

[Siwastaja]

Remember that a cheaper CPLD may be an option, too. They are widely used in actual power conversion devices like inverters etc. Even fairly complex power conversion could often be implemented with some 20-30 standard 74 logic gate ICs. It would be insane to do it that way today, but it gives the idea of the amount of the logic needed, and CPLD provides enough resources and reconfigurability.

FPGAs are marketed towards larger tasks, think about image processing and such.

[gnuarm]

FPGA is a dream device for designing power conversion controllers, such controllers tend to be relatively simple when drawn as a logic diagram, and such diagram can be transferred to HDL almost directly. Often there is no complex state, so a perfect fit for FPGA. The question about "peripherals" is weird, peripherals are the fixed parts in the MCUs that try to address certain common needs. With FPGA, you write your own logic, you can do anything with it, and because it can be just application-specific and nothing more, the logic design will be much simpler than what the MCU peripherals internally are.

Thank you for clarifying FPGA advantages better than I did.  I find FPGA work to be so simple because of what you said.  I tend to think in terms of diagrams and the ease of implementing such a clear image is what makes FPGAs my first choice for most projects.

Why I never use FPGA for power conversion projects? Some reasons come into mind,
1) FPGAs are more expensive. Even if you can find a $5 deal and it happens to work out, it's still more expensive than a $2 MCU,

The $5 number was one I picked because it was a low water mark for a well known brand, Xilinx.  There are other brands that are even cheaper.  I have quotes on Gowin devices that are closer to $3 and there are a number of devices available on Digikey or Mouser that reach that price point or lower.  Not very large devices, but I don't expect size to be a big factor in most controller designs.

Like I said, I don't recall working on a design where $1 difference in price was a deal breaker.  So that's not the domain of my experience. 

2) Most FPGAs require external ICs like configuration memory/controller, or multiple voltage domains, not all of course,

Again, that's not always true as you say yourself.  So it really shouldn't be included.  Lattice and Microsemi have lines with programmable memory on chip.  Gowin devices work with internal Flash and even provide some for use by the user program without use block RAM.  There are many choices with a single voltage domain if you choose that or will work with multiple I/O voltages simultaneously. 

The big manufacturers X and A(Intel now) focus on the high end for telcom work and so pretty much ignore internal flash.  The low end market options are expanding with more and more devices and lower prices. 

but even more importantly,
3) they tend not to come with built-in SAR ADCs, comparators, opamps, etc., so you need even more external parts,

Op amps???  They don't include the voltage regulator or level shifters or many other features that are not suitable for inclusion on digital devices.  I read the Picolo data sheet someone referred to and the built in 12 bit ADC is functionally a 10 bit device.  It is fast, about 2.5 MSPS, but with multiple inputs is shared across all inputs lowering the effective sample rate and not simultaneous sampling.  At slower rates, say 100 kHz, a 10 bit ADC can be constructed on a sigma-delta structure with good performance and a full converter can be dedicated to each channel.  The logic required is minimal and it includes an antialias filter.  Add an external one pole filter and you are good.  You can't say that with the SAR converters built into the various MCUs/DSPs.   

I think the peripheral issue is a bit overstated. 

and finally,

4) the microcontroller designers have come up with quite some good power conversion peripherals that happen to do the job for me, so there is no need to DIY it on FPGA.

What peripherals do you mean?  PWM?  That is trivial.  What else do you use that comes in a controller chip?  What is ignored is the complexity of using these controller devices.  Someone mentioned in another thread how an MCU manual was 300 pages and someone else pointed out that was a small one with some manuals being in the kilopages range.  Sure you can use libraries, but does that really make them "easy" to use or just add bugs where you can't see them easily?  I'm working a ventilator project where they used a PWM through the library code.  It took significant effort to figure out if the limitations were in the code or in the chip.  Most of the time they didn't know how it was even working since they were using the library code essentially blind.

Roll your own peripherals and you know how they work and where the limitations are.  It's not at all hard and 99% of the debugging is done in simulation.  I've never figured out why more software isn't debugged in simulation where it is so much easier to control the testing.

So, for 99% of power conversion needs, you can buy a classical dedicated IC. For the rest 0.99%, something like STM32F334 does it fine, and for the remaining 0.0099%, you can then use an FPGA, and then for 0.0001%, better to design a full custom mixed signal ASIC.

To each his own.  For me you have to show me why an FPGA is not the right choice.  I'm considering rolling an eval/experimenting board with a Gowin FPGA.  I would be interested in suggestions on what it should include to be useful for control work.

[gnuarm]

Remember that a cheaper CPLD may be an option, too. They are widely used in actual power conversion devices like inverters etc. Even fairly complex power conversion could often be implemented with some 20-30 standard 74 logic gate ICs. It would be insane to do it that way today, but it gives the idea of the amount of the logic needed, and CPLD provides enough resources and reconfigurability.

FPGAs are marketed towards larger tasks, think about image processing and such.

I don't know what you consider to be an FPGA vs. CPLD.  I don't make a distinction and most vendors blur the line.  Many CPLDs use an FPGA architecture internally (4 input LUT and FF), so are just small FPGAs. 

No point in making that distinction really.  It's all programmable logic.

[uer166]

Can your FPGA "peripherals" generate a PWM waveform with resolution that is equivalent to running at 4.7GHz? Because that's what most hi res  PWM generators do in MCUs with no clock actually running that quick (they use analog delay locked loops). Can your PWM generator react asynchronously to an event without waiting for the next clock edge? That's also what the comparator/PWM peripheral combo can do.

The analog features are not overstated, IMO a good converter is 50/50 digital/analog design. And yes, opamps! They can be used as PGAs or analog integrators or even comparators, whatever you want. Most have plenty of performance for any reasonable converter design.

This not only saves component cost but also board space since most of the analog interconnects can be internal. There is a reason why pretty much all commercial power conversion I've seen (up to many 100kW, including drive inverters in EVs) use TMS320 with maybe a small CPLD for interlocks and such.

[Siwastaja]

Well I understand the point that it may be easier to write exactly what you need in HDL, when you compare it to reading 300 pages out of the 2000-page reference manual of an MCU to figure out and debug how to configure the MCU peripherals to do the same.

Somehow, still, I have good success working with the MCUs.

Yes, I can likely write my own SPI peripheral implementation in VHDL in less time than to work around the broken beyond imagination SPI implementation of STM32...

I did FPGA-based motor inverter, for example, back some ten years ago, but since then, I have just worked with MCUs doing the same, and more.

Things could have gone completely different; I could be here praising the bliss of doing it with FPGA, and pointing out how difficult it is to use an MCU.

One point we are missing here is that you often tend to need complex state and information processing like things, those that are really really tedious to write in hardware, and trivial in software. When using an MCU, a single part does both things; the power conversion mostly on HW peripherals, guided by a little bit of software. Then adding more software for "everything else" usually isn't a problem. In FPGA, you would be adding a softcore, and defining communication between it and your own "peripherals", and you would be still writing software, too. Not saying this is fundamentally difficult, but something to consider. If the available MCU peripherals are good enough (even if suboptimal), you'll have an off-the-shelf solution where you don't need to write a single line of HDL - or think about learning a new skill, many have zero experience on digital logic design / writing HDL.

Finally, FPGA performance may be a bit iffy for power conversion. As stated, MCUs do have those asynchronous break signals and 4-GHz equivalent PWM modules. It's questionable whether you can do those with FPGAs, especially cheap ones, without adding external analog components.

[sandalcandal]

Thanks for the great discussion guys.

I think a point being missed by gnuarm on opamps and related analog front end peripherals is the need for opamps and analog functions implemented using opamps (PGAs, voltage offsets, comparators etc.) in order to do required analog front end before you get to an ADC. For example the voltage signal levels coming from a current transformer or more so a current shunt aren't going to be legible to a soft ADC without some form of preamp. If you want to regulate/measure any AC signal then you'll need either a rectifer+polarity sensing front end or you need to add a DC offset to keep the signal over 0 V. Alternatively for a signal with a large DC offset such as if you are attempting to regulate a DC voltage over a limited range then you'll want to get rid of that DC offset so you're not wasting 0v to x range on the ADC.

It seems most FPGAs have some integrated comparators at best to implement analog to digital interfacing?

It is fast, about 2.5 MSPS, but with multiple inputs is shared across all inputs lowering the effective sample rate and not simultaneous sampling.  At slower rates, say 100 kHz, a 10 bit ADC can be constructed on a sigma-delta structure with good performance and a full converter can be dedicated to each channel.  The logic required is minimal and it includes an antialias filter.  Add an external one pole filter and you are good.  You can't say that with the SAR converters built into the various MCUs/DSPs.   

With the limited number of ADCs that isn't a problem for the MCUs I've been looking at. Three ADCs at 12 bit 3.5 MSPS (as per my previously linked TMS320F280049) is sufficient and I'm not going to be splitting that down to 0.1MSPS 10-bit effective in a single channel power converter but perhaps that would be possible in a many-channel teleco board power supply. Sample rate directly places a limit on control loop speed and potentially affects stability so it is hardly a component that can be overstated. It is possible to keep within safe operating parameters with a slower control loop but doing so requires significantly larger and more expensive power passive components.

The discussion seems quite biased in favour of MCUs but I can start to see how FPGAs might not be as far out as I thought in terms of how suitable they are for use in my application.

[poorchava]

FPGA/CPLD is a good option provided, that the ADC is sorted out. Or ADCs plural.

I recall designing an 8 phase 200A/1kW Dc/Dc precision current source. I had to measure current through every single inductor and also measure like 5 other values, most of them every cycle. And the use individual HRPWMs to drive the phases. Ended up doing it on TMS320F28069. This ran at 300kHz, but the control loop was in kHz range (we were able to get away with that

FPGA would make sense if really fast multichannel ADCs were used. Like Quad channel or more. Either simultaneous sampling or even better 4 ADCs in single package. Such parts tend to be on the expensive side.

[NiHaoMike]

FPGA would make sense if really fast multichannel ADCs were used. Like Quad channel or more. Either simultaneous sampling or even better 4 ADCs in single package. Such parts tend to be on the expensive side.

Depending on your definition of "fast" and "expensive", an AK5558 provides 8 channels of 768kHz for about $5. I'm using two of those in my solar inverter, the inverter module has a total of 6 AC channels so 12x ADC channels for voltage and current sensing. The remaining 4 channels are used for two I/Q channel pairs from the coherent diversity PLC receiver front end. The last bit is the part where a FPGA makes a lot more sense than a microcontroller for my application. The reason the PLC receiver is needed at all is because it's a zero export inverter which uses a PLC transmitter to relay the mains current waveforms, to which the inverter has to respond with a current to more or less cancel out the load current. The FPGA doing each stage of that at the same time (decode the PLC signal, calculate the current to source, adjust the PWM signal to reach that calculated current) makes it a lot easier to minimize latency than with a microcontroller that can only do those one at a time. (I suspect the latency requirement is why the zero export inverters on the market that support external current sensors require dedicated wiring for those sensors.)

[Marco]

an AK5558 provides 8 channels of 768kHz for about $5.

With somewhere between 19 and 5 cycles of group delay depending on the decimation filter ... not ideal.

[sandalcandal]

FPGA/CPLD is a good option provided, that the ADC is sorted out. Or ADCs plural.

I recall designing an 8 phase 200A/1kW Dc/Dc precision current source. I had to measure current through every single inductor and also measure like 5 other values, most of them every cycle. And the use individual HRPWMs to drive the phases. Ended up doing it on TMS320F28069. This ran at 300kHz, but the control loop was in kHz range (we were able to get away with that

FPGA would make sense if really fast multichannel ADCs were used. Like Quad channel or more. Either simultaneous sampling or even better 4 ADCs in single package. Such parts tend to be on the expensive side.

Are there any challenges in managing ADC to FPGA latency and bandwidth?

[gnuarm]

Thanks for the great discussion guys.

I think a point being missed by gnuarm on opamps and related analog front end peripherals is the need for opamps and analog functions implemented using opamps (PGAs, voltage offsets, comparators etc.) in order to do required analog front end before you get to an ADC. For example the voltage signal levels coming from a current transformer or more so a current shunt aren't going to be legible to a soft ADC without some form of preamp. If you want to regulate/measure any AC signal then you'll need either a rectifer+polarity sensing front end or you need to add a DC offset to keep the signal over 0 V. Alternatively for a signal with a large DC offset such as if you are attempting to regulate a DC voltage over a limited range then you'll want to get rid of that DC offset so you're not wasting 0v to x range on the ADC.

It seems most FPGAs have some integrated comparators at best to implement analog to digital interfacing?

I am not in the control business, so I am not familiar with the specialized chips available for control.  I do know that in general, analog that is incorporated on digital chips is not the highest quality or performance.  The analog interfacing I've done in the past did not require real time adjustments to the analog path in real time.  Gains were set and forget!  So unless they require special handling low cost op amps and fixed gain are perfectly adequate.  In fact, for another thread I just provided a circuit to rectify the analog input and present only a positive half signal in a single op amp and a few resistors, not diode.  Are you suggesting these specialized chips have rectifier circuits built in for measuring AC signals?  I've never seen that in any chip. 

I can design an analog input to an FPGA ADC that will accept bipolar inputs without a single op amp.  Passives only.  It may lose some resolution.  I'd need to work out the details. 

It is fast, about 2.5 MSPS, but with multiple inputs is shared across all inputs lowering the effective sample rate and not simultaneous sampling.  At slower rates, say 100 kHz, a 10 bit ADC can be constructed on a sigma-delta structure with good performance and a full converter can be dedicated to each channel.  The logic required is minimal and it includes an antialias filter.  Add an external one pole filter and you are good.  You can't say that with the SAR converters built into the various MCUs/DSPs.   

With the limited number of ADCs that isn't a problem for the MCUs I've been looking at. Three ADCs at 12 bit 3.5 MSPS (as per my previously linked TMS320F280049) is sufficient and I'm not going to be splitting that down to 0.1MSPS 10-bit effective in a single channel power converter but perhaps that would be possible in a many-channel teleco board power supply. Sample rate directly places a limit on control loop speed and potentially affects stability so it is hardly a component that can be overstated. It is possible to keep within safe operating parameters with a slower control loop but doing so requires significantly larger and more expensive power passive components.

The required control loop speed depends entirely on the speed required.  The switching speed is often not much higher than 100 kHz.  You can't run your control loop faster than the switching rate.

The discussion seems quite biased in favour of MCUs but I can start to see how FPGAs might not be as far out as I thought in terms of how suitable they are for use in my application.

Mostly the issue is that people have many prejudices and misinformation about FPGAs as being power hungry, large, expensive and hard to work with.  Clearly there is an advantage to using devices that are specially designed for control loops.  I was surprised to see the price on the Picolo.  When I look at the chips some years ago they were MUCH more expensive with some versions over $40. 

Still, the one big advantage of FPGAs is the one many people think is a disadvantage, programming.  Yes, if you know nothing about programming hardware you will not do well with an HDL.  But an HDL relieves the programmer of dealing with the complications of trying to share a single, sequential processor between multiple tasks.  Even when you have lots of processor speed to spare, the coordination between tasks can be complex.  I've never had a problem with any of that in an FPGA.  Digital hardware doesn't need to be designed that way. 

[Siwastaja]

Quite frankly, if you really need custom power conversion, I think FPGA is better in almost every regard.

But does A being better than B matter if B is good enough?

Most of use are just familiar with microcontrollers so they are an easy solution, and if they do the job well enough, why bother learning a new skill?

I'm going immediately for FPGA for power conversion when I actually hit a project where the MCU simply doesn't cut it. As long as that doesn't happen, I'm happy working with MCU-based custom power conversion.

[gnuarm]

I think I am hearing from multiple points of view that are rather orthogonal and not at all compatible.  Some are talking about the high integration available in specialized controllers while others talk about the low pricing of MCUs.  However, these two issues can't be combined in a single part that I can see. 

I checked out the data sheet for the MAX22000ALB+.  It is a very capable part with lots of good peripherals and analog functions which seem capable, however, not what some would seem to claim.  I saw 24 bit ADCs mentioned which actually surprised me.  I've only seen that sort of resolution in audio work where they really are not 24 useful bit widths, rather the SINAD numbers put them closer to 20 bits and of course limited sample rates.  Then people talk about 2.5 MSPS rates, but more like 12 bit converters with 10 useful bits.  The MAX22000ALB+ ADC is 24 bits with a sample rate up to 115 kSPS and specified at under 60 kSPS.  The specs on the ADC seem to indicate about 16 useful bits.  So no high speed power supply control for this part.  It's also $30 in qty, so the $3 prices are clearly for a less capable part.

[gnuarm]

Quite frankly, if you really need custom power conversion, I think FPGA is better in almost every regard.

But does A being better than B matter if B is good enough?

Most of use are just familiar with microcontrollers so they are an easy solution, and if they do the job well enough, why bother learning a new skill?

I'm going immediately for FPGA for power conversion when I actually hit a project where the MCU simply doesn't cut it. As long as that doesn't happen, I'm happy working with MCU-based custom power conversion.

That is exactly my point.  Your goto solution for control is MCU oriented because your goto solution for control is MCU oriented. 

My point is the preferences are based on your personal experience rather than what is actually best.  I don't have that bias or you could say my bias is opposite.  I find dealing with emulating parallel tasks on a sequential processor to be problematic while parallel tasks in an FPGA is of literally no consequence. 

Your initial premise is that FPGAs are "better in almost every regard".  I'm not sure you really believe that.  If you did, it seems a folly to continue making the same "wrong" choice for every project you do.  I think you may be summarizing a few advantages you perceive as quite small.  Otherwise it would only make sense to spend a bit of effort to make FPGAs your goto solution for control.

[gnuarm]

FPGA would make sense if really fast multichannel ADCs were used. Like Quad channel or more. Either simultaneous sampling or even better 4 ADCs in single package. Such parts tend to be on the expensive side.

Depending on your definition of "fast" and "expensive", an AK5558 provides 8 channels of 768kHz for about $5. I'm using two of those in my solar inverter, the inverter module has a total of 6 AC channels so 12x ADC channels for voltage and current sensing. The remaining 4 channels are used for two I/Q channel pairs from the coherent diversity PLC receiver front end. The last bit is the part where a FPGA makes a lot more sense than a microcontroller for my application. The reason the PLC receiver is needed at all is because it's a zero export inverter which uses a PLC transmitter to relay the mains current waveforms, to which the inverter has to respond with a current to more or less cancel out the load current. The FPGA doing each stage of that at the same time (decode the PLC signal, calculate the current to source, adjust the PWM signal to reach that calculated current) makes it a lot easier to minimize latency than with a microcontroller that can only do those one at a time. (I suspect the latency requirement is why the zero export inverters on the market that support external current sensors require dedicated wiring for those sensors.)

Sorry to hear you are using an AKM part in your product.  I am also and their factory fire has cut me off from all supply.  A part that was $3 is now $60 on Alibaba. 

Have you gotten any of these parts lately?

[Siwastaja]

I think I am hearing from multiple points of view that are rather orthogonal and not at all compatible.  Some are talking about the high integration available in specialized controllers while others talk about the low pricing of MCUs.  However, these two issues can't be combined in a single part that I can see.

I think they are pretty well combined.

STM32F334 is a good example IMHO, it's $3 and comes with two independent 5 MSPS 12-bit SAR ADCs with differential inputs, three 1MSPS 12-bit DACs (these can feed internal comparators for peak current limit setpoints etc, and being 1MSPS and fed from DMA, you can do arbitrary waveforms on peak current limit, for example!), three analog comparators that are super fast and can bypass the synchronous logic for those really quick current limits, opamp with PGA, the 4-GHz equivalent 5 or 10 channel (depending on how you count it) timer/PWM module with a lot more configurability than traditional MCU timers, another PWM module capable of driving 6 phase converter or two 3-phase motors with pulse-by-pulse current feedback...

Many of these peripherals can be combined / routed to work together, typical example would be the DAC driving one of the comparator inputs and the comparator output controlling the PWM timer module.

What it is lacking is basically just slower, higher resolution ADCs (some others come with those, usually delta-sigma). So no complete integration if you need that, but pretty close.

And, they have added a core-coupled memory for fast and predictable execution of timing-critical routines, this isn't standard in Cortex-M4 product line.

This sounds like an advertisement, right, but just saying this part satisfies most power conversion needs I can think of and does it cheaply.

[NiHaoMike]

Sorry to hear you are using an AKM part in your product.  I am also and their factory fire has cut me off from all supply.  A part that was $3 is now $60 on Alibaba. 

Have you gotten any of these parts lately?

Luckily, it's a one off prototype and I ordered the chips while they were commonly available. For production, such a high end ADC is overkill and most likely Delta Sigma ADCs built around the LVDS receivers in the FPGA would perform well enough, maybe a separate ADC for just the PLC receiver. I don't have any plans to make a production version, since aside from the regulatory issues surrounding a mains connected product that uses custom circuits interfaced to mains, I don't think very many see the value in an all in one box that handles solar MPPT, backup power, VFD for thermal storage, and home automation/energy management.

[uer166]

You can't run your control loop faster than the switching rate.

Sure you can, the required bandwidth for even plain old peak current mode control or hysteretic control is well into the 100s of MHz, and that's kind of the point I was trying to make. Dead time generation using HRTIM? That's in the GHz. Peripherals in these MCUs (really they're kind of almost ASICs with a nice MCU for configuration and light DSP) make that possible. A fully synchronous FPGA with ADCs bolted on can do none of that without a bunch of extra analog and digital stuff.

[gnuarm]

I think I am hearing from multiple points of view that are rather orthogonal and not at all compatible.  Some are talking about the high integration available in specialized controllers while others talk about the low pricing of MCUs.  However, these two issues can't be combined in a single part that I can see.

I think they are pretty well combined.

STM32F334 is a good example IMHO, it's $3 and comes with two independent 5 MSPS 12-bit SAR ADCs with differential inputs, three 1MSPS 12-bit DACs (these can feed internal comparators for peak current limit setpoints etc, and being 1MSPS and fed from DMA, you can do arbitrary waveforms on peak current limit, for example!), three analog comparators that are super fast and can bypass the synchronous logic for those really quick current limits, opamp with PGA, the 4-GHz equivalent 5 or 10 channel (depending on how you count it) timer/PWM module with a lot more configurability than traditional MCU timers, another PWM module capable of driving 6 phase converter or two 3-phase motors with pulse-by-pulse current feedback...

Many of these peripherals can be combined / routed to work together, typical example would be the DAC driving one of the comparator inputs and the comparator output controlling the PWM timer module.

What it is lacking is basically just slower, higher resolution ADCs (some others come with those, usually delta-sigma). So no complete integration if you need that, but pretty close.

That's my point.  Some are talking about 24 bit ADC which are not in FPGAs.  Well, they aren't in most MCUs either.  Someone posted a part number for a Maxim device that is $30 in quantity!  Someone was talking about 100's of kB of memory for $3, the STM32F334 has 65kB of Flash and only 16kB of RAM.  Someone was talking about 100's of MHz clock speeds for $3 and this part is 72 MHz. 

I know people like their MCUs.  That's fine.  But the facts of the matter are being distorted.  At 72 MHz clock rate there are only a few instructions available to process a pair of ADC's at 5 MSPS.  If you can squeeze your app into those remaining instructions, great!  But it's not a design you can do in your sleep. 

And, they have added a core-coupled memory for fast and predictable execution of timing-critical routines, this isn't standard in Cortex-M4 product line.

Ok, so they are trying to catch up with FPGAs.  Good.

This sounds like an advertisement, right, but just saying this part satisfies most power conversion needs I can think of and does it cheaply.

I never said anything different.  I said that FPGAs are easier to design with for such tasks.  If you find MCUs easier to use, that is mostly because you've done it many times before and can use the same techniques again.  If you have a new problem that has new constraints and can't be done so easily, you will have to start over again.  At that point you might consider an FPGA. 

[gnuarm]

Sorry to hear you are using an AKM part in your product.  I am also and their factory fire has cut me off from all supply.  A part that was $3 is now $60 on Alibaba. 

Have you gotten any of these parts lately?

Luckily, it's a one off prototype and I ordered the chips while they were commonly available. For production, such a high end ADC is overkill and most likely Delta Sigma ADCs built around the LVDS receivers in the FPGA would perform well enough, maybe a separate ADC for just the PLC receiver. I don't have any plans to make a production version, since aside from the regulatory issues surrounding a mains connected product that uses custom circuits interfaced to mains, I don't think very many see the value in an all in one box that handles solar MPPT, backup power, VFD for thermal storage, and home automation/energy management.

A design I am working uses sigma-delta converters for ADC.  We sample slowly at 5 ms because that's all it needs.  It took me a while to get my head around everything I read about this type of design.  Much of it doesn't apply to this app because our signal relates to the human breath and does not need to support a high band width.  One thing I learned is that most of the objections have to do with the work required to shape the band pass response on a sigma-delta converter.  That is typically done with a FIR filter, but is not needed if the CIC filter response is adequate.  At that point the circuit design is a simple counter with a boxcar filter response.  The noise filtering at higher frequencies is very good. 

I'm not familiar with a PLC receiver.  This is about comms over the power line?

What sample rates do you expect to use for the various control aspects?