Yeah I'm not 100% sure what the difference is, I'd love an elaboration. The languages you program FPGAs in typically are in the class of hardware description languages (HDLs) - and IMO description and definition are interchangeable in this context.
Yeah, it's subtle but let me see if I can tease it out.
When you're talking about software you're talking about issuing a series of commands that execute in certain ways that produce a desired result. While you may have threading to give the appearance of concurrency(or actual discrete cores/etc) it's still largely a serial operation(with pipelining under the hood but largely not exposed at a software level).
In contrast FPGAs, CPLDs and the like use as you said Hardware Description Languages. These languages are not about issuing a series of actions but instead describing a blueprint for construction of physical hardware units(via SRAM LUTs, ASIC lithography or the like). Many things that are common and expected as a part of software(looping, blocking, etc) are either anti-patterns to not available at all.
Asking someone who's familiar with software to write HDL is like asking a Civil Engineer to do the job of a Mechanical Engineer in designing the drivetrain of a car. Both are professional engineers but they have vastly different skills.
I've spent a fair time in both worlds(although more on the software side) and learning FPGAs was like hitting a brick wall for ~3 months until you realize you have to unlearn all you know about software and build up an understanding from the hardware side first. It's also probably why firmware engineers tend to write so much copy/paste code and software engineers tend to write code that uses an order of magnitude more resources than they actually need.
> It's also probably why firmware engineers tend to write so much copy/paste code
This always seemed like limitations of the commonly used HDLs. Both Verilog and VHDL are extremely verbose and do not really allow a lot of abstraction. Even stuff like "I want this module to have a $common_interface" is hard to impossible without just copy pasting the definitions (sure, there are C macros) every time.
Oh yeah totally, I think it's also a byproduct of how they synthesize. Extra abstractions in software have relatively low cost where they can be really expensive in HW.
The difference you describe imo is between descriptive and imperative programming languages though (Prolog comes close for the desktop world) and that one usually targets wires and one targets assembly is irrelevant as you can use either for either purpose. Your reply covers which is used most commonly for which purpose. Where does System C fit in this model out of curiosity?
Nah, it's deeper than that. Assembly is still just a series of commands with desired effects. HDLs are a description of physical hardware(minus IP blocks which are vendor specific). You're describing things down to the actual gate level.
Stuff like sync vs async latches, global resets, exact cycle count are things that are critical in HDLs but don't have matter much in software these days.
For SystemC I'm not a huge fan, the types if things you want to describe tend to get bolted on and many constructs just aren't synthesizeable. There's a huge impedence match between the two.
The same is true of languages like Prolog on the desktop. You don't express how you want the software to work (imperative) but rather what you want it to do (declarative). Just because one synthesizes hardware and one assembly instructions isn't particularly significant, software is software! :) It's just that historically declarative languages have mapped more naturally onto FPGAs.
I definitely agree with you there's more to consider when writing for an FPGA but not much more so than let's say writing for a microcontroller where cycles (at least timing) matters. Or anything hard real-time for that matter.
HDLs are not software. There is no generated instruction sequence. The end result can just as readily be an ASIC which is most definitely not "software defined".
There absolutely can be a generated instruction sequence, that just depends on the compiler. That's what GHDL does if I'm not mistaken. In fact, "by using a code generator (llvm, GCC or a builtin one), GHDL is much faster than any interpreted simulator." [1]
Theoretically I could write any web service in a synthesizable subset of VHDL. Similarly, you could, in theory, compile down any C program into an FPGA bitstream, as both HDLs and C are Turing complete. It may not function efficiently as the right considerations probably haven't been made in your C code to make it easy to do well. I could even turn my C program into an ASIC but that's not the point. The fact that FPGAs are reprogrammable and their functionality is defined in code means they are as much software defined as as any microcontroller. That definition IMO doesn't stretch to ASICs as they are not reprogrammable, and the resulting HDL goes through a huge pipeline of vendor-specific tools to turn the result into silicon.
This is my opinion of course, and I would argue that an FPGA bitstream is equivalent to a ROM for a microcontroller - software that defines the digital electrical characteristics in response to stimuli. Seems that if the latter is defined by software so is the former.
