Posted by thawawaycold 12/19/2025
I disagree with "HDL is software" though. It's not, it's even in the name: "hardware description language". Yes it's a text file with what looks a lot like regular code in it. However what's being decribed is how to connect boxes of logic together, and how to compute the output of the boxes from their inputs. There's no implicit program counter that's advancing from one line to the next.
It is (theoretically) possible to write these kind of things with a lot of abstraction, but every time you try that by using more advanced language features, you hit some bugs in the tool's implementation of the language. If you're lucky it'll tell you where you're doing undupported stuff. Often it'll crash. Sometimes it'll sythesize hardware that doesn't conform with the language spec.
Finally, FPGAs are simple only when you're looking at a bird's eye view (just like CPUs are simple when you're looking at a diagram with a few boxes saying "ALU", "Cache", "Registers"). The actual datasheets are thousands of pages long.
FPGAs are still useful though, their use case is "I need custom hardware and I don't have the volume to build an ASIC". For example, my application is a custom signal processing pipeline that's handling about 3.5 Gbit/s of streaming raw data. On a $40 chip.
I think my main point is that yes, the tooling is a pain to use, with heaps of bugs and bad language support. However a HDL is conceptually different from a software language and I'm not sure you can hide away the complexities of designing hardware behind "modern" language features.
For those suggesting diagram-based languages, go program something in LabView, you'll quickly understand why that's a bad idea (works for trivial designs, anything complex is an opaque mess of boxes and lines, unsearchable, and impossible to integrate with version control).
You can write very neat and tidy code with dataflow diagram languages. I did it professionally for years, and there were many others who did as well.
Same thing as any other language, you have to come up ways to organize the code into functions and classes that make sense. Vomiting everything into the top level diagram is the same as 10000 line of code while(1)
You could always tell the exact level of proficiency someone had with LabVIEW immediately when opening the diagram.
The dataflow model maps very well to FPGAs IMO, it's a shame it never became widespread. There was much potential there
Yes, that's certainly a big misconception. Maybe not the one the author meant to call out, but... yes, a big misconception indeed.
No mention of that Brazilian company that was set to manufacture them to undercut the market?
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.
If you have an application that can be done on a CPU, with lots of sequences dependencies (such as video compression/decompression), an FPGA doesn’t stand a chance compared to adding dedicated silicon area.
That’s even more so if you’d embed an FPGA on a CPU die. Intel tried it and you got a power hungry jack of all trades, master of none that nobody knew what to do with.
Xilinx MPSOC and RFSOC are successful, but their CPUs are comparatively lower performance and used as application specific orchestrators and never as a generic CPU that run traditional desktop or server software.
FPGAs have hard wired blocks like DSPs which do not have any power disadvantages vs "ASIC" (only advantages actually)
the likelihood that there is an ASIC that happens to implement your particular design is very low
and off the shelf ASICs like GPUs and CPUs have significant amounts of overhead for each operation. This is especially evident with CPUs. They perform a small number of operations per cycle, but they have to pay the entire fixed energy cost of caches, registers, instruction decoding, etc per cycle. This is way way worse than programmable logic if you're mostly using the DSP and the block RAM slices.