MicroFPGA – A coming revolution in small electronics (2019) [video]

MicroFPGA – A coming revolution in small electronics (2019) [video]
youtube.com

Interesting talk but I remain skeptical. Anyone got stats on how FPGA ecosystems have fared vs. MCUs over chipageddon? From a cursory search it seems: 1. There are very few PMOD suppliers 2. They do extremely low volume. So low, in fact, it appears there is simply ~no demand. Therefore, good luck hiring and scaling a team that is familiar with this stuff on a budget. Especially since the half-life of the software tooling is probably 3-6 months and the majority of toolchains are still vendor-specific. Further, in terms of supply chain security, the plethora of suppliers for lower-end MCUs cannot be matched in lower-cost FPGA offerings, which rely heavily on specific vendors who cannot readily guarantee global availability.

M-LVDS is an onboard high speed signalling standard whereas USB and ethernet are specifically designed for off-board connectivity (and have features like power distribution, dynamic topologies, etc.). They are apples and oranges.

The notion of a baseboard for these things is so simple, why isn't there a FPGA+PMOD+baseboard PCB generation and fabrication webservice offered by Digilent? Because it's not that simple. PCB design is often largely constrained by non-electronic functional aspects such as form factor, thermals, mounting and assembly considerations. Having modules to just plug in is great for a quick test, but the second you actually want a product you have to consider the whole problem and that typically means multiple iterations of traditional PCBs for these reasons.

Conclusion: The case is over-stated and the market has effectively rejected the current offerings.

No data I can offer as such, but anecdote from several suppliers who integrate some big name FPGAs into their products. They've seen supply dry up like other chips, causing several months of delays to lead times. It's not "zero supply", but a significant reduction in supply.

The vendor-specific toolchains and supply chain security issues you point out are huge issues, and ones most people (even security experts) are a bit blind to. You can't verify the state of a programmer FPGA by inspection (at least not using normal techniques), so you can't easily verify the output of your bitstream compiler, which is the output of the complex design toolchain.

The toolchain output and bitstream are probably encrypted (or heavily obfuscated at minimum), and this will make it near impossible to audit the component. I don't see how anyone can defend against a Solarwinds (i.e. Stuxnet style attack) in the long run, as a toolchain compromise could introduce arbitrary modification of the logic, and would be unlikely to be spotted, and very difficult to ever detect once in the field.

I want to write FPGA code like any other high-level programming language (but quickly dismiss that the hard part of developing native HDL is in fact that it's fundamentally a lot more akin to architecting physical hardware).

I want to use FPGAs because they're powerful (but only when a conceptual design aligns with a traditional microcontroller architecture).

I want to use FPGAs because they're flexible (but I need to nerf proprietary building blocks that endow specific devices with competitive edge, or trade significant performance in other ways to do so).

I want to commodify the development peripheral market (but only if they conform to a certain commercially trademarked and weakly defined spec[2] inherently constrained to low-frequency applications where sloppy SI is presumed to be inconsequential).

I want to standardize high-performance interfaces (so arbitrarily "abandon standards you don't like" and simply write your own, but only if they're not "annoying"...and look like a custom FIFO with specific signal labels).

I'm sure this will be an unpopular opinion, but the positive feedback loop generated around this topic needs a stability check.

[1] https://youtu.be/ME_e06ApxJA?t=2080

[2] https://digilentinc.com/Pmods/Digilent-Pmod_%20Interface_Spe...