> While this may look like code in a normal programming language, it operates entirely differently. So happy to see this called out up-front. One of the hardest things with FPGAs as a developer is understanding that you're reconfiguring hardware instead of a series of serial asm/opcodes. They look superficially the same but have very different requirements and constraints under the hood.
> under the hood Surely, we don't have to work with raw quantum electrodynamics when designing an FPGA, even though that's what's going on "under the hood". Thinking that way, gets me wondering about different layers of abstraction along with the benefits and drawbacks of each. With FPGA programming, what levels of abstraction are available and what simplifying assumptions does each model make? I've got in mind thing…
Probably. But that doesn't mean you might not see the effects of it. I can't find the story/paper at the moment due to too much noise in my searches, but a team of researchers gave some kind of machine learning process (I think genetic programming) an FPGA to treat as a black box to solve some problem. It ended up making a program for the FPGA that didn't work on any other FPGA, and had what should be useless elements in the program that didn't connect anywhere, but without which the whole system wouldn't work properly. So at the least they had some kind of weird effect going on that wouldn't be explained by normal analysis.
edit: Found it: https://www.damninteresting.com/on-the-origin-of-circuits/