Digital logic design isn't software programming, and today's FPGAs are for most intents and purposes 'single-configuration-at-a-time' devices - you can't realistically time-slice them.
The placement and routing flow of these devices is an NP-Complete problem and is relatively non-deterministic* (the exact same HDL will typically produce identical results, but even slightly different HDL can produce radically different results.)
All of these use cases you've mentioned (AV1 decoders, NN layers, but especially a JS runtime) require phenomenal amounts of physical die area, even on modern processes. CPUs will run circles around the practical die area you can afford to spare - at massively higher clock speeds - for all but the most niche of problems.
Gowin and Efinix's tools are extremely spartan compared to Vivado or Quartus: they're pretty much straight HDL to bitstream compilers. There's also a FOSS implementation flow available for the Gowin chips (but I haven't used it.)
HDL isn't getting any easier, though, and that's where most of the complexity is.
Often, the same people crying about Flock will decry private arms ownership through mental gymnastics.
These very same ships you speak of that could do "tons of damage" had actual cannonry - with no registration or restrictions on ownership or purchase, either.
You can still buy and bear a cannon with no background check or registration or any of the like, FWIW. Very easy to order on the internet and have shipped straight to your door[].
You can, but be aware that an exploding cannonball (widely available in 1776) is considered a destructive device, so each shell must have an NFA stamp. Solid shot is not considered a destructive device.
Why do they need consent in a public place? Children vandalize, steal, etc. as well - should they just be immune from detection because they are below some arbitrary age?
Do banks just shut off all surveillance when a child walks past their front door?
> and quite a bit worse than just dealing with an MCU.
Unless you're using some kind of USB DFU mode (which is annoying on assembly lines), SWD-based flashing of an MCU is substantially more complicated than the JTAG sequences that some internal-flash FPGAs use for programming..
These chips are just as easy or easier to program than any ARM MCU. Raw SPI NOR flash isn't "easy" to program if you've never done it before, either.
Oh look, the factory screwed up and isn't flashing the MCU this week! Does the board survive?
Oh look, the factory screwed up and isn't flashing the PLD this week! Does the board survive?
Oh look, the factory... wait, what is the factory doing and why are they putting that sticker on that....
You get the idea. Yes, yes, it is all solvable. I have never claimed it isn't. I am just claiming it is a giant pain in the ass and limits use of these things. I will bend over backwards to keep boards at one binary that needs to be loaded.
Embed the bitstream into your MCU firmware binary, bitbang the 50-100KB bitstream into SRAM via JTAG from your MCU in all of 10ms. This is <100 lines of Rust.
Yes, it's solvable. But my whole argument is that the entire experience is death by a thousand cuts. I'm not seeing how "it's possible in 100 lines of Rust" (a language most people don't even use for embedded work) is really countering my argument.
I honestly start to wonder how in the world we survived flashing 3 different binaries, for years (bitstream, 2 MCUs), without ever getting a complaint from the production floor.
I mean, yeah. My argument isn't that anything is impossible. My argument is that all of this is harder than it needs to be and this is not countering me!
This is your job, and it really shouldn't feel difficult. This is really not tedious: the minimum board design for these chips literally consists of just power, JTAG pins, and a clock (if the internal oscillator isn't good enough.)
The Gowin FPGAs are available (at a massive premium) from Mouser, just like whatever MCU you are already using. Many are available for <$1-2 in China. Efinix are available from DigiKey, with some SKUs under <$10.
All of the Gowin documentation is available on their site with a free, approval-less email login and no NDA, or via Google directly (PDFs, just like Xilinx, even numbered similarly.)
> All of the Gowin documentation is available on their site with a free, approval-less email login
The problem is trust. I'm hesitant to hand out my e-mail anywhere because far too often I have been hounded by salespeople as a result, not to mention data breaches or bombardment of newsletters.
The placement and routing flow of these devices is an NP-Complete problem and is relatively non-deterministic* (the exact same HDL will typically produce identical results, but even slightly different HDL can produce radically different results.)
All of these use cases you've mentioned (AV1 decoders, NN layers, but especially a JS runtime) require phenomenal amounts of physical die area, even on modern processes. CPUs will run circles around the practical die area you can afford to spare - at massively higher clock speeds - for all but the most niche of problems.
reply