[HN Gopher] Unconventional Uses of FPGAs
___________________________________________________________________
Unconventional Uses of FPGAs
Author : voxadam
Score : 108 points
Date : 2024-03-18 23:59 UTC (23 hours ago)
(HTM) web link (voltagedivide.com)
(TXT) w3m dump (voltagedivide.com)
| harwoodr wrote:
| My favourite example of this type of thing isn't mentioned in the
| article - using evolutionary computing to do some of the things
| mentioned in said article:
|
| https://www.researchgate.net/publication/2737441_An_Evolved_...
| jakeogh wrote:
| more: On the Origin of Circuits (2007):
| https://news.ycombinator.com/item?id=9885558
| IncreasePosts wrote:
| I read that paper about 20 years ago - at the time I was very
| interested in ML, and was torn between neural networks and
| evolutionary algorithms. This paper caused me to go all in on
| evolutionary algorithms, and eventually burn out because I
| could never get any kind of promising result out of it. Wrong
| choice I guess!
| bongodongobob wrote:
| Yeah, I tried my hand at some evolutionary algorithms and
| found it's all about the fitness function. I'd spend hours
| and hours refining it and eventually realized that you're
| really just optimizing the function to fit what you want to
| see. Kinda took the magic out of it for me.
| harwoodr wrote:
| Further on this - there's a more modern project that is trying
| to get the original experiments working on iCE40 FPGAs now:
|
| https://evolvablehardware.org/
| ShadowBlades512 wrote:
| Author here, thanks for reading, I just scaled the VPS to
| hopefully handle the traffic better, hahaha
| navaati wrote:
| Well joke's on you: your website worked fine for me, however HN
| itself was down after reading your article :p.
|
| Good job !
| konstantinua00 wrote:
| I sometimes wonder if something as changeable as fpga can be made
| for asynchronous circuits...
| morphle wrote:
| Yes, quite easily, we made a few different versions. There are
| much more benefits than just runtime programmable asynchronous
| circuits.
| jonathrg wrote:
| > A ring oscillator in an FPGA can be used as a strain gauge. If
| you implement a ring oscillator on an FPGA and then bend the
| FPGA, the frequency of the ring oscillator will shift.
|
| That's horrifying. I love it.
| function_seven wrote:
| Just when you think you've found all the possible side channel
| attacks, along comes a new one: The mole can Morse-Code-tap
| their secret messages on your Cisco edge router and abscond
| with your secrets.
| duskwuff wrote:
| Eagerly awaiting Mordechai's paper on this one.
| 4gotunameagain wrote:
| The same thing happens with PIC microcontrollers:
|
| https://www.youtube.com/watch?v=UCXCLR3xq8U
| AlotOfReading wrote:
| A game controller I worked on was accidentally sensitive to
| physical strain.
|
| We discovered this after the first prototypes/consoles were
| sent to early reviewers. They kept seeing weird in-game
| behavior no one could replicate, even when affected reviewers
| tried to demonstrate. Turns out they were gripping hard enough
| to minutely bend the PCB during intense moments in games, which
| created voltage spikes the software mistook for button presses.
| You needed to be angry to replicate.
| HowardStark wrote:
| Stories like these are my catnip. The 500 mile email is
| another great one.
|
| How did you end up debugging/reproducing? I conjured a
| picture in my head of an engineer comically exasperated and
| squeezing the controller followed by an "Aha!"
| AlotOfReading wrote:
| There was bare PCB prototype running on my desk that was in
| the way. I started cleaning my desk to work on something
| less frustrating and it got knocked off by accident. The
| logger went haywire immediately. That was the hint I
| needed.
| RGamma wrote:
| Accident-driven development.
| ShadowBlades512 wrote:
| This is definitely one of the reasons I wrote this article.
| To be able to see the cause/effect when a problem is very
| convoluted is something difficult to learn and difficult to
| teach. You just have to consume a lot of second hand stories
| and experience a few yourself.
|
| A story I have heard several times in different instances is
| some light sensitivity, I think this happened to the
| Raspberry Pi team (PMIC transient induced by camera flash).
| bayindirh wrote:
| I think one of the Raspberry Pis were resetting on flash
| because of an exposed/uncapped chip.
|
| Yes. It's the Raspberry Pi 2:
| https://hackaday.com/2015/02/08/photonic-reset-of-the-
| raspbe...
| gorkish wrote:
| 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 wrote:
| > 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 wrote:
| I 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).
| timeinput wrote:
| Are you saying that FPGAs increase the production cost of low
| rate (<1000 units) hardware? Compared to ASIC fabrication?
| gabrielhidasy wrote:
| Probably compared to micro controllers that are getting fast
| enough to do a lot of what used to take custom hardware or
| FPGAs
| vardump wrote:
| For 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 wrote:
| > Can't do same with ASICs.
|
| You can make latches with ASIC perfectly well. Or even more
| complex memory elements.
| polishdude20 wrote:
| One 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.
| Brian_K_White wrote:
| I think you meant more affordable or less expensive? Or even
| viable/possible at all.
| 15155 wrote:
| On 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.
| pama wrote:
| One of my favorite FPGA gadgets is the mojo 2 headphone amplifier
| by Chord electronics. The amplifier is nearly flawless. Coming
| from the old days of tube amplifiers and amazing analogue devices
| it is nice to see how far the digital circuitry has gone with
| analog applications.
| cadr wrote:
| Wow, just looked that up. That's a chunk of change for a
| headphone amplifier.
| jsheard wrote:
| https://www.audiosciencereview.com/forum/index.php?threads/c...
|
| It's not bad, but it's not the best, and pretty much everything
| that measures better is using a more conventional architecture
| and in many cases is significantly cheaper. Chords use of FPGAs
| gets points for novelty but I don't think it has any practical
| merit.
|
| https://www.audiosciencereview.com/forum/index.php?threads/c...
|
| Even their $14,000 monster desktop DAC/Amp gets beaten by units
| a fraction of the price in objective measurements. The
| audiophile market has taken a fascinating turn since ASR
| arrived on the scene, the snake oil salesmen are still on their
| bullshit but there has been an uptick in companies doing
| legitimately good engineering and making products with
| phenomenal performance for dirt cheap. There are DAC/Amp combos
| under $200 which are objectively perfectly transparent well
| beyond the theoretical limits of lossless CD audio now.
| atoav wrote:
| As a musician I absolutely love my "so small/light forgot I
| had it in my backpack"-500W Bass amp, compared to a 36 kg
| tube one. Class D is the shit.
| bongodongobob wrote:
| Fellow bass player here, I concur. Get a transparent class
| D and pair with a tube preamp of your choice. I love my
| Ampeg, but it lives in the basement now and doesn't leave.
| tombert wrote:
| I started playing with Clash recently, which is basically a
| Haskell-to-FPGA compiler.
|
| It's very cool and I'm slowly making progress, but man it feels
| like I'm learning to program all over again. I didn't take any
| electronics or computer engineering courses in college (focused a
| lot more on the discrete-math section of computer science), and
| the closest I've ever been to this is GPIO programming on an
| Arduino.
|
| It's really rewarding though, and it's clear that it's a skill
| that might come in handy some day in the future. I can think of a
| few cases where I'd benefit from dedicated hardware for some
| stuff.
| zachbee wrote:
| I've actually been working on a personal project using
| asynchronous ring oscillators on FPGAs to perform meaningful
| computation. If you make the oscillators interact in the right
| way, you can leverage them to solve certain graph problems!
|
| Once I finish the write-up I'm planning on posting it on HN :)
|
| https://github.com/zbelateche/digial-ising
| fpgamlirfanboy wrote:
| I promise I'm not trying to rain on your parade, and I blame
| the academics for this, but:
|
| 1. NP-complete problems are (today) global search problems
| (3-SAT algos _search_ for a satisfying assignment...);
|
| 2. Combinatorial search spaces are not only non-convex, they
| don't have gradients (sub-gradients don't count) and even if
| they did, without convexity, it's still hopeless.
|
| Thus, you cannot (today) appreciably parallelize NP-complete
| algos, _you can only draw more lottery tickets_ (for where to
| seed your search), i.e., constant factor improvement.
|
| I'm just putting this out there in case someone gets tantalized
| by the "fancy math/physics/fpga thing solves NP-complete
| problems" hook. Yes it can but no better than your computer
| (despite what paper authors claim in order to get published).
| To wit: if this were a compelling solution to NP-complete
| problems it would either a) already be a proof that NP=P or b)
| be implemented in absolutely every single SAT solver (using GPU
| or whatever rather than FPGA). In contrast, every single SAT
| solver uses CDCL which is ~roughly DFS with clever
| backtracking.
|
| And I say this as someone that has investigated solving ILPs on
| FPGA - i.e., I wish it were true but it ain't.
| zachbee wrote:
| This is a personal project aiming to replicate analog
| coupling dynamics with asynchronous digital circuits FPGAs,
| not a claim that we can solve NP complete problems with a
| fundamental speedup.
|
| Also, these sorts of Ising architectures get their speed-up
| are based on oscillator interaction, not parallelism. It's
| relevant to this article because it leverages oscillators on
| FPGAs in a nifty way :)
| fpgamlirfanboy wrote:
| > This is a personal project aiming to replicate analog
| coupling dynamics with asynchronous digital circuits FPGAs,
| not a claim that we can solve NP complete problems with a
| fundamental speedup.
|
| Then you shouldn't have led with that? It's like academic
| clickbait to say "here's this thing I'm working on, it uses
| XYZ technique to solve REALLY HARD PROBLEM" but omit the
| "...very poorly" part. Like I said I don't entirely blame
| you, I blame the academics that have an entire cottage
| industry and culture around these kinds of "results".
|
| > These sorts of Ising architectures get their speed-up are
| based on oscillator interaction, not parallelism.
|
| Not sure what you're trying to say - it's quantum annealing
| "brought to life" using simple 2-state (up/down)
| particles/phonos/whatever you want to call them. The
| quantum in quantum annealing means superposition ie
| parallelism; your implementation is basically a D-Wave
| machine without the qubits.
| zachbee wrote:
| I dunno man, I think saying "this is a personal project
| of mine" and linking to an open source github repo
| implies that it's a casual side project. I never made any
| performance claims, it's just for fun. I'm not trying to
| put up clickbait.
|
| And yeah, I think the fact that you can build a
| classical, analog, D-Wave-sans-qubits machine on an FPGA
| is cool!
| pclmulqdq wrote:
| The digital ising thing was a very interesting line of research
| that Fujitsu has been trying to sell for 10 years or so:
| https://www.fujitsu.com/global/services/business-services/di...
|
| They presented their v1 chip architecture at ISSCC in 2015 much
| to the consternation of a few quantum computing people who
| (rightly) objected to the characterization of it as an "Ising"
| chip, because it cannot represent superposition.
|
| It's a pretty cool sort of system that should be able to solve
| pseudo-energy-minimization problems, but they are only
| theoretically sound when energy minimization corresponds to
| minimizing a Lyapunov function. Sadly, it's not clear that
| there is a way to generically construct a Lyapunov function
| with a minimum that corresponds to an NP-complete problem. The
| Fujitsu device supposedly is good at "easy" versions of
| problems, but so is a SAT solver.
| zachbee wrote:
| The Fujitsu device is a synchronous digital architecture. I'm
| using asynchronous oscillators, more like Lo et. al.
| (https://www.nature.com/articles/s41593-024-01607-5)
|
| I personally think it's super cool that we can replicate
| analog coupling dynamics using asynchronous digital logic!
| pclmulqdq wrote:
| I hate to burst your bubble, but when you do the dynamic
| systems math, they are sadly equivalent. You are working in
| the continuous time domain while the synchronous devices
| are working in the discrete time domain.
| zachbee wrote:
| In practice, though, asynchronous systems can run a lot
| faster than their synchronous counterparts! Also, I'm
| mostly working on this project because it's cool and
| interesting to build oscillator-based computing systems
| on FPGAs, not because I'm trying to build a practical
| system.
|
| That's why I posted it here: it's a fun use-case for
| asynchronous stuff you can do on FPGAs.
| pclmulqdq wrote:
| The strain gauge is an interesting one that I hadn't seen before,
| and theoretically should work. Very creative!
|
| A few more fun things you can do with FPGA fabric:
|
| * A temperature sensor - timing some ring oscillators against a
| reference clock generated off-chip can give you a measure of the
| temperature of the chip because transistor speed is temperature
| dependent.
|
| * ADC/power supply monitor - Launching a signal down a TDC at a
| known interval gives you a time measurement that correlates with
| power supply voltage. Also, ring oscillator speed correlates with
| power supply voltage. This is also a possible attack vector for
| side-channel attacks on multi-tenant FPGAs and multi-tenant
| systems that involve programmable FPGAs.
|
| * An oven/thermostat - Switching transistors on and off creates
| heat by burning power. This can be hooked up to a temperature
| sensor (either a synthetic one in FPGA fabric or the one in the
| device ADC/system monitor) with a PID loop to create a
| temperature control system. This is actually kind of useful if
| you want to do analog stuff with reasonable stability.
|
| Also, if the author is here, I would appreciate a link to
| https://arbitrand.com in the "TRNG" section.
| DontchaKnowit wrote:
| That bit about stabilizing the tempture was suoer interesting I
| could see that being useful for like a synthesizer or
| something.
| pclmulqdq wrote:
| It's not uncommon in sensitive analog systems to do something
| like this, ~but I haven't seen anyone doing it with an FPGA
| yet~. Very old analog systems (that were a lot more
| temperature-dependent than modern analog circuits) often were
| contained in small ovens, and an intermediate step between a
| normal oscillator and an atomic clock today is to use an
| oven-controlled oscillator. In both cases, they keep the
| ambient temperature on the analog devices at 40-50 C to make
| sure that they operate at a stable temperature regardless of
| ambient temperature.
|
| Edit: See the sibling comment - someone has found a
| reasonable circumstance to do it!
| ShadowBlades512 wrote:
| I forgot about self-heating FPGAs! I am definitely going to add
| that to the article at some point. This is a paper I read on
| this a few years ago.
| https://ieeexplore.ieee.org/document/6818753
| logtempo wrote:
| Kind of related to this post:
| https://news.ycombinator.com/item?id=39735665
|
| > The solution to these problems came from Khuri-Yakub's lab at
| Stanford University. In experiments in the early 2000s, the
| researchers found that increasing the voltage on CMUT-like
| structures caused the electrostatic forces to overcome the
| restoring forces of the membrane. As a result, the center of the
| membrane collapses onto the substrate. A collapsed membrane
| seemed disastrous at first but turned out to be a way of making
| CMUTs both more efficient and more tunable to different
| frequencies[...]
___________________________________________________________________
(page generated 2024-03-19 23:00 UTC)