5 ms·
I like the strain gauge application best! I do personally feel that the #1 application of FPGAs is to make short run and high-end hardware fantastically more e
by gorkish 3y ago
I like the strain gauge application best!
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!
- cycomanic 3y ago> 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. 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.
- gimmeThaBeet 3y agoI kind of empathize where they are coming from, my electronics version of "this meeting could have been an email" is "this fpga could have been an arduino". 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).
- dfox 3y agoApart from my overengineered audio stuff (which is intentionally overengineered, as it is mostly an hobby project/research vehicle) I'm guilty of designing what was essentially an simple scintillation detector around fast ADC, somewhat beefy FPGA and bunch of synchronous SRAM, the final shipped hardware had MSP430, bunch of discrete 74ACT logic and bunch of discrete analog comparators instead of the ~100MSps ADC… You should always do the simplest thing that could possibly work…
- deleted 3y ago[deleted]
- gorkish 3y ago> "this fpga could have been an arduino" That's giving a lot of credit! I see way more of "this FPGA could have been two logic chips and an EEPROM"
- gorkish 3y agoThe FPGA in my scope probe that is dutifully implementing the functionality of an EEPROM while loading its configuration from an even larger EEPROM exists in a state of extreme disagreement to your comment. 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.
- ShadowBlades512 3y agoFor a slowly increasing number of use cases, Lattice is starting to change that. Not quite Cyclone IV, but the ECP5 can be pretty decent for the price. Over time I think their new CertusPro-NX line is going to become interesting.
- gorkish 3y agoThat is good! I am hopeful as well! However I don't think that the parts that you are talking about are fundamentally solving the problems I discussed. You have always been able to go to a vendor outside of the top few and get cheaper parts -- for the small price of having to rework basically everything. Something has to break the vendor lock-in a little more completely before this can fundamentally change.
- timeinput 3y agoAre you saying that FPGAs increase the production cost of low rate (<1000 units) hardware? Compared to ASIC fabrication?
- gabrielhidasy 3y agoProbably compared to micro controllers that are getting fast enough to do a lot of what used to take custom hardware or FPGAs
- polishdude20 3y agoOne project I had to learn to use an FPGA for was to make a working sensor system for the HTC Vive. 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.
- vardump 3y agoFor military use FPGAs with encrypted bitstreams is a pretty interesting application. 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.
- marcosdumay 3y ago> Can't do same with ASICs. You can make latches with ASIC perfectly well. Or even more complex memory elements.
- vardump 3y agoSure, but the point was that nothing of the original logic will be recoverable, once the FPGA loses power. Unless you make an ASIC that's effectively an FPGA.
- opello 3y agoFPGAs are ASICs. :) 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.
- jecel 3y agoTo nitpick, FPGAs are COTS (Commercial Off The Shelf) components since a single FPGA can be bought to be used in a huge number of different products. An Application Specific Integrated Circuit is designed for use in a single product, as the name says. A classic example were the two big chips Apple designed for the Apple //e to replace the large number of TTLs used by the Apple ][+. To be fair, more people use the term ASIC wrong than right.
- opello 3y agoI think that's a reasonable distinction to make. I also think it's more like "firmware" insofar as it's a squishy, environment-dependent usage. 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).
- Brian_K_White 3y agoI think you meant more affordable or less expensive? Or even viable/possible at all.
- 15155 3y agoOn FPGAs for military applications: - 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.
- sterlind 3y agoIsn't that how those Fortezza crypto cards worked? The chips leave the factory unclassified, then the NSA loads their classified Suite A algorithms onto them?
- gorkish 3y agoFPGAs aren't inherently secure. I'd assume that a nation-state-level actor would have the ability to extract the bitstream from an operating FPGA which would invalidate both of your statements if additional protections and security considerations are not met in the hardware design. But you are correct that an FPGA readout is a far more difficult attack than, say, bypassing the read protection on a microcontroller's flash. At the same time, it might be easier to attack an FPGA than a modern CPU's secure area/secure enclave. 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.
- 15155 3y agoWhat are you doing with a Xilinx bitstream even if you have it besides producing more of the device without authorization? 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.