Thanks for the detailed response gnuarm!
One issue with comparing FPGAs based on price is that the vendors only give discounted (meaning realistic) prices by quote. The numbers you see at distributors' web sites are typical qty 1 pricing with no one giving numbers for qty 1k. LCSC has amazing prices for some Spartan 6 devices in the $5 range (XC6SLX16-2FTG256C, big enough for literally any DSP effort you might want to tackle, 32 DSP units), but I don't know for sure they are through proper channels. I personally have been given prices that were less than half the qty 1 list price. If I were a large company buying 10's or 100's of thousands, I could do better.
Interesting to hear FPGAs can be had so much cheaper from non-authorised sources. The lack of freely available quantity pricing is also a bit strange. Any ideas why? Can you say what qty you were asking to get discounted quotes? The 1ku being less than half the single unit cost isn't unusual or any different for MCUs. Even at a third of the $26 single unit price, the XC6SLX16-2FTG256C is still much more expensive than available MCU options which are close to $6 single unit price manufacturer direct.
Yeah, there are other devices at that price or lower. I just mentioned that one because it's on the LCSC site and can be assembled by JLCPCB I believe.
The close to the vest pricing is a result of the FPGA market being dominated by the major telcom equipment makers. They buy the big dollar chips giving the vendors their biggest profits. That's why FPGAs are right up there with the mainstream CPU makers on the leading edge technology. That promotes very competitive pricing, but not giving anything to the enemy that you don't have to. So no public pricing.
Some years back I worked on a product by my company that I expected to sell a couple thousand per year. This was the time of the dot-com bubble and the vendors were eager to get any startup they could, literally. A few months before I had interviewed with a startup in Rockville, MD and in six months they no longer existed. lol
The other quotes I got were working for a telcom test equipment maker who was a big account of both FPGA vendors. They did not focus on one group specifically so they could continue to beat one against the other on price.
I don't think I've ever worked on anything where the difference in price of a dollar or two was a deal breaker. I guess my jobs have been different than yours. I try to work in ways I have confidence will work. I've seen lots of MCU projects have issues from timing, problems that just don't exist in FPGAs.
In the sort of stuff I've built the FPGA does the real work and the MCU handles the user and I/O interfaces like USB updates, etc.
You can construct any peripheral you wish from the FPGA fabric, even ADC. I am presently working on an ADC for a ventilator. It only needs to sample at 200 SPS, but it will be high resolution.
[...] Only one company has an FPGA with significant analog components, but it is expensive. I'm not familiar with the devices you are talking about. I assume the analog must be fairly low end as it is not easy to mix quality analog with quality digital. Every such device I've ever seen has compromises in either the analog, the digital or both.
Cypress has PSOC devices with an MCU, programmable analog and digital. Not an FPGA, but their first generation were pretty limited devices. The CEO insisted they pull out all the stops and build a combined chip with "No Excuses!" What they got was ok, but still nothing special.
If saving the cost of the low end analog is significant then I suppose FPGAs are not for you. But don't think you can't do ADC and DAC in FPGAs. I think I mentioned I am presently working on ADC and DAC in an FPGA design. The ADC are reading sensors and the DAC is to drive audio output. Not high end, but adequate. This is all a soft design, not using any hard IP in the chip. Oh, most FPGAs do have comparators. They call them LVDS receivers, but they work very well and high speed! That's the inputs for the ADCs I'm building.
I don't doubt you can flexibly implement nearly any digital function in FPGA fabric but as mentioned by uer166, integrated analog peripherals such as programmable gain amplifiers, comparators, fast high-res DACs and ADCs are all important peripherals for the application being discussed (digital power conversion) and these peripherals come integrated in DSP MCUs. You don't seem convinced yourself that such required functions can be had more efficiently by using an FPGA based solution.
You use programmable gain amplifiers for control functions??? How do you handle the variable scale factor in the software?
As I mentioned, pretty much every FPGA has comparators built in.
When you say fast and high res ADC and DACs, how high and fast are you talking? I've never seen that in any sort of MCU/DSP device. I've seen lots of 1 MHz 12 bit ADCs and 16 bit sigma-delta converters, but they are usually not so fast.
Conversely, these DSP MCUs particularly the TI C2000 family (including the aforementioned $3.55 TMS320F280049) feature "Control Law Accelerators" that perform math processing independent of the CPU and configurable logic blocks which enable "the calculations to be done in a more logic oriented way". Admittedly, some of the digital design knowledge avoided by using vanilla MCUs is required here but the disadvantages in processing power compared to FPGAs is narrowed whilst still being overall more efficient in cost (and part count, footprint etc.).
I don't claim the speed of FPGAs are what the advantages are about. It is the ease of coordinating the calculations without worrying that sharing a CPU between tasks will mess up timing. Interrupts are a necessary evil in CPUs. But they really mess with hard real time design.
I've never needed licensed IP. There's so much open source or I write my own. What examples?
True, I should have realised there would be plenty of open sources IP cores out there though I lack familiarity. Do you have preferred communities/collections?
What are you referring to exactly? If you mean CPU designs, I don't use them.
I have no idea what you mean about configuration errors??? Configuration is similar to a CPU booting code, but more simple. What is your concern?
I won't argue that there aren't more sequential software programmers than HDL programmers. So sure, you will find one more easily.
Configuration errors are one failure point I've seen in discussion of FPGA reliability and would seem more different compared to a program memory error in an MCU? (not the crux of my point though) I don't doubt one can learn and use good practice to avoid device/design failures but my point is there are barriers to obtaining competency. These barriers are present regardless of whether or not they "should be" present in industry but they are there and I'm not about to go changing the status quo. If you have specific training or resources you would recommend for helping bring an engineer up to scratch though, I would love to hear.
I don't know what you are talking about with the configuration errors. That is what happens when you are working in the lab perhaps but otherwise they configure just fine. In fact, in space applications a problem is radiation induced soft errors altering the configuration. Rather than trying to fix or prevent them they periodically reconfigure the FPGA which clears out the soft errors. I thought that was pretty crazy, but they design the system so any part can be shut down without impacting anything else. So the FPGA can be taken off line for a few milliseconds to reconfigure every minute or so to mitigate the soft errors. If configuration was not reliable obviously this would not work.
... FPGAs by their nature have fewer problems (if any) with real time work and that's the real difficulty in this work, finding people who can program real time control...
...
I would point out that part of this thread is discussing how hard it is to meet real time requirements in DSP and MCUs. That's not a problem with FPGAs, not much of a consideration really. You just focus on your computations and the speed comes for free.
This I'm not so convinced about. My take from discussion in this thread (as well as the other thread) was that I was over estimating the performance needs and digital power conversion can be achieved with less performance and features than I thought necessary or otherwise nice.
I'm still unconvinced FPGAs would be a better solution or the majority of my concerns are invalid. There's a bit of how long is a piece of string but it still doesn't look to me like FPGAs are a better cost-performance choice to meet my requirements by any means.
None the less, thankyou for your responses and I'll edit my OP to link your differing opinions.
It's not really speed as such. It's the issues created from trying to make a sequential processor look like it is doing things in parallel while in an FPGA things can literally happen in parallel. In essence, FPGAs take the "hard" out of hard real time. Consider it risk mitigation. That's the sort of thing I focus on rather than extracting the last penny from the BoM.
I never have a problem with the labor pool. I'm the labor pool.