Picking a DSP MCU for Power Conversion - Experiences? - Page 1
Forum section: electronics / projects

author: sandalcandal
author_rank: Unknown
timestamp: January 05, 2021, 01:42:29 am
content: TL;DRTrying 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 C2000family for my needs but STM32G4 is a strong and popular alternative.Detailed post on decision here.BackgroundAs part ofthe pilot 1kW CLLC converter design I've posted aboutand 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 MCUThe 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 AnalogIn 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 powerDiscrete Analog Feedback NetworkThe 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 ICsAnalog (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 ASICsDSP 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.FPGAsFPGAs 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 gnuarmOther MiscThere 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-analogHybridsHybrid 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 FeaturesNot all DSP MCUs are created equal and having an idea of what will be required or otherwise beneficialProcessor Core Frequency:>100 MhzADC Bit Depth:>11 bits usableADC Sample Rate:>2 MSPSADCs:2 minimum, more than 5 not usefulPWM Peripherals:<100ns resolutionECC MemorySafety CertificationsSingle CoreAvailable CLLC or LLC reference designFPUProcessor Core Frequencyneeds 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 Depthmust 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 Rateneeds 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 ADCsneeds 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 Peripheralsneed 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 Memoryis 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 Certificationsare 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 anAvailable Reference Design CLLC or LLCwith 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 aSingle CoreMCU 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?AnFPU(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 ListTexas Instruments: C2000https://www.ti.com/microcontrollers/c2000-real-time-control-mcus/overview.htmlChips available meeting wishlistProprietary TI core?Optional CLA and PGA peripheralsBest value in terms of features and performance per $Wide performance/spec range availableReference Design 6.6 kW CLLLC using TMS320F28004xhttps://www.ti.com/tool/TIDM-02002https://www.ti.com/product/TMS320F280049Reference Design 500 W 2-phase LLC using TMS320F280025Chttps://www.ti.com/tool/TIDM-1001Also seems popular in designs from outside TI. Wolfspeed reference designs using C2000 MCUsWolfspeed Reference Designs:Oct 2020 Reference Design 22 kW CLLC bidirectional using TMS320F28377Dhttps://www.wolfspeed.com/power/products/reference-designs/crd-22dd12n2019 Reference Design 6.6 kW LLC using TMDSCNCD280049Chttps://www.wolfspeed.com/power/products/reference-designs/crd-06600dd065n2019 Reference Design 6.6 kW CLLC bidirectional using TMS320F28377Dhttps://www.wolfspeed.com/power/products/reference-designs/crd-06600ff065n2018 Reference Design 6.6 kW CLLC bidirectional using TMS320F28377Dhttps://www.wolfspeed.com/crd-06600ff10nTMS320F28377D Product Page:https://www.ti.com/product/TMS320F28377DAcademic Papers:5kW CLLC bidirectional using TMS320F28335https://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: XMC4000https://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 wishlistARM® Cortex™-M4 basedNo configurable logic peripheralsMost expensive but still within budgetXMC4400 series looks particularly relevantReference Design 3 kW 2-phase LLC usingXMC4400-F64K512 BAhttps://www.infineon.com/cms/en/product/evaluation-boards/eval_3kw_2llc_cfd7/STMicroelectronics: STM32G4https://www.st.com/en/microcontrollers-microprocessors/stm32g4-series.htmlChips available meeting wishlistARM® Cortex™-M4 basedNo configurable logic peripheralsAlso lower spec 72 MHz STM32F3 series available, mostly intercompatible? Clock speed likely too low for highest target operating frequency however.Reference Design STM32F334https://www.st.com/en/evaluation-tools/steval-dpsllck1.htmlMicrochip: dsPIC33https://www.microchip.com/design-centers/16-bit/products/dspic33eMicrochip seems to be pushing the dsPIC33C (100 MIPS capable) and dsPIC33E (70 MIPS capable) families for digital power.NO FPUConfigurable logic peripheralsReference Design, 200 W half bridge LLC usinghttps://www.microchip.com/developmenttools/ProductDetails/DC/DC-LLC-Resonant-ConverterAnalog Devices: ADSP-CM4xxNo 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 MCUshttps://www.analog.com/media/en/technical-documentation/tech-articles/IC-Ecosystem-for-Driving-Next-Generation-SiC-GaN-Power-Converters.pdfRenesas: RA6T1https://www.renesas.com/us/en/products/microcontrollers-microprocessors/ra-cortex-m-mcus/ra6t1-120mhz-arm-cortex-m4-assp-ra6-motor-controlMeant primarily for motor control but has peripherals useful for digital power.No reference designNot offering mixed-signal/DSP MCUs:Silicon LabsChoosing the MCUThe main contenders are the STMicro STM32G4, Infineon XMC4000 and TI C2000. All have a full and complete feature set and excellent specs.Only theXMC4000 andC2000 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.

author: uer166
author_rank: Super Contributor
timestamp: January 05, 2021, 03:29:08 am
content: Great stuff, the only comment I have is re:Quote from: sandalcandal on January 05, 2021, 01:42:29 amI 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.

author: sandalcandal
author_rank: Unknown
timestamp: January 05, 2021, 03:53:16 am
content: Thanks for having a look uer166, great advice!Quote from: uer166 on January 05, 2021, 03:29:08 amThanks, 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.

author: Phoenix
author_rank: Frequent Contributor
timestamp: January 05, 2021, 04:49:35 am
content: Hi scandalcandalI 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:ProcessorC28x+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/873371Most 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.ADCCan 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.PWMVery 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.QuoteThe 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.QuoteThis 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.

author: NiHaoMike
author_rank: Super Contributor
timestamp: January 05, 2021, 05:23:37 am
content: 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.

author: sandalcandal
author_rank: Unknown
timestamp: January 05, 2021, 06:21:55 am
content: Thanks for the thoughts and experiences Phoenix!Quote from: Phoenix on January 05, 2021, 04:49:35 amThe original source post for that table comparing performance from Nov. 2010 states the Cortex-M4F takes 3 cycles for a MAChttps://e2e.ti.com/support/microcontrollers/c2000/f/171/p/21092/276807#276807However,the XMC4400 chip I was looking atadvertises 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.

author: gae_31
author_rank: Contributor
timestamp: January 05, 2021, 07:02:35 am
content: 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)

author: Berni
author_rank: Super Contributor
timestamp: January 05, 2021, 07:15:03 am
content: 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 etcThe 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.

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: January 05, 2021, 08:15:22 am
content: STM32H750VBT6 is good choice too, it can be bought around 3.5$ in china

author: sandalcandal
author_rank: Unknown
timestamp: January 05, 2021, 08:49:20 am
content: Quote from: gae_31 on January 05, 2021, 07:02:35 amThanks for having a look and sharing that,the UCD3138looks 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/Creehttps://www.wolfspeed.com/crd-20dd09p-2does 20kW using the (relatively) dirt cheapNCP1395(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!Quote from: Berni on January 05, 2021, 07:15:03 amI 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.Quote from: NiHaoMike on January 05, 2021, 05:23:37 amSounds 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.

author: Phoenix
author_rank: Frequent Contributor
timestamp: January 05, 2021, 10:30:40 am
content: Quote from: sandalcandal on January 05, 2021, 06:21:55 amI 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.

author: Berni
author_rank: Super Contributor
timestamp: January 05, 2021, 11:23:16 am
content: Quote from: sandalcandal on January 05, 2021, 08:49:20 amI 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 STM32F4However 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.

author: poorchava
author_rank: Super Contributor
timestamp: January 05, 2021, 02:11:34 pm
content: 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...)

author: poorchava
author_rank: Super Contributor
timestamp: January 05, 2021, 05:15:24 pm
content: 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.

author: Berni
author_rank: Super Contributor
timestamp: January 05, 2021, 07:00:38 pm
content: Quote from: poorchava on January 05, 2021, 05:15:24 pmYep 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).

author: gae_31
author_rank: Contributor
timestamp: January 05, 2021, 09:08:23 pm
content: QuoteI 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.pdfQuoteThe 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.Quote from: Berni on January 05, 2021, 07:00:38 pm

author: gae_31
author_rank: Contributor
timestamp: January 09, 2021, 03:37:17 pm
content: @sandalcandal, I wonder if you were able to make a decision after getting all the different opinions

author: sandalcandal
author_rank: Unknown
timestamp: January 10, 2021, 12:58:04 pm
content: 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: KV4xProduct PageARM® Cortex™-M4 basedLacks ECC MemoryHigh cost relative performance.Reference Design, 250W LLC using KV46F256VLL15https://www.nxp.com/design/designs/kv46-digital-llc-converter-reference-design:LLC-RESONANT-CONVERTERAlso NXP MC56F83xxx being marketed for digital powerProduct pageARM® Cortex™-M4 basedECC MemoryMore expensive than XMC4400 but less features and lower performance.Further Research and Consideration 1Looking at some of the discussion here and inthe 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 publishedand recentbenchmarks 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 peoplewe've recruitedalso 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.SoC2000 is looking like the best choiceand 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?

author: sandalcandal
author_rank: Unknown
timestamp: January 10, 2021, 02:25:38 pm
content: Quote from: blueskull on January 10, 2021, 01:22:36 pmPretty 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.

author: nchrx
author_rank: Newbie
timestamp: January 28, 2021, 12:15:31 pm
content: 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.ghttps://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.

author: gnuarm
author_rank: Super Contributor
timestamp: January 28, 2021, 09:06:34 pm
content: I don't think the initial post paints an accurate picture of using FPGAs.QuoteCertainly 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???QuoteWhile 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.QuoteFaulty 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.

author: sandalcandal
author_rank: Unknown
timestamp: January 29, 2021, 10:57:33 am
content: 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?Quote from: gnuarm on January 28, 2021, 09:06:34 pmCan 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.Quote from: gnuarm on January 28, 2021, 09:06:34 pmI'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.Quote from: gnuarm on January 28, 2021, 09:06:34 pmMore 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.Quote from: gnuarm on January 28, 2021, 09:06:34 pmI'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

author: sandalcandal
author_rank: Unknown
timestamp: January 29, 2021, 11:15:41 am
content: Quote from: nchrx on January 28, 2021, 12:15:31 pmI 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 afraidThat'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.

author: poorchava
author_rank: Super Contributor
timestamp: January 29, 2021, 07:02:52 pm
content: 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.

author: gnuarm
author_rank: Super Contributor
timestamp: January 29, 2021, 07:49:47 pm
content: Quote from: sandalcandal on January 29, 2021, 10:57:33 amI'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.QuoteI can't speak to that. I've never needed licensed IP. There's so much open source or I write my own. What examples?QuoteSounds 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!QuoteI 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.

author: uer166
author_rank: Super Contributor
timestamp: January 29, 2021, 08:02:47 pm
content: 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.

author: gnuarm
author_rank: Super Contributor
timestamp: January 30, 2021, 01:06:43 am
content: Quote from: uer166 on January 29, 2021, 08:02:47 pmThat 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.

author: sandalcandal
author_rank: Unknown
timestamp: January 30, 2021, 05:23:46 am
content: Thanks for the detailed response gnuarm!Quote from: gnuarm on January 29, 2021, 07:49:47 pmInteresting 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, theXC6SLX16-2FTG256Cis still much more expensive than available MCU options which are close to $6 single unit price manufacturer direct.Quote from: gnuarm on January 29, 2021, 07:49:47 pmQuote from: gnuarm on January 30, 2021, 01:06:43 amI 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.).Quote from: gnuarm on January 29, 2021, 07:49:47 pmTrue, 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?Quote from: gnuarm on January 29, 2021, 07:49:47 pmConfiguration 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.Quote from: gnuarm on January 29, 2021, 07:49:47 pmThis 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.

author: gnuarm
author_rank: Super Contributor
timestamp: January 30, 2021, 09:14:29 am
content: Quote from: sandalcandal on January 30, 2021, 05:23:46 amYeah, 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. lolThe 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.QuoteYou 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.QuoteI 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.QuoteWhat are you referring to exactly? If you mean CPU designs, I don't use them.QuoteI 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.QuoteIt'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.

author: Siwastaja
author_rank: Super Contributor
timestamp: January 30, 2021, 09:37:14 am
content: 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 conversionperipheralsthat happen to do the job for me, so there is noneedto 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: January 30, 2021, 09:53:02 am
content: 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.

author: gnuarm
author_rank: Super Contributor
timestamp: January 30, 2021, 06:38:37 pm
content: Quote from: Siwastaja on January 30, 2021, 09:37:14 amThank 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.QuoteThe $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.QuoteAgain, 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.QuoteOp 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.QuoteWhat 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.QuoteTo 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.

author: gnuarm
author_rank: Super Contributor
timestamp: January 30, 2021, 06:41:41 pm
content: Quote from: Siwastaja on January 30, 2021, 09:53:02 amI 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.

author: uer166
author_rank: Super Contributor
timestamp: January 30, 2021, 07:34:51 pm
content: 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: January 30, 2021, 07:42:28 pm
content: 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 bestillwriting 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.

author: sandalcandal
author_rank: Unknown
timestamp: January 30, 2021, 11:34:10 pm
content: 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?Quote from: gnuarm on January 30, 2021, 06:38:37 pmWith 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.

author: poorchava
author_rank: Super Contributor
timestamp: January 31, 2021, 08:51:38 pm
content: 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 thatFPGA 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.

author: NiHaoMike
author_rank: Super Contributor
timestamp: February 01, 2021, 01:45:51 am
content: Quote from: poorchava on January 31, 2021, 08:51:38 pmDepending 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.)

author: Marco
author_rank: Super Contributor
timestamp: February 01, 2021, 02:06:59 am
content: Quote from: NiHaoMike on February 01, 2021, 01:45:51 amWith somewhere between 19 and 5 cycles of group delay depending on the decimation filter ... not ideal.

author: sandalcandal
author_rank: Unknown
timestamp: February 01, 2021, 02:11:11 am
content: Quote from: poorchava on January 31, 2021, 08:51:38 pmAre there any challenges in managing ADC to FPGA latency and bandwidth?

author: gnuarm
author_rank: Super Contributor
timestamp: February 01, 2021, 08:43:34 am
content: Quote from: sandalcandal on January 30, 2021, 11:34:10 pmI 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.QuoteThe 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.QuoteMostly 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: February 01, 2021, 02:18:37 pm
content: 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.

author: gnuarm
author_rank: Super Contributor
timestamp: February 01, 2021, 06:37:27 pm
content: 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.

author: gnuarm
author_rank: Super Contributor
timestamp: February 01, 2021, 06:44:42 pm
content: Quote from: Siwastaja on February 01, 2021, 02:18:37 pmThat 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.

author: gnuarm
author_rank: Super Contributor
timestamp: February 01, 2021, 06:54:42 pm
content: Quote from: NiHaoMike on February 01, 2021, 01:45:51 amSorry 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?

author: Siwastaja
author_rank: Super Contributor
timestamp: February 01, 2021, 07:15:32 pm
content: Quote from: gnuarm on February 01, 2021, 06:37:27 pmI 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.

author: NiHaoMike
author_rank: Super Contributor
timestamp: February 02, 2021, 12:28:39 am
content: Quote from: gnuarm on February 01, 2021, 06:54:42 pmLuckily, 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.

author: uer166
author_rank: Super Contributor
timestamp: February 02, 2021, 01:07:13 am
content: Quote from: gnuarm on February 01, 2021, 08:43:34 amSure 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.

author: gnuarm
author_rank: Super Contributor
timestamp: February 02, 2021, 01:27:53 am
content: Quote from: Siwastaja on February 01, 2021, 07:15:32 pmThat'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.QuoteOk, so they are trying to catch up with FPGAs. Good.QuoteI 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.

author: gnuarm
author_rank: Super Contributor
timestamp: February 02, 2021, 01:43:11 am
content: Quote from: NiHaoMike on February 02, 2021, 12:28:39 amA 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?

author: NiHaoMike
author_rank: Super Contributor
timestamp: February 02, 2021, 04:24:55 am
content: Quote from: gnuarm on February 02, 2021, 01:43:11 amYes, data communications using a RF carrier over the power line. The idea being that while every zero export inverter I'm aware of on the market requires the inverter to be connected to sensors using a dedicated cable in order to zero export to upstream loads, my design just requires installation of the sensors and a PLC transmitter module. The actual PLC modulation format I decided to use was a FM carrier at about 800kHz-1.4MHz (can be changed using a command over the reverse PLC channel) with an ASK modulated pilot tone for digital power readings and a subcarrier for the difference between the two phases. I went with that rather than a fully digital modulation since it would make the transmitter a lot simpler and also make it simpler to meet latency requirements. The same signal is sent over both phases and the coherent diversity receiver does some "beamforming" tricks to mitigate interference. (In the process, I also learned just how complex is the stuff my friend Tiffany Yep, a digital communications engineer, works on. Now if only she had more time to teach me DSP using Verilog...)The voltages and currents are digitized at 768kHz, which is quite fast considering the PWM is on the order of 15kHz. The "core" frequency in the FPGA is likely to be the 36.864MHz bit clock for the ADCs or some multiple of it. The FPGA is a LX100, a bit dated and probably much bigger than necessary, but I have several boards that I got for cheap.

author: Phoenix
author_rank: Frequent Contributor
timestamp: February 02, 2021, 05:06:42 am
content: Quote from: NiHaoMike on February 02, 2021, 04:24:55 amThat's a good idea. Is this a commercial zero export inverter you're working on, or more of a hobby project? Are you also making your own power meter, or can you interface to other meters that already have PLC? In guessing own power meter since it's home brew PLC.

author: gnuarm
author_rank: Super Contributor
timestamp: February 02, 2021, 07:46:23 am
content: I've worked a bit in comms so I am at least familiar with the terms you used.For an ADC the numbers you provide would give you only about 5.5 bits. You can bump that up to 7 bits if you use a PLL to generate a ~100 MHz clock for the ADC circuit, ~8 bits with a 200 MHz clock. The limitation will be the I/O cells themselves. Rising and falling edge asymmetries and high/low drive level asymmetries will distort the average value of the feedback signal, at some point dominating as the rate increases. You can also gain one bit of resolution for each halving of the data rate from the ADC. So you might ask yourself if you really need a 50x ratio between the ADC sample rate and the control PWM rate. I'm not sure what you would do with that data unless you are extrapolating curves.The ADC I am working on is sampling at 33.55 MHz but with a very low data rate, so lots of decimation and averaging. The counter is 18 bits, so the other end of the scale from what you are doing.Just as a point of comparison, the audio output from the device I am working on uses 32 kHz to produce audio tones. Seems they like their alarms to not be alarming, but rather musical.

author: NiHaoMike
author_rank: Super Contributor
timestamp: February 02, 2021, 01:53:16 pm
content: Quote from: Phoenix on February 02, 2021, 05:06:42 amA hobby/research project. I am making the power meter, there are ready made power meters specifically for zero export inverters but all of them use a low latency interconnect like Ethernet or high bitrate RS485/CAN. Because the latency of a "bare metal" Ethernet interface is incredibly low, even adding a "store and forward" switch in between will likely prevent it from working properly, let alone anything more complex like a pair of Homeplug adapters. (I did look at one inverter using such a power meter and the directions say to connect the meter directly to the inverter, no switches or routers in line.)

author: Phoenix
author_rank: Frequent Contributor
timestamp: February 02, 2021, 09:54:41 pm
content: Quote from: NiHaoMike on February 02, 2021, 01:53:16 pmAs much as I like the PLC approach, I'm not sure I agree with the dire need for low latency. The response time requirements that I have seen are in seconds (VDE 4105 reduce to 10% of power excursion in 3s and AS/NZS 4777 draft talks about 15s) and you can do zero export using "slow" RMS measurements. Getting rid of the dedicated cable is the real benefit that I see. Could also consider an ISM band wireless which might be cheaper.

author: NiHaoMike
author_rank: Super Contributor
timestamp: February 03, 2021, 02:29:59 am
content: I think the "zero export" definition for some areas like Hawaii are relaxed for latency requirements provided the inverter has a graceful voltage limiting feature. I think that was done so that some older inverters (that have a production limiting feature but not a true zero export feature) can still be used for new installs by simply adding on an export limiter module. If such a loose definition of zero export was created specifically to make it easier to make zero export inverters with wireless sensors, I haven't found any on the market.Other than working around limitations of older equipment that isn't really designed for it, it's not hard at all to make an inverter with wired sensors that can react to load changes in milliseconds. With some control loop tuning, a few hundred microseconds or less can be achieved. One big reason to use a zero export inverter is to not have to go through the hassle of getting the system to be allowed to export (which nowadays sometimes pays too little to be worth the hassle, especially for smaller setups) and therefore work with an existing electrical system including a utility meter that specifically looks for reverse power flow as a possible hacking attempt. Limit the reverse power flow to be a fraction of a cycle and it will basically act somewhat like a reactive load during that instant.

author: Marco
author_rank: Super Contributor
timestamp: February 03, 2021, 03:12:33 pm
content: Regulation getting super uptight about microsecond level reversal of current doesn't make a whole lot of sense to me. A couple watt of poor power factor current getting sent upstream isn't a problem.

author: nudge
author_rank: Contributor
timestamp: February 03, 2021, 09:36:16 pm
content: I’ve designed power converter controller boards using TMS320F2810 and TMS320F28069 parts. TI parts are pretty standard in the industry.Pros are fast/hi-res & immediate trip PWMs, decent ADCs, fast trig math support, and tons of supporting documentation and resources for power conversion design.Cons are propriety toolchain, and less advanced peripherals for applications processor type work — they’re aimed at real-time control applications. Having said that, some of the newer chips have both a C2000 + ARM Cortex-M4 core in a single chip, this is great for offloading the connectivity and applications work to the M4 core (eg TMS320F28386S).

author: gnuarm
author_rank: Super Contributor
timestamp: February 03, 2021, 09:52:06 pm
content: Quote from: nudge on February 03, 2021, 09:36:16 pmSort of reminds me of Segal's law, "A man with one watch knows what time it is; a man with two watches is never sure."That said, I suppose two processors can be better than one... sometimes. The trick is knowing when those times are.

author: NiHaoMike
author_rank: Super Contributor
timestamp: February 03, 2021, 11:56:36 pm
content: Quote from: Marco on February 03, 2021, 03:12:33 pmMicroseconds would indeed be overkill, but stopping reverse power flow in milliseconds or within a cycle or two is not difficult. As mentioned, the main reason is to not trip reverse power detection on utility meters.