"As for the HDL code itself, it can act as software (when it is run on an emulator or loaded into an FPGA) or as a hardware design (when it is realized in immut

"As for the HDL code itself, it can act as software (when it is run on an emulator or loaded into an FPGA) or as a hardware design (when it is realized in immutable silicon or a circuit board)." This statement comes with some pretty heavy caveats. You can't just compile any arbitrary piece of software to hardware. At least not directly...not without an implied runtime package to support your program on hardware. Software developers tend to take this stuff for granted, especially at the high level. If you're writing C, where is your stack living? Do you plan on using the heap? Those need to go down to hardware somewhere. This is the big trouble with FPGAs+Software Developers. Folks at the software level can (and probably tend to) fully utilize the Turing completeness (or anything power above regular language recognition at least) in their languages, inadvertently or not. When you want to support a computation that requires more power than finite automata can provide, you're going to need to bundle in things like memory management functionality, and maybe even a proto-processor. The rub is that you already have these things in literally any computer, and they're likely going to be faster than what you can do on an FPGA. For now anyway. FPGAs are a tough nut to crack from the bottom up and the top down. If they're going to turn into a massively disruptive technology, we're going to need better tools for them and maybe some different thinking about how we program for them.