Picking a DSP MCU for Power Conversion - Experiences?

[sandalcandal]

TL;DR
Trying to pick a DSP MCU family for power electronics control loop. Done some research and consideration, toss up between Texas Instruments C2000 and Infineon XMC4000. Would like to hear other people's own experiences and thoughts.
Edit: Similar question thread here: https://www.eevblog.com/forum/renewable-energy/micros-for-digital-smps-control-ti-nxp-(freescale)-opinions/
Update: Decided on going with TI C2000 family for my needs but STM32G4 is a strong and popular alternative. Detailed post on decision here.

Background
As part of the pilot 1kW CLLC converter design I've posted about and future power conversion systems a DSP MCU (digital signal processing microcontroller, often referred to as just DSP) will be required to control switching and regulate output (i.e. implement the control loop). Selection of an appropriate microcontroller platform/family is critical as the development of the control firmware/embedded software will require significant sunk resources in order to produce functional test prototypes. In particular, the basic operational code and associated learning curve for each platform will be non-transferable, especially for special proprietary features (e.g. integrated peripherals) if they are to be taken advantage of.  More general learning of control loop and system dynamics are expected to be transferable however. There may be errors or points I’ve missed so please feel free to correct me.

Why DSP MCU? Alternatives to DSP MCU
The underlying function to be fulfilled is control loop regulation of a switchmode power supply and in our particular application primarily frequency modulation but there is also possibility for mixed control schemes using phase and duty cycle. This function does not require a DSP MCU in particular and could be potentially fulfilled by other devices.

Digital vs Analog
In general, digital systems as opposed to analog systems offer benefits most significantly in flexibility and configurability of the control loop since most digital control systems are “programmed” rather than hardwired. This in turn enables faster development for application. The fundamental implementation of control systems also tends to be more straightforward with the ability implement arbitrary* response functions and conditional behaviour.

The limitations of digital control systems are aliasing, processing delay and data throughput. Analog enables the highest operating frequency and bandwidth possible. Analog components also tend to be more robust than high speed digital components due to freedom from digital error and failure modes but this is not guaranteed.

Costs and size can vary for digital and analog implementations. For simple systems and analog IC implementations, analog can be smaller and cheaper but for more complex control systems, a digital implementation can be smaller and cheaper as functions requiring multiple devices and stages can be easily accomplished in the digital domain in a single DSP chip.

Great overview of digitally controlled power


Discrete Analog Feedback Network
The most “basic” means of controlling a system using analog feedback via op-amp or even discrete transistors and passive components. Drawbacks of this method include increased circuit size and component count as well as potentially higher costs (when implementing more complex control systems). The biggest drawback from a developmental standpoint is the reduced speed of iteration due to the need for significant physical rework to adjust feedback network parameters or even change configuration topologies.
As minimising development/iteration time as well as minimising size of the circuit are high priorities, discrete analog systems are not being considered.

Analog Control ICs
Analog (aka linear) controller integrated circuits are another potential analog based option. ICs can provide all the required functionality in a cost effective single package with relatively simple implementation (compared to making a control circuit/algorithm for scratch) by following recommended reference designs. Being ICs however, they suffer from inflexibility. An IC suitable for the application needs to be found otherwise it is sometimes possible to use an IC outside its recommended application but doing so often involves risk in terms of reliability and development.

For the desired high power application, off the shelf ICs are not available. Example reference designs in our application space exclusively use DSP MCUs.

DSP ASICs
DSP ASICs (digital signal processing application specific integrated circuits) are another means of performing digital control. DSP ASICs tend to be designed for digital domain processing of special signals such as video and audio processors where analog domain processing would be impractical. As with analog ICs, the application specific nature means they are inflexible and generally require a suitable IC to be available. Again, few (none known to me currently) are available on the market for our application. Generalised DSP using DSP MCUs seems to be the norm for cutting edge power electronics using DSPs.

FPGAs
FPGAs are a strong alternative to DSP MCUs. Essentially capable of all the same functions as an MCU but potentially higher bandwidth and with the ability to efficiently transition designs to an ASIC. A downside to FPGAs is much higher unit cost for similar performance and a convoluted intellectual property landscape. Development and coding of FPGAs is also fundamentally different to MCU programming which can be a major barrier for designer competence. Engineers/programmers able to competently program MCUs tend to be more available however since MCU operation falls closer inline with typical computer science education.  The available reference designs as well as recent academic literature all use DSP MCUs so in addition to the cost disadvantage and lower accessibility, FPGAs are not going to be used over DSP MCUs.
edit: Some different opinions on FPGAs by gnuarm

Other Misc
There are also discrete, general DSP microprocessors but these tend to be higher cost, very high compute power for processing actual signals and lack the integrated mixed-domain peripherals required for power control.

Programmable analog is a thing but you don’t see much of it. Article suggesting why:
https://www.digikey.com.au/en/blog/whatever-happened-to-programmable-analog

Hybrids
Hybrid solutions consisting of a mix of any of the above are also possible. Such systems can take advantage of the strengths of different solutions while covering weaknesses. However, mixing systems also greatly complicates designs and if not well optimised serves to increase size, cost and development time. Will still be targeting a primarily DSP MCU based implementation for now.

Wishlist Specifications and Features
Not all DSP MCUs are created equal and having an idea of what will be required or otherwise beneficial

Processor Core Frequency: >100 Mhz
ADC Bit Depth: >11 bits usable
ADC Sample Rate: >2 MSPS
ADCs: 2 minimum, more than 5 not useful
PWM Peripherals: <100ns resolution
ECC Memory
Safety Certifications
Single Core
Available CLLC or LLC reference design
FPU

Processor Core Frequency needs to be sufficiently fast with respect to the converter maximum switching frequency such that “full” control can be achieved with minimal phase delay or potential aliasing effects. This will be particularly important for achieving active synchronous rectification. Maximum switching frequency will be in the order of 1MHz at light loads so to ensure minimal phase delay, a clock speed in the order of 100MHz will be required. This seems to be in line with DSP MCUs in reference LLC designs.

Control is possible with switching frequencies nearing or beyond processor frequency using PWM peripherals but sampling and control then needs to be done in frequency-phase domain rather than time domain which can limit flexibility and control.

ADC Bit Depth must be sufficient so that adequate regulation resolution can be achieved. Insufficient resolution also can contribute to instability due to quantisation error. A voltage regulation of 0.01V over a 60-40=20V range, a dynamic range of 2000:1 or ~33dB (note: just looking at voltage dynamic range and regulation, not signal power so not using x2 factor seen in some dynamic range dB equations) for which the minimum number of bits is 11 bits. A current regulation of 0.01A over 20A range will similarly require 11 bits. If a voltage offset is to be avoided in the voltage regulation frontend then the required dynamic range would be 60:0.01=6000:1=~38dB and 13 bits.

It should be noted that sometimes despite an ADC technically having for example 16 bit output, the LSB (least significant bit) or multiple LSBs can be unusable due to self-noise which can also be dependent on a configurable sample rate. The actual number of usable bits needs to be checked.

ADC Sample Rate needs to be sufficiently fast to capture control input signals without aliasing. Given a maximum switching frequency of 1MHz a minimum sample rate of above 2MHz will be required as per Nyquist sampling theorem to discern the fundamental but higher would be better, particularly for quickly and accurately determining phase and amplitude. Complete discrimination of switching waveforms is not necessary required for control but could allow better control and efficiency e.g. active synchronous rectification. However, such high sampling rate dependent features could be disabled when operating at maximum switching frequency i.e. light load where it is less necessary anyway.

Number of ADCs needs to be sufficient to sense all the required control signals. At a bare minimum, output voltage and current needs to be regulated and must be sensed. Additional sensing can also help improve the control loop e.g. sensing input voltage, sensing rectifier conduction state and tank energy. Perhaps up to 5 could be useful, at least for experimentation with the ability to measure input and output current voltage as well as tank state. Also a note on the number of ADCs, the limited number of ADC on an MCU can typically be internally multiplexed to sample multiple channels, the downside being that each ADC is still limited in its sample rate.

Edit: As uer166 pointed out below, ADC sampling can be synced to the controlled waveform in hardware so Nyquist sampling doesn't necessarily apply.

External ADCs are possible but hooking up an external ADC properly so that full data throughput is enabled and delay is kept to a minimum is an additional challenge compared to using an internal ADC which will of course be fully compatible and have minimal delay.

PWM/Timer Peripherals need to be sufficiently fast and high resolution to operate in the circuit. Most MCUs have PWM/Timer peripherals to handle switching and timing outside the processor core but requirements for timer speed and resolution are much greater for high frequency (>100kHz) switching control. At a 1MHz operating frequency the required PWM resolution will be fractions of a microsecond so approximately <100ns; at lower timescales the gate drive and switching speed of the MOSFETs themselves will become overriding. Better resolution could allow better control using phase shifting techniques. Depending on control and output options, it may be possible to achieve the bare minimum input inverter control using a single timer. Multiple timers could allow greater control freedom.

ECC Memory is desired as any memory glitches or loop failures could potentially have catastrophic failures due to the amount of power being handled. Failures are also much less desirable in industrial grade, mission critical equipment.

Safety Certifications are not strictly required for the converter controller but the added reliability and potential to reuse a familiar family in another application requiring functional safety e.g. BMS are attractive.

Having an Available Reference Design CLLC or LLC with the DSP MCU will speed up design greatly by having a full example to reference for all the basic required functions. It also provides some level of “proof” the DSP MCU is adequate for application in an CLLC/LLC.

Only a Single Core MCU will be required for the time being. Only a single phase needs to be controlled for the pilot design and otherwise syncing between multiple MCUs will be required for high level multiphase implementations later anyway so no need for multicore MCUs probably?

An FPU (floating point unit) is required to do floating point arithmetic efficiently.  Whilst it is possible to implement control systems using fixed point arithmetic, doing so requires careful conversions at each calculation step to avoid loss of precision and introducing error. Using floating point will be much quicker to develop and avoid designer errors as well as rounding errors.

Short List
Texas Instruments: C2000
https://www.ti.com/microcontrollers/c2000-real-time-control-mcus/overview.html
Chips available meeting wishlist
Proprietary TI core?
Optional CLA and PGA peripherals
Best value in terms of features and performance per $
Wide performance/spec range available

Reference Design 6.6 kW CLLLC using TMS320F28004x
https://www.ti.com/tool/TIDM-02002
https://www.ti.com/product/TMS320F280049

Reference Design 500 W 2-phase LLC using TMS320F280025C
https://www.ti.com/tool/TIDM-1001

Also seems popular in designs from outside TI. Wolfspeed reference designs using C2000 MCUs

Wolfspeed Reference Designs:
Oct 2020 Reference Design 22 kW CLLC bidirectional using TMS320F28377D
https://www.wolfspeed.com/power/products/reference-designs/crd-22dd12n

2019 Reference Design 6.6 kW LLC using TMDSCNCD280049C
https://www.wolfspeed.com/power/products/reference-designs/crd-06600dd065n

2019 Reference Design 6.6 kW CLLC bidirectional using TMS320F28377D
https://www.wolfspeed.com/power/products/reference-designs/crd-06600ff065n

2018 Reference Design 6.6 kW CLLC bidirectional using TMS320F28377D
https://www.wolfspeed.com/crd-06600ff10n

TMS320F28377D Product Page: https://www.ti.com/product/TMS320F28377D

Academic Papers:
5kW CLLC bidirectional using TMS320F28335
https://www.researchgate.net/publication/260496284_Design_Methodology_of_Bidirectional_CLLC_Resonant_Converter_for_High-Frequency_Isolation_of_DC_Distribution_Systems

(also seen some other papers for non-LLC circuits using C2000 DSP MCUs)

Cypress/Infineon: XMC4000
https://www.infineon.com/cms/en/product/microcontroller/32-bit-industrial-microcontroller-based-on-arm-cortex-m/32-bit-xmc4000-industrial-microcontroller-arm-cortex-m4/
Chips available meeting wishlist
ARM® Cortex™-M4 based
No configurable logic peripherals
Most expensive but still within budget
XMC4400 series looks particularly relevant

Reference Design 3 kW 2-phase LLC using XMC4400-F64K512 BA
https://www.infineon.com/cms/en/product/evaluation-boards/eval_3kw_2llc_cfd7/

STMicroelectronics: STM32G4
https://www.st.com/en/microcontrollers-microprocessors/stm32g4-series.html
Chips available meeting wishlist
ARM® Cortex™-M4 based
No configurable logic peripherals

Also lower spec 72 MHz STM32F3 series available, mostly intercompatible? Clock speed likely too low for highest target operating frequency however.

Reference Design STM32F334
https://www.st.com/en/evaluation-tools/steval-dpsllck1.html

Microchip: dsPIC33
https://www.microchip.com/design-centers/16-bit/products/dspic33e
Microchip seems to be pushing the dsPIC33C (100 MIPS capable) and dsPIC33E (70 MIPS capable) families for digital power.
NO FPU
Configurable logic peripherals

Reference Design, 200 W half bridge LLC using  https://www.microchip.com/developmenttools/ProductDetails/DC/DC-LLC-Resonant-Converter

Analog Devices: ADSP-CM4xx
No DSP MCU controlled LLC/CLLC reference designs available. Suggested MCU for digital power has been obsolesced. Doesn’t look like they’re putting much behind their DSP MCUs https://www.analog.com/media/en/technical-documentation/tech-articles/IC-Ecosystem-for-Driving-Next-Generation-SiC-GaN-Power-Converters.pdf
Renesas: RA6T1
https://www.renesas.com/us/en/products/microcontrollers-microprocessors/ra-cortex-m-mcus/ra6t1-120mhz-arm-cortex-m4-assp-ra6-motor-control
Meant primarily for motor control but has peripherals useful for digital power.

No reference design

Not offering mixed-signal/DSP MCUs:
Silicon Labs

Choosing the MCU
The main contenders are the STMicro STM32G4, Infineon XMC4000 and TI C2000. All have a full and complete feature set and excellent specs.

Only the XMC4000 and C2000 have complete, well documented reference designs which closely match the target design. Documentations and materials for the STMicro reference design appear less complete and are for the related STM32F3 rather than the STM32G4. Edit: Only the C2000 reference design has publicly available source code.

Costwise, the C2000 appears to be the best value for money looking at 1ku budgetary pricing. The C2000 also has a much larger available product lineup with more cost-performance options.

The XMC4000 uses the “open” ARM Cortex for its processor core which might help keep us free from being too “locked-in” with a specific vendor in terms of being able to transfer code architecture but the C2000s use a TI proprietary core?

I’ve also actually been able to get my hands on the reference design board for the Infineon XMC4000 LLC and I have emails of the Infineon engineers which are responsible for the Infineon LLC design. I have tried via TI’s official portals but haven’t been able to get in touch with TI support (help?). There appears to be more stuff out there using C2000 MCUs.

Development environments also differ but would need experience and hands-on testing to know which is better.

For just what I have on hand currently, XMC4000 looks like the easier option but C2000 looks like it might be best overall on paper.

[uer166]

Great stuff, the only comment I have is re:

ADC Sample Rate needs to be sufficiently fast to capture control input signals without aliasing. Given a maximum switching frequency of 1MHz a minimum sample rate of above 2MHz will be required as per Nyquist sampling theorem to discern the fundamental but higher would be better, particularly for quickly and accurately determining phase and amplitude.

I think you need to re-think this. Even though ADCs in the given MCUs approach >2MSPS, it doesn't mean that it will be usable, or that you can process samples in such short time-frames. I mean that only gives you ~50 CPU cycles between each ADC sample for only one channel @ 100MHz. That's what, 10 multiply-accumulates?

Another thing is, you are in control of both the control waveform generation and the ADC sampling. All the timer peripherals can synchronize ADC sampling to arbitrary places in the waveform, in hardware. This means the nyquist theorem doesn't truly apply, since you can alias (or anti-alias), the measurements in any way you wish with the switching waveform. For example, you can use HRTIM peripheral, or an advanced timer in STM32 to trigger ADC sample-and-hold every middle of PWM period to get average current, or even every Nth period if your measurement bandwidth can be lower than switching frequency.

Instead, the truly high-frequency control is all done in the analog/pure hardware domain (comparators, DACs, flip flops, opamps). All those resources are available on-chip in all those MCUs, you just need to know how to connect them together. The software control loop can run at, say, 100kHz or in that order, something actually reasonable for an ARM core where you not only need to process the data, but first load into the registers with associated delays and write back all the control stuffs.

If you truly need a 2MHz software control loop, which sounds highly unlikely, you are stuck with a dedicated DSP + discrete high-speed ADC, or FPGA+ADC solution. No way you can do a complex 2MHz control loop with Cortex-M4 in given implementations. Maybe an extremely simple hand-optimized control loop, but that's not what you're trying to do..

Edit: another thought is, for classic PWM specifically, the max. resolution is de-coupled from the core operating frequency using delay-locked loop peripherals and such. E.g. 200ps PWM resolution on STM32G4. Same applies for asynchronous connections of comparator outputs to timer peripherals and such.

[sandalcandal]

Thanks for having a look uer166, great advice!

Another thing is, you are in control of both the control waveform generation and the ADC sampling. All the timer peripherals can synchronize ADC sampling to arbitrary places in the waveform, in hardware. This means the nyquist theorem doesn't truly apply, since you can alias (or anti-alias), the measurements in any way you wish with the switching waveform. For example, you can use HRTIM peripheral, or an advanced timer in STM32 to trigger ADC sample-and-hold every middle of PWM period to get average current, or even every Nth period if your measurement bandwidth can be lower than switching frequency.

Thanks, I wasn't aware one could synchronise ADC sampling as such in hardware. Edit: The phase relationship of the converter output to the input controlled waveform could be undetermined so might not be perfect.

I probably need to get further along in my control loop design and implementation to appreciate the full extent of requirements and options available. Before then I still need a solid platform I can get started on to explore the options so that's what this topic is about finding.

[Phoenix]

Hi scandalcandal

I have many years experience developing digital control for power electronics - I have only ever used TI C2000's but at the moment they are (IMO) still the winner for what you want to do. Hopefully you have plenty of other microcontroller experience as the learning curve will be great.

The other contender IMO are the STM32G4's, but I haven't used them.

Unless you're making millions of these I don't think being locked to one vendor is going to be a game changer - look for long term support. Otherwise your code might remain processor compatible but still need to write half of it again to fit different peripherals. Which requires still requires significant time.

Good things about the TI TMS320F280xxx range:

Processor
C28x+FPU is has faster instructions than CM4+FPU including parallel integer/memory and floating point instructions. So you need less clock for the same performance.
https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/873371

Most models have a secondary processor called the CLA which is designed to be dedicated to fast control loop calculations.

Can also get other nice things like fast floating sin/cos/invert etc.

ADC
Can get 3 (or even more?) ADCs in some models.
Not the greatest specs (newer ones are a bit better) but much better when using an external precision 3.3V reference.
Very configurable sampling sequencer. Very configurable triggers.

PWM
Very configurable PWM modules. They get even more complicated with newer types .
For frequency control they have shadowed counter PERIOD registers (I expect most competitive vendors do).

My current work project is using a single TMS320F280049 (IMO currently best bang-for-buck model) to control a bidirectional system with grid tie inverter (1ph and 3ph), unregulated LLC and regulated buck. The only thing I've really run out of is GPIO pins .

Great overview of digitally controlled power

The point about embedded design not crossing over with power electronics design is very important. An analogue power electronics engineer trying to tell a programmer what to do doesn't work well in my observations; the control designer needs to understand digital implementation too.

Another thing is, you are in control of both the control waveform generation and the ADC sampling. All the timer peripherals can synchronize ADC sampling to arbitrary places in the waveform, in hardware. This means the nyquist theorem doesn't truly apply, since you can alias (or anti-alias), the measurements in any way you wish with the switching waveform. For example, you can use HRTIM peripheral, or an advanced timer in STM32 to trigger ADC sample-and-hold every middle of PWM period to get average current, or even every Nth period if your measurement bandwidth can be lower than switching frequency.

This is one of the big things that needs to be understood in digital control - the effects of the sample point. For example if you sample current at the peak/trough of a triangle carrier waveform you sample the exact average current (i.e. rejecting the switching ripple)... but of course if you have any delays (or phase shift) in your analogue circuit you need to delay your sampling too. This is also not true for discontinuous conduction operation and the current may need hardware low pass filtering.

[NiHaoMike]

I'm using a Xilinx Spartan 6 for my zero export solar inverter design, but it's a rather unique case where it's handling the PWM control as well as low latency power line communications with the current sensor. The (remote) sensor modulates a FM carrier with the current waveform, a subcarrier for the difference in current between the phases, and an ASK pilot tone for fault detection and more accurate digital power readings. The FPGA has to decode the signal (including various DSP tricks with coherent diversity reception for robustness) and respond with commanding the power electronics to inject a current to largely cancel out the load current, all while responding to load current changes in a few hundred microseconds or less.

There might be some exotic DSP microcontroller that would be able to do that but as far as I can see, the FPGA's advantage of running everything in parallel would make it a lot easier to keep end to end latency to a minimum. As far as I can tell, none of the commercially available solar inverters support wireless current sensors for zero export and few support external current sensors at all for zero exporting upstream of the inverter. (Most so called "zero export" inverters only support zero export to loads on the output side.) That and the high cost of inverters with all the features I want is why I'm building my own.

[sandalcandal]

Thanks for the thoughts and experiences Phoenix!

Processor
C28x+FPU is has faster instructions than CM4+FPU including parallel integer/memory and floating point instructions. So you need less clock for the same performance.
https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/873371

Most models have a secondary processor called the CLA which is designed to be dedicated to fast control loop calculations.

Can also get other nice things like fast floating sin/cos/invert etc.

The original source post for that table comparing performance from Nov. 2010 states the Cortex-M4F takes 3 cycles for a MAC https://e2e.ti.com/support/microcontrollers/c2000/f/171/p/21092/276807#276807

However, the XMC4400 chip I was looking at advertises single cycle MAC so I wonder if that comparison is entirely accurate or up-to-date.

It does bring up an important point that advertised MIPS and core frequency are much less than a full picture for "real world" performance.

[gae_31]

Great stuff!
I was recently looking at SR controllers for LLC when I stumbled upon the UCD3138.
Might be worth adding that to the equation, although I am convinced that C2000 is better choice in terms of cost and performace.

And my personal preference/requirement is to always have a external reference for the ADC, (as you really want a stable non-drifting reference)

[Berni]

It doesn't really matter as much these days because so many MCUs are so powerful that the need for actual DSP chips is going away for most applications.

Just take an ARM MCU and run with it. Someone like ST has a wide range of chips from little low power 48 MHz MCUs with no floating point up to 400MHz CortexM7 chips with single cycle float MAC and some fairly narrow SIMD math. You also get libraries directly from ARM that have assembler hand optimized DSP functions such as FFT, matrix, vector etc

The ADCs in some of these MCUs are also very nice. You can get a MCU from ST with multiple 2MSPS 16bit ADCs and you can get some pretty decent performance out of them. Processing data that fast in real time is also not that big of a problem when the code is reasonably optimized. The code typically won't service the ADC directly, rather the DMA is used to move ADC samples into RAM for processing. Any tight timing synchronization with PWM and such is also done in the ADC hardware. Yes you might not get the noise performance of a dedicated 16bit 2MSPS ADC chip, but the internal MCU ADCs are actually good enough to make most of those bits actually usable. Even if the last few bits are noisy they still greatly help in keeping away the non uniform quantization noise.

[ali_asadzadeh]

STM32H750VBT6 is good choice too, it can be bought around 3.5$ in china

[sandalcandal]

Great stuff!
I was recently looking at SR controllers for LLC when I stumbled upon the UCD3138.
Might be worth adding that to the equation, although I am convinced that C2000 is better choice in terms of cost and performace.

And my personal preference/requirement is to always have a external reference for the ADC, (as you really want a stable non-drifting reference)

Thanks for having a look and sharing that, the UCD3138 looks like an interesting device. Any more detailed thoughts about how it compares to the more generalised DSP MCUs? Looks like a light weight processor (ARM7TDMI-S) together with some fairly strong ADCs and PWMs with the main control being some configurable hardware PID filters. Cost is comparable or slightly higher than some of the C2000 MCUs I've been looking at.

Also for non-MCU controller options, this LLC reference design by Wolfspeed/Cree https://www.wolfspeed.com/crd-20dd09p-2 does 20kW using the (relatively) dirt cheap NCP1395 (US$0.76 budgetary price). Not possible to do bidirectionality and lacks the flexibility of a fully programmable control solution though.

Thanks for the comment and thoughts Berni!

It doesn't really matter as much these days because so many MCUs are so powerful that the need for actual DSP chips is going away for most applications.

I think that's what I saw. These "DSP" MCUs mostly look like souped up MCUs with some extra DSP instructions, floating point arithmetic and nice peripherals. Different from older "actual" DSP MPUs like the TI C6000 series. My current question is which of the available options is the best (in terms of both cost-performance and development costs) or rather what are some unforeseen pitfalls I might want to avoid when picking one to start running with e.g. the dsPIC not having FPU.

I'm using a Xilinx Spartan 6 for my zero export solar inverter design, but it's a rather unique case where it's handling the PWM control as well as low latency power line communications with the current sensor. The (remote) sensor modulates a FM carrier with the current waveform, a subcarrier for the difference in current between the phases, and an ASK pilot tone for fault detection and more accurate digital power readings. The FPGA has to decode the signal (including various DSP tricks with coherent diversity reception for robustness) and respond with commanding the power electronics to inject a current to largely cancel out the load current, all while responding to load current changes in a few hundred microseconds or less.

There might be some exotic DSP microcontroller that would be able to do that but as far as I can see, the FPGA's advantage of running everything in parallel would make it a lot easier to keep end to end latency to a minimum. As far as I can tell, none of the commercially available solar inverters support wireless current sensors for zero export and few support external current sensors at all for zero exporting upstream of the inverter. (Most so called "zero export" inverters only support zero export to loads on the output side.) That and the high cost of inverters with all the features I want is why I'm building my own.

Sounds like an interesting project. Given the amount of functional designs I've seen using these DSP MCUs (some cited in the OP) I don't think the level of processing you require necessitating FPGAs will be the case for my application.

[Phoenix]

However, the XMC4400 chip I was looking at advertises single cycle MAC so I wonder if that comparison is entirely accurate or up-to-date.

It does bring up an important point that advertised MIPS and core frequency are much less than a full picture for "real world" performance.

I don't think the M4F has changed over the years, it's a pretty old design too. Some companies have added external processors (like STM32G4 having trig calculators). I don't profess to fully understand the different pipelines of the M4F vs the C28x... but I do believe the results if you consider TI is slightly more expensive purpose built processor vs the M4F as a more general low cost processor. Of course you can offset the difference with a faster clock! Then the TI can have CLA which is designed to look after all the closed loop calculations.

As much as I am a TI fanboi I would like to try an STM32G4 series, but I can't justify the huge time investment to learn it to a similar level I know the TI chips. They are a compelling option from a cost and feature perspective.

[Berni]

Thanks for the comment and thoughts Berni!

It doesn't really matter as much these days because so many MCUs are so powerful that the need for actual DSP chips is going away for most applications.

I think that's what I saw. These "DSP" MCUs mostly look like souped up MCUs with some extra DSP instructions, floating point arithmetic and nice peripherals. Different from older "actual" DSP MPUs like the TI C6000 series. My current question is which of the available options is the best (in terms of both cost-performance and development costs) or rather what are some unforeseen pitfalls I might want to avoid when picking one to start running with e.g. the dsPIC not having FPU.

I already said about ARM MCUs from ST. The exact chip depends on what peripherals you need and how much processing power is needed. Code is reasonably easily ported between all of them. If you want speed go for STM32H7 if you don't go for STM32F4

However DSP does not always mean having a FPU. Sometimes DSP processing is done in fixed point math hence why the fixed point performance of DSPs is also specified separately. The different between a regular CPU and a DSP is mostly just that the DSP is optimized for moving and calculating large amounts of data. This is seen in the from of having multiple banks of memory to allow parallel data access, having multiple ALUs to allow multiple calculations to happen in parallel, even those ALUs support SIMD instructions etc... Since these parallel calculation units are all hanging off a single core means that things have to happen in a very specific order to keep all of them well fed with data and commands. This makes writing software for such "pure breed" DSPs very confusing and messy since efficiently using all of its processing power means mashing together and interleaving certain steps of an algorithm to keep all parts of the core busy.

However it is not the 1990s anymore, these days we know how to just crank up the clockspeed fast enough to do it sequentially while transistors are so cheep that a MCU can afford to have a powerful single cycle FPU. So people don't want to bother with these hard to program DSPs when they can just use a CPU.

Orders of magnitude more processing power can be had from a FPGA, but programing those is even more annoying.

[poorchava]

C2000 have one downside: they are weird and TI documentation sucks. If you come from any normal 8 or 32 but controllers, u will really have a hard time. Try to search reference manual for SPI MOSI signal... Good luck... They call it SOMI... And this stuff is littered all over the place.

Dev tools are crap. We had bought 5 different tools and neither of them is really stable. Loads of driver problems, even with the really expensive high end tools.

The boot sequence and configuration is complicated, and documented in a way typical for TI: fragmented, and everything is called differently than any industrial standards, which means you have to pretty much read the entire thing from top to bottom. They have some wiki pages or few different wikis, all full of dead links...

And they have sixteen bit bytes. Which means that C2000 little.endian and ARM little endian mean completely different things. Also, no DMA on things like UART, SPI and I2C and no hardware nested interrupts.

They do have good ADCs,  best HRPWM capabilities of all DSCs and very good optimizations by the compiler, but they are a pain to work with and even bigger pain to learn.

It took me about a month to be able to do anything useful with a C2000 and that is given that we have a guy in the company i could talk to and hear 'they call it that way' or 'look at this doc's.

The only thing that is good in their tool chain is liner scripts. Much more straightforward to learn than GCC linker. I found assembly easier than ARM too (and you will need it, believe me...)

[poorchava]

Btw, where actual DSP/DSC shines in comparison to a fast uC with some edvanced PWM is math. Most C2000 have stuff like CORDIC engine, hardware viterbi/crc, hardware real numbers etc. Calculating a sin/cos in 4 to 5 cycles is often huge.

Also, fixed point math is often worse. Eg i did some benchmarking on a H7 for different ways to run certain long FFT, and the fixed point version is actually waaaay slower than floating point one due to having to scale up/down numbers all the time.

But DSPs are a real pain in the ass to work with, especially if ur used to much more user friendly ARM-based uC tool chains like those from ST, Infineon or Cypress.

[Berni]

Btw, where actual DSP/DSC shines in comparison to a fast uC with some edvanced PWM is math. Most C2000 have stuff like CORDIC engine, hardware viterbi/crc, hardware real numbers etc. Calculating a sin/cos in 4 to 5 cycles is often huge.

Also, fixed point math is often worse. Eg i did some benchmarking on a H7 for different ways to run certain long FFT, and the fixed point version is actually waaaay slower than floating point one due to having to scale up/down numbers all the time.

But DSPs are a real pain in the ass to work with, especially if ur used to much more user friendly ARM-based uC tool chains like those from ST, Infineon or Cypress.

Yep i used the ARM official DSP library on the STM32H7 too and fixed point was indeed slower. But this is because the H7 has a single cycle floating MAC. On some of the other ARM chips that have slower floating math it might be faster to do it fixed point. Or if you have a chip with no hardware FPU then you are pretty much forced into fixed point. Tho FFT is a particular example where float is pretty useful. There are quite a few other algorithms like averaging, filters, control loops etc where fixed point works just fine.

Actual DSPs still indeed have their benefits as they still overpower the "DSP capable MCUs" but its only worth it if you actually need the extra horsepower to justify the extra effort in making the software work.

Also when it comes to powerful number crunching chips the modern Linux SoCs are also quite a powerhouse. Obviously with all the extra layers, they are not well suited for fast timing critical applications, but when a bit of latency is not an issue then the modern flexible GPUs found inside them can blow the pants off quite big and beefy DSPs. Can also be quite tricky to program for but can push some really impressive GFLOPS numbers while also being pretty power efficient.

Still for just controlling large a power converter these things are so slow in terms of modern electronics that even something as poor as a dsPIC can take care of it. It can literally execute thousands cycles in the time the power converter goes through a single PWM cycle(big ones tend to operate at pretty low freqency to get the efficency out of it).

[gae_31]

Thanks for having a look and sharing that, the UCD3138 looks like an interesting device. Any more detailed thoughts about how it compares to the more generalised DSP MCUs? Looks like a light weight processor (ARM7TDMI-S) together with some fairly strong ADCs and PWMs with the main control being some configurable hardware PID filters. Cost is comparable or slightly higher than some of the C2000 MCUs I've been looking at.

I think the main difference is indeed the hardware filters which work independently.
See the qoute below , taken from :
https://www.eletimes.com/wp-content/uploads/2016/12/spry279.pdf

.
 Unlike traditional MCU-based solutions that require fast,
complex calculations to stabilize the control loop,
the UCD3138 processor is never directly involved in
control loop computation. Instead, once configured,
multiple hardware peripherals operate autonomously
to control the power converter

The reason I was eyeballing it is because of the combination with the UCD7138 as SR controller which seems interesting as you could off load that part to the micro.

Still for just controlling large a power converter these things are so slow in terms of modern electronics that even something as poor as a dsPIC can take care of it. It can literally execute thousands cycles in the time the power converter goes through a single PWM cycle(big ones tend to operate at pretty low freqency to get the efficency out of it).

I am not sure.  usually you want the same transient response from your digital control almost as good as what you would get from analog control.
If you switch at 200Khz and you take a sample each period in order to not completely destroy your phase combined with the time to process the ADC results, you actually do not have a lot of budget for processing. (note that you are also limited about the moments you can take samples)
Since for digital control, you are already limited to a lower crossover frequency than analog control, due to phase erosion of sampling.
In my opinion/limited experience for good transient response and analog type of transient, you really do not have a great time budget.
reading, writing, storing, running the control loop can easily take 50-100 cycles with optimized assembly code, so suppose you have a 50Mhz cpu then you end up with 2 us.

[gae_31]

@sandalcandal, I wonder if you were able to make a decision after getting all the different opinions 

[sandalcandal]

Still not 100% locked into one yet (haven't made purchases or started actual development work). I had a look at the NXP offerings.

NXP: KV4x
Product Page
ARM® Cortex™-M4 based
Lacks ECC Memory
High cost relative performance.

Reference Design, 250W LLC using KV46F256VLL15
https://www.nxp.com/design/designs/kv46-digital-llc-converter-reference-design:LLC-RESONANT-CONVERTER

Also NXP MC56F83xxx being marketed for digital power
Product page
ARM® Cortex™-M4 based
ECC Memory
More expensive than XMC4400 but less features and lower performance.

Further Research and Consideration 1
Looking at some of the discussion here and in the other thread. I've started considering the STM32G4 more strongly due to "popularity", outstanding cost effectiveness as well as feature set.

I tried seeing if there were any publicly published and recent benchmarks comparing some of the different MCU families but the best I could find was this: https://www.eembc.org/coremark/ which seems more like benchmarking compilers/toolchains than MCUs. There probably is stuff out there but not available for free (or a price I'd be willing to pay).

I might have mentioned it already but it turns out code for the XMC4400 reference design is not part of the publicly available reference documentation.

Availability is another thing I've kept an eye out for. The XMC4400 seem to be out of stock everywhere with very long lead times but the C2000 MCUs by comparison seem to have the best availability with thousands in stock across the whole range everywhere. STM32G4 also seems to have good availability.

Overall the C2000 is looking like the most attractive due to good cost effectiveness, strong feature set and complete, available, application-specific reference documentation. One of the people we've recruited also has experience doing implementations of power DSP using C2000 chips. The only pressure against the C2000 is some of the proprietary funniness of TI which could be avoided by using Arm Cortex chips but due to the immense product range in the C2000 family and TI's size I'm not too worried about getting stranded with only bad options due to platform immobility.

So C2000 is looking like the best choice and certainly "easiest" choice in terms of minimising development risks but if I can find the resources then I'd like to seriously consider the STM32G4. Cost impact of the DSP MCU isn't major relative the overall system but the STM chips do have outstanding cost effectiveness; sometimes near half the cost of comparable TI C2000 chips. Maybe I'll let an intern play around with a STM32G4 or do some out of hours experimentation?

[sandalcandal]

Having a higher PWM resolution helps reducing control loop oscillation thus reduces circulating energy, thus reduces the loss by a bit. But if your power train is efficient enough, a bit of recirculating energy shouldn't hurt the overall efficiency that much. I would say PWM resolution should be a factor, but not having HRPWM shouldn't cross out a part immediately.

I've done interleaved 600kHz PFC with a cheap commodity 120MHz Cortex M4 (GD32F350) even without hardware FPU. Make sure your control loop doesn't over compensate and oscillate badly. You need some tricks to cope with the lower PWM resolution, but it is possible (active feed forward dithering is better than letting the feedback loop do it for you).

The MCU I picked doesn't even have interleaving capability, so I had to use two timers, and use hand written assembly to enable their clocks at a particular delay. Sometimes people will go extreme to achieve a certain goal, like extreme cost saving, or in my case, to eliminate US components.

Pretty much all the MCUs I've looked at being sold as "DSP" and for digital power applications happened to have high-res PWM peripherals apart from some STM32 chips so it wasn't really a selection criteria or one that matters much. Even for the ones without HRPWM, resolution looked sufficient to be functional. Cool to hear tricks like manual software interleaving timers and sophisticated control methods to squeeze the most out of chips.

[nchrx]

Did you guys check devices that are a bit more expensive, but also come with a more ready-to-use environment?
I am typically thinking about SoC-based controllers from imperix, e.g https://imperix.com/products/control/bboard.
Thanks to FPGA-based peripherals, the PWM resolutions gets down to 4ns, and everything can be programmed with pre-written C libraries.

[gnuarm]

I don't think the initial post paints an accurate picture of using FPGAs. 

FPGAs
FPGAs are a strong alternative to DSP MCUs. Essentially capable of all the same functions as an MCU but potentially higher bandwidth and with the ability to efficiently transition designs to an ASIC. A downside to FPGAs is much higher unit cost for similar performance and a convoluted intellectual property landscape.

Certainly the unit cost issue is not so much a factor.  FPGAs are available sub $4 these days.  I'm not sure what is "convoluted" about the IP used in FPGAs.  Maybe he is referring to the fact that most IP is proprietary??? 

Development and coding of FPGAs is also fundamentally different to MCU programming which can be a major barrier for designer competence. Engineers/programmers able to competently [emphasis added] program MCUs tend to be more available however since MCU operation falls closer inline with typical computer science education.

While development on FPGAs is different from MCUs, I think the real limitation for most control systems design is finding an engineer who is competent at control systems design.  FPGA design is not really tough.  I've seen software people take it on easily. 

The available reference designs as well as recent academic literature all use DSP MCUs so in addition to the cost disadvantage and lower accessibility, FPGAs are not going to be used over DSP MCUs.

Faulty conclusion based on erroneous data.  In general FPGAs are widely misunderstood.  Articles like this perpetuate the myth of the overly expensive, power hungry, large footprint FPGA.  Oh, well. 

[sandalcandal]

Hey gnuarm!

It's great to hear some differing opinions. It's what I make these posts in the hope of seeing! Would you be able to provide some more details regarding your disagreements?

Certainly the unit cost issue is not so much a factor.  FPGAs are available sub $4 these days.

Can you give any example FPGA SoCs or otherwise including required peripherals for $4 (or comparable cost) with performance on par with these modern DSP MCUs at ~$3.50 with 32-bit FPU ~200MIPS, 100KB RAM, 256kB flash and loaded with peripherals? AFAIK a softcore is never going to be cheaper than an equivalent hardcore.

I'm not sure what is "convoluted" about the IP used in FPGAs.  Maybe he is referring to the fact that most IP is proprietary??? 

I'm referring to the IP cores and other generated IP used in FPGAs to carry out functions that are otherwise normally handled by the microprocessor core(s) and integrated hardware peripherals in MCUs which need licencing agreements to be used in commercial implementations.

While development on FPGAs is different from MCUs, I think the real limitation for most control systems design is finding an engineer who is competent at control systems design.  FPGA design is not really tough.  I've seen software people take it on easily. 

More than getting a basic function working in a prototype by doing something like making a controller in Simulink/LabVIEW then synthesising and uploading the auto generated HDL to an FPGA, I feel like for a high reliability and certified system to be developed efficiently you need some level of understanding of how FPGAs function fundamentally and how they can fail (e.g. latchups, synchrony/timing errors,  configuration errors). It's not an insurmountable challenge to learn the basics of FPGAs and get going but finding people with the competency to do MCU dev seems easier to me compared to finding people with FGPA dev competency though perhaps not enough to warrant consideration? Please do tell me more of why you think professional level FPGA dev isn't as challenging as control loop dev though.

The available reference designs as well as recent academic literature all use DSP MCUs so in addition to the cost disadvantage and lower accessibility, FPGAs are not going to be used over DSP MCUs.

Faulty conclusion based on erroneous data.  In general FPGAs are widely misunderstood.  Articles like this perpetuate the myth of the overly expensive, power hungry, large footprint FPGA.  Oh, well. 

I'd very much like to know where my "data" is erroneous and where these lower cost FPGA based designs are. This isn't an article, it's an open invitation to discussion posted on a forum so I would very much appreciate constructive substance to your disagreements. I'm certainly no expert in FPGAs and I'd love to hear more.

Cheers

[sandalcandal]

Did you guys check devices that are a bit more expensive, but also come with a more ready-to-use environment?
I am typically thinking about SoC-based controllers from imperix, e.g https://imperix.com/products/control/bboard.
Thanks to FPGA-based peripherals, the PWM resolutions gets down to 4ns, and everything can be programmed with pre-written C libraries.

I didn't really check or see any solutions like that in my search. At >$2000 that's more than "a bit more expensive" I'm afraid  That's a price I might be willing to pay for a top shelf dev kit but certainly not something to be integrated into a commercially produced product with our level of price sensitivity. I guess there could be some justification for one-off turn-key industrial systems that have big budgets and need to be done in a hurry. The PWM resolution of these MCUs is already more than enough as has been discussed.

[poorchava]

Also, 4ns PWM resolution is kinda crap. A $2 stm32f7 does almost the same. 100s of ps is good.

A distributor once told me, that people often use lower range Cortex A's FROM Atmel/Microchip for crunching numbers bare metal, no OS.

[gnuarm]

Hey gnuarm!

It's great to hear some differing opinions. It's what I make these posts in the hope of seeing! Would you be able to provide some more details regarding your disagreements?

Certainly the unit cost issue is not so much a factor.  FPGAs are available sub $4 these days.

Can you give any example FPGA SoCs or otherwise including required peripherals for $4 (or comparable cost) with performance on par with these modern DSP MCUs at ~$3.50 with 32-bit FPU ~200MIPS, 100KB RAM, 256kB flash and loaded with peripherals? AFAIK a softcore is never going to be cheaper than an equivalent hardcore.

I'm not sure you understand FPGAs.  They would not use a CPU or DSP in the sense of an SOC.  They allow the calculations to be done in a more logic oriented way.  This may turn out to be like a processor, but it doesn't have to be exactly like a typical MCU. 

I can get an FPGA with multiple multipliers/DSP units (not a DSP CPU, just the math logic) for under $5.  Is price the only consideration?  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.

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.

I'm not sure what is "convoluted" about the IP used in FPGAs.  Maybe he is referring to the fact that most IP is proprietary??? 

I'm referring to the IP cores and other generated IP used in FPGAs to carry out functions that are otherwise normally handled by the microprocessor core(s) and integrated hardware peripherals in MCUs which need licencing agreements to be used in commercial implementations.

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

While development on FPGAs is different from MCUs, I think the real limitation for most control systems design is finding an engineer who is competent at control systems design.  FPGA design is not really tough.  I've seen software people take it on easily. 

More than getting a basic function working in a prototype by doing something like making a controller in Simulink/LabVIEW then synthesising and uploading the auto generated HDL to an FPGA, I feel like for a high reliability and certified system to be developed efficiently you need some level of understanding of how FPGAs function fundamentally and how they can fail (e.g. latchups, synchrony/timing errors,  configuration errors). It's not an insurmountable challenge to learn the basics of FPGAs and get going but finding people with the competency to do MCU dev seems easier to me compared to finding people with FGPA dev competency though perhaps not enough to warrant consideration? Please do tell me more of why you think professional level FPGA dev isn't as challenging as control loop dev though.

Sounds like you are talking more about high reliability design issues than FPGA.  Latchup is a hardware design issue and is common to all CMOS devices, so not solely an FPGA issue.  I don't know what synchronization issues you mean.  There are two I am aware of, no, one really as they are different aspects of the same thing, crossing clock domains, a problem that is well understood and easy to mitigate.  It actually bit me in the ass once in a problem similar to how an Ariane rocket failed if I recall.  I reused some code without considering fully the documentation and omitted an synchronizing FF that is required and I expected to be in the module.  Gave me fits for months with intermittent problems that I kept looking elsewhere to find.  It looked like a software timing bug...  My failure didn't bring down a multi-million dollar rocket. 

Timing errors are an issue, but not one that is especially hard in FPGAs.  You generate timing constraints and the tools work to those constraints reporting errors.  I think sequential software is MUCH more difficult with the indeterminate timing of many processors and programs.  Using interrupts has been worked on for many years and people continue to have problems with 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.  But 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.  You can't put a JAVA programmer in front of a DSP and expect that to work.  So the FPGA programmer may be a bit harder to find, but if you have a real time control designer, send them to school for a week or two, they can be writing HDL relatively quickly.  That's what happened to me.  I was programming Windows 3.1 and was put on an FPGA project.  I got trained in VHDL by accident actually.  At the time schematic was used more commonly and the week class on the new (to me) tools had one day on VHDL.  That was a brilliant flash of light and the rest was history! 

The available reference designs as well as recent academic literature all use DSP MCUs so in addition to the cost disadvantage and lower accessibility, FPGAs are not going to be used over DSP MCUs.

Faulty conclusion based on erroneous data.  In general FPGAs are widely misunderstood.  Articles like this perpetuate the myth of the overly expensive, power hungry, large footprint FPGA.  Oh, well. 

I'd very much like to know where my "data" is erroneous and where these lower cost FPGA based designs are. This isn't an article, it's an open invitation to discussion posted on a forum so I would very much appreciate constructive substance to your disagreements. I'm certainly no expert in FPGAs and I'd love to hear more.

Cheers

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.

I hope I have provided you with some info to consider.