I do personally feel that the #1 application of FPGAs is to make short run and high-end hardware fantastically more expensive for business and government (+military) customers.
As it has nothing to do with electronics, I'll put it to the wisdom of the crowd to decide if this application is conventional or unconventional!
Not sure I understand. Take for example applications in communications where you need a real time signal processing. The alternatives (custom ASICs) are several orders more expensive. I would actually say the opposite, FPGAs make short-run, high-end affordable to others that are not government or large coperations.
I feel like we're constantly spoiled by the clock speed of computers, they are good enough for so many things. FPGAs can make simple things a bear to implement, and you will just get there faster.
But there's a bunch of things where FPGAs are like discovering fire, all the discrete digital logic you ever wanted in the palm of your hand (until you have to meet timing).
You should always do the simplest thing that could possibly work…
That's giving a lot of credit! I see way more of "this FPGA could have been two logic chips and an EEPROM"
Yeah obviously FPGA's are unquestionably awesome devices, but IMO the real problem with them is they have no long tail or economies of scale compared to other device types. Having worked with them personally, I mostly believe this is because there aren't really any great cross vendor standards analogous to a CPU's ISA. The lack of interoperability absolutely destroys the ability of competition to benefit customers. I'd like to be able to buy a modern $5 part with capabilities equivalent to something like a Cyclone IV, but there's nothing even remotely close.
It involves timing laser pulses very accurately and quickly and potentially concurrently. A regular microcontroller with interrupts wouldn't work well with 20+ sensors as each interrupt could potentially block another one happening at the same time.
So with an FPGA you define a "block" of hardware that handles one sensor, then copy it multiple times and have each block send the final timing data to an overarching hardware block. That way each sensor has its own dedicated hardware block and they can work in parallel.
The arming process provides the key and once the single-use weapon hits the target, there's no way for the enemy to get to the original bitstream.
So the enemy can't reverse engineer any secrets that are part of the logic.
Can't do same with ASICs.
shrug I can't really say anything except that's not the only way to accomplish that sort of thing. And if it's a common enough use case that you need to build it into millions of pieces of ammunition, it doesn't explain why economies of scale never kicked in or a more purposeful custom part was never designed.
Limitless military budgets, by contrast, explain quite well why this /hasnt/ happened.
The cost of making a chip is proportional to the size of the chip and the process node, and that's the end of the story. FPGA and CPU quite literally cost the same to manufacture; it doesn't explain why the one categorically is priced 10 times higher than the other by die area, even in the long tail of the supply chain.
You can make latches with ASIC perfectly well. Or even more complex memory elements.
Unless you make an ASIC that's effectively an FPGA.
The benefit being highlighted is that the "executable code" of the system is stored in volatile memory. The same can be done for a more traditional software system.
To be fair, more people use the term ASIC wrong than right.
It seems unreasonable to me to cite the name "application specific" and conflate that to "single product." Nobody would debate that an Nvidia Tegra T20, for example, is an ASIC and yet it is contained within numerous products. An even more prevalent example would be any TI buck converter, used in a likely unknowable number of products.
I expect the level of application specificity needed to satisfy a particular view on ASIC varies by exposure and domain usage, which is why I think it's more like "firmware" than like "program" in a taxonomy of names. I also think that ASICs is a kind of parent group, members of which are things like microcontrollers, microprocessors, memory devices, FPGAs, and CPLDs. To draw such a hard contrast between "ASIC" and "FPGA" seems to not appreciate that an FPGA necessarily has fixed design elements (components, peripherals, etc.) to effect the function and provide more tight tolerance functionality like high speed signaling, which are limited resources by locality (only assignable within some bank of pins, for example).
- IP being ephemeral is a feature, preventing duplication and extraction by an adversary.
- IP doesn't leave your organization: by deploying an FPGA, no ASIC fab has access to it.
That is all to say the security is not coming the FPGA but from a systems design process that prioritizes security. There are a number of solutions to the problem which may or may not involve FPGAs but when you scramble it all up along with the preverse incentives driving the pricing/costing of these contracts, it's pretty clear that good+expensive solutions are chosen more often than good+inexpensive solutions.
How exactly are you analyzing it for any meaningful information?
It's absolutely not "easier" to attack an FPGA in this manner because the information yielded isn't something a smart fellow can just pop into IDA and glean every secret from: it's a highly optimized gate configuration with massive amounts of redundant register, LUT, etc. insertion. All structures resembling "code" are gone.
You'll never see RTL from this information and there's nothing like assembler for it.
All of this is assuming that the nation state actor can keep the device powered while doing this extraction, because once that voltage drops even a couple hundred mV below the allowed value, that bitstream is gone. Tamper switch, timer, batteries dead, a 30 cent microcontroller analyzing environmental conditions, velocity, etc. and cutting the power: it's gone forever.