10 ms·

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 ce

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.

arcticbull 8y ago
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?
- vvanders 8y ago
  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.
  - arcticbull 8y ago
    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.
sannee 8y ago
> 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.
- sanxiyn 8y ago
  Try Chisel. Chisel solves this.
- orbifold 8y ago
  System verilog interfaces solve this. A lot of the publicly available code is just riddled with bad practices, just like it is the case with C.
- vvanders 8y ago
  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.

arcticbull 8y ago

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?

vvanders 8y ago
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.
- arcticbull 8y ago
  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.

sannee 8y ago

> 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.

sanxiyn 8y ago
Try Chisel. Chisel solves this.
orbifold 8y ago
System verilog interfaces solve this. A lot of the publicly available code is just riddled with bad practices, just like it is the case with C.
vvanders 8y ago
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.