5 ms·

Maybe you are not the target audience? I found it a decently informative read myself. Why is it necessary to understand how verilog is exactly transformed into

Maybe you are not the target audience? I found it a decently informative read myself. Why is it necessary to understand how verilog is exactly transformed into gates? Sounds like gatekeeping to me, but please enlighten me. I have in the past written hdl and I didn’t even have a FPGA

d_tr 3y ago
While it is not strictly necessary in all scenarios, I think you will just not be able to get efficient circuits if you do not have a sense of what type of logic your verilog code snippets map to. I honestly believe that if you do not understand at least some basics, things will be way more painful and opaque than necessary, so it is a no-brainer IMO. You also do not need to have an FPGA to learn this stuff.
codedokode 3y ago
Because Verilog is not C where typically a line of code turns into several machine code commands. And even if you write inefficient code, CPUs are so fast that you won't notice it. In Verilog a simple "+" or "*" can turn into thousands of gates. Without understanding this your designs will be inefficient and slow. Unlike CPU cycles, silicon and transistors are not free. Also for a design to be fast you need to use pipelining and to slice your combinational logic into thin layers. Again, you won't be able to do it without understanding how your code translates to gates.
- minipci1321 3y ago
  > And even if you write inefficient code, CPUs are so fast that you won't notice it. I think you are arguing for the right cause but with wrong arguments. In C language, not understanding in details what exactly the code does, can be just as disastrous as in Verilog. Internet examples abound.
- RetroTechie 3y ago
  > 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.
  - alain94040 3y ago
    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.
    - imtringued 3y ago
      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.

d_tr 3y ago

While it is not strictly necessary in all scenarios, I think you will just not be able to get efficient circuits if you do not have a sense of what type of logic your verilog code snippets map to. I honestly believe that if you do not understand at least some basics, things will be way more painful and opaque than necessary, so it is a no-brainer IMO. You also do not need to have an FPGA to learn this stuff.

codedokode 3y ago

Because Verilog is not C where typically a line of code turns into several machine code commands. And even if you write inefficient code, CPUs are so fast that you won't notice it. In Verilog a simple "+" or "*" can turn into thousands of gates. Without understanding this your designs will be inefficient and slow. Unlike CPU cycles, silicon and transistors are not free. Also for a design to be fast you need to use pipelining and to slice your combinational logic into thin layers. Again, you won't be able to do it without understanding how your code translates to gates.

minipci1321 3y ago
> And even if you write inefficient code, CPUs are so fast that you won't notice it. I think you are arguing for the right cause but with wrong arguments. In C language, not understanding in details what exactly the code does, can be just as disastrous as in Verilog. Internet examples abound.
RetroTechie 3y ago
> 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.
- alain94040 3y ago
  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.
  - imtringued 3y ago
    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.