> In Verilog a simple "+" or "*" can turn into thousands of gates. Without understanding this your designs will be inefficient and slow.
Trying hard to avoid this because it is inefficient, is (imho) a typical case of premature optimization. Who cares whether you're wasting CPU cycles (in C) or FPGA logic (Verilog & co) when you're just learning what's what?
But there's a better reason: to make sure that whoever is learning Verilog (or other HDL) actually understands what they are trying to do.
With that understanding in place, the learning becomes "what logic construct(s) would be suitable" followed by "what Verilog to write that describes that logic".
Versus: "Verilog intro course has this example, does it compile? And does it appear to do what I think the Verilog says it should do?".
In programmer's parlance: semantics vs. syntax. The algorithm + how it maps to a CPU's resources, vs. red tape required to implement it.
If you 'feel' the syntax but underlying semantics is black magic, then you could keep stumbling in the dark forever. Spitting out copypasta along the way.
But if you understand basic concepts of the underlying hw (and how you intend to use that), learning syntax to describe that is straightforward.
It goes beyond being inefficient. It's the wrong mental model.
Chip designers intuitively visualize interconnected blocks of logic. They draw rectangles with wires between them.
To learn this intuition, writing spaghetti Verilog code that runs in a simulator is counter-productive. It's a common mistake that people coming from a software background make all the time, and that has been discussed to death. So with some appeal to authority, trust us and learn proper hardware design, hopefully it will be more rewarding and will "click" faster.
I don't understand where this sentiment is coming from. I have seen so many logs on HN that tryo to explain the "gotcha" difference between hardware and software and I don't understand who they are targeting. For me it is obvious that VHDL maps to hardware. When I got to actually writing VHDL I was like "where is the gotcha? These people lied to me. Hardware works exactly like hardware!".
It feels condescending to read on the internet how hardware engineers clain that software engineers don't know how hardware works. Any kid that has played around with Redstone intuitively knows the difference and in fact children are more likely to have extensive experience with hardware than with software because most games have some sort of logic gate system but only a tiny minority lets you program unless the entire game is based around programming.
Trying hard to avoid this because it is inefficient, is (imho) a typical case of premature optimization. Who cares whether you're wasting CPU cycles (in C) or FPGA logic (Verilog & co) when you're just learning what's what?
But there's a better reason: to make sure that whoever is learning Verilog (or other HDL) actually understands what they are trying to do.
With that understanding in place, the learning becomes "what logic construct(s) would be suitable" followed by "what Verilog to write that describes that logic".
Versus: "Verilog intro course has this example, does it compile? And does it appear to do what I think the Verilog says it should do?".
In programmer's parlance: semantics vs. syntax. The algorithm + how it maps to a CPU's resources, vs. red tape required to implement it.
If you 'feel' the syntax but underlying semantics is black magic, then you could keep stumbling in the dark forever. Spitting out copypasta along the way.
But if you understand basic concepts of the underlying hw (and how you intend to use that), learning syntax to describe that is straightforward.