moving logic from s/w (e.g. OS kernel) to f/w (e.g. BIOS/UEFI/fastboot/MCU bootloader or the EC/BMC¹) or h/w just because the latter is harder to reverse-engineer smells of #security through obscurity
#FPGA bitstreams, just like the #firmware, don’t actually need any higher assurance than s/w – they’re just as easy to patch if there is still access to the h/w
so only #ASIC’s stand out in this requirement – they really can’t be altered after production
¹ Embedded Controller (a.k.a. keyboard controller), found on all laptops; Base Management Console (another mocrocontroller found on servers)
hypothesis: #ASIC’s made with very old topological norms (gate sizes) may still be way faster, cheaper, and more energy-efficient that the implementations on modern #FPGA’s the only problem is that you still would need to make them in pretty large batches, and therefore somebody to sell them to in those quantities also the quality assurance has to be substantially higher^
@amiloradovsky There are a lot of fabs that would make you ASICs on old norms. You get the hardware and they get continued returns on their investment. And, yes, those would be faster and cheaper than FPGAs. Everybody wins.
The question is why isn't everyone doing this.
@dpwiz my impression is that’s because everybody wants competitors to the huge chips, like those found in the modern off-the-shelf servers, desktops, laptops, and mobile devices – those really need most recent topological norms or one IC will become a set of several ones, the frequencies will be much smaller, and the power consumption much higher while the small chips, such as MCUs, are already very inexpensive and trusted enough that nobody wants to pay for making new brands of them
still though there are customers who’d rather use the FPGAs than the very integrated chips made by somebody they can’t trust, and there the sets of poorly integrated ASICs would be appreciated, the problem is the quantities it’s also hard to get into the huge chips because the protocols and standards are changing very often – you have to implement them very quickly or they’ll become obsolete by the time you’ve finished basically if your chips are poorly integrated, the protocols and standards they may support would also be “obsolete” and therefore the s/w running in it would be of old versions (e.g. try running modern Linux on a x86-32)
the proper solution is to reject the bloated s/w (for users) and make it small and still usable (for developers), then the h/w that may run it can be not only made by the oligopolies then again most of the high-end h/w is being used for entertainment and web services – the gamers won’t tolerate less polygons per frame that they’re used to and the webshit is so quick and easy to make and just enough to automate the business processes IDK what really can be done about it, I can only try and not be part of the problem