3 ms·

The key to learning HDL is to understand that it isn't software. There are no instructions to a state machine. You are describing the functionality of the state

The key to learning HDL is to understand that it isn't software. There are no instructions to a state machine. You are describing the functionality of the state machine itself.

aseipp 10y ago
Not to sound rude, but what are you addressing with this statement? I've been doing functional programming for over a decade; I'm quite familiar with the concept of declarative programming, so circuits were not a big leap from this point (one of the many ways in which FP nicely dovetails with hardware design.) My point wasn't really about state machines or whatever. Languages like Verilog and VHDL are absolutely terrible at things like abstraction capabilities. You don't have modules, you don't have a REPL, you don't have any kind of abstraction facilities almost at all, on top of the languages being ridiculously verbose. They sit in some bizarre uncanny valley where anything takes a surprising amount of code to write, yet is terrible in terms of reuse, modularity, understandability, etc. Example: A few weeks ago I ran into a case where I couldn't easily wrap a cell library primitive by wrapping it in a Verilog module, and then re-use that module a few times. The primitive was a PLL on my board. Oops, can't do that -- because the synthesis toolchain disliked a module around the PLL primitive, as the primitive had some arguments which were required to be constants (despite the fact all call sites to the wrapping module had constant arguments). So I had to use a Verilog macro which generated a Verilog module, and I had to instantiate that macro like 10 times to 10 different modules, each one corresponding to a different clock speed, with no reuse outside of a Macro. Because some parameters had to be constant. If Verilog metaprogramming wasn't just a rip off of C macros, it might not be so terrible. But shit like this is just tedious. I can't even do things like use higher order functions, or strong typing capabilities, or things like leverage a real module system (with boundary and abstraction capabilities) -- even when I am completely in control of their use and completely understand how they will synthesize. Tools like REPLs vastly improve time-to-iterate with an interactive environment. Cosimulation being a primary feature of these tools means I generally get fairly accurate software simulations directly from my HDL itself, independent of any EDA toolchain etc. The languages are just bad languages. Can you get work done in them? Yes, and everybody does. Do they accurately reflect the fact you're declaratively describing a hardware circuit? Yes. That doesn't mean Verilog/VHDL, as languages, aren't objectively terrible. I understand why this is. The cost models associated with these tools -- and process -- are fundamentally different (for hardware, it's not about "determinism" like software programmers care about -- but things like MTTF, lead time, and optimizing around that), and Verilog is really a small portion of the overall lifecycle of developing a chip (you still need post-synth testing, possibly do gate-level debugging, post-synth modifications, on-board testing, etc). And tools like Clash/Chisel are not perfect by any means, and I still have plenty of slack to pick up by myself, nonetheless. The languages are still bad, despite all that.
- blackguardx 10y ago
  I think we are approaching this from opposite perspectives. I've been doing FPGA development for 10 years and am an EE. C was the first programming language that I learned over 20 years ago as a teenager. I've only very recently been learning high-level languages and associated abstractions. A lot of the trouble with FPGA development in my opinion isn't the HDL, but the toolchains themselves. I haven't met anyone that likes FPGA toolchains. Things like PLL instantiation problems are likely to do with the tool and not the language. A lot of people (I'm not saying this is you) coming from a software background tend to approach FPGAs as if it were a software problem. They seem very similar, after all. You write some code into a window, hit a button, and bam, you have some functionality. To some extent, I think it leads them to tend to shove a square peg in a round hole. Just like there are programming paradigms governing software design, there paradigms governing FPGA design as well. Trying to force certain abstractions can lead to headache. Abstractions are very important in any design process, be it analog hardware, digital hardware, software, bridge design, etc. Software tends to favor abstractions because they are powerful, but also very cheap. One can afford to waste some CPU cycles if it reduces development time and the occurrence of bugs. In FPGA and ASIC design, abstractions are just as important but one can't afford to waste clock speed or chip area to get it. FPGAs are expensive and ASICs even more so. The design paradigms of HDL exist for that reason, as frustrating as they may be. In a sense, I've just grown accustomed to Verilog's warts. I was appalled at the FPGA development process when I first started but at this point I just take it for granted. I think thing will get better but it will take time. Even so, I think that it is best to stick with Verilog/VHDL for the time being. Just like if one wanted to web development, one would have to learn javascript, which is also considered terrible.
  - ZenoArrow 10y ago
    > "Even so, I think that it is best to stick with Verilog/VHDL for the time being." If you do it for your job, perhaps. However, if you're a hobbyist, that doesn't make as much sense. As a hobbyist you have the luxury of being able to use the tools you like the best. In any case, FPGA design shouldn't be closely coupled to any one language, they're just a tool that allows you to express the design you have in mind. If Clash or Chisel can help you express that design more succinctly and clearly than the competition, there's no need to stick to the other tools. The need only exists for professionals, as changing to languages with lower market share carries risk.

The key to learning HDL is to understand that it isn't software. There are no instructions to a state machine. You are describing the functionality of the state machine itself.

aseipp 10y ago

Not to sound rude, but what are you addressing with this statement? I've been doing functional programming for over a decade; I'm quite familiar with the concept of declarative programming, so circuits were not a big leap from this point (one of the many ways in which FP nicely dovetails with hardware design.) My point wasn't really about state machines or whatever. Languages like Verilog and VHDL are absolutely terrible at things like abstraction capabilities. You don't have modules, you don't have a REPL, you don't have any kind of abstraction facilities almost at all, on top of the languages being ridiculously verbose. They sit in some bizarre uncanny valley where anything takes a surprising amount of code to write, yet is terrible in terms of reuse, modularity, understandability, etc. Example: A few weeks ago I ran into a case where I couldn't easily wrap a cell library primitive by wrapping it in a Verilog module, and then re-use that module a few times. The primitive was a PLL on my board. Oops, can't do that -- because the synthesis toolchain disliked a module around the PLL primitive, as the primitive had some arguments which were required to be constants (despite the fact all call sites to the wrapping module had constant arguments). So I had to use a Verilog macro which generated a Verilog module, and I had to instantiate that macro like 10 times to 10 different modules, each one corresponding to a different clock speed, with no reuse outside of a Macro. Because some parameters had to be constant. If Verilog metaprogramming wasn't just a rip off of C macros, it might not be so terrible. But shit like this is just tedious. I can't even do things like use higher order functions, or strong typing capabilities, or things like leverage a real module system (with boundary and abstraction capabilities) -- even when I am completely in control of their use and completely understand how they will synthesize. Tools like REPLs vastly improve time-to-iterate with an interactive environment. Cosimulation being a primary feature of these tools means I generally get fairly accurate software simulations directly from my HDL itself, independent of any EDA toolchain etc. The languages are just bad languages. Can you get work done in them? Yes, and everybody does. Do they accurately reflect the fact you're declaratively describing a hardware circuit? Yes. That doesn't mean Verilog/VHDL, as languages, aren't objectively terrible. I understand why this is. The cost models associated with these tools -- and process -- are fundamentally different (for hardware, it's not about "determinism" like software programmers care about -- but things like MTTF, lead time, and optimizing around that), and Verilog is really a small portion of the overall lifecycle of developing a chip (you still need post-synth testing, possibly do gate-level debugging, post-synth modifications, on-board testing, etc). And tools like Clash/Chisel are not perfect by any means, and I still have plenty of slack to pick up by myself, nonetheless. The languages are still bad, despite all that.

blackguardx 10y ago
I think we are approaching this from opposite perspectives. I've been doing FPGA development for 10 years and am an EE. C was the first programming language that I learned over 20 years ago as a teenager. I've only very recently been learning high-level languages and associated abstractions. A lot of the trouble with FPGA development in my opinion isn't the HDL, but the toolchains themselves. I haven't met anyone that likes FPGA toolchains. Things like PLL instantiation problems are likely to do with the tool and not the language. A lot of people (I'm not saying this is you) coming from a software background tend to approach FPGAs as if it were a software problem. They seem very similar, after all. You write some code into a window, hit a button, and bam, you have some functionality. To some extent, I think it leads them to tend to shove a square peg in a round hole. Just like there are programming paradigms governing software design, there paradigms governing FPGA design as well. Trying to force certain abstractions can lead to headache. Abstractions are very important in any design process, be it analog hardware, digital hardware, software, bridge design, etc. Software tends to favor abstractions because they are powerful, but also very cheap. One can afford to waste some CPU cycles if it reduces development time and the occurrence of bugs. In FPGA and ASIC design, abstractions are just as important but one can't afford to waste clock speed or chip area to get it. FPGAs are expensive and ASICs even more so. The design paradigms of HDL exist for that reason, as frustrating as they may be. In a sense, I've just grown accustomed to Verilog's warts. I was appalled at the FPGA development process when I first started but at this point I just take it for granted. I think thing will get better but it will take time. Even so, I think that it is best to stick with Verilog/VHDL for the time being. Just like if one wanted to web development, one would have to learn javascript, which is also considered terrible.
- ZenoArrow 10y ago
  > "Even so, I think that it is best to stick with Verilog/VHDL for the time being." If you do it for your job, perhaps. However, if you're a hobbyist, that doesn't make as much sense. As a hobbyist you have the luxury of being able to use the tools you like the best. In any case, FPGA design shouldn't be closely coupled to any one language, they're just a tool that allows you to express the design you have in mind. If Clash or Chisel can help you express that design more succinctly and clearly than the competition, there's no need to stick to the other tools. The need only exists for professionals, as changing to languages with lower market share carries risk.