5 ms·

Sadly the article explains nothing. For example, it doesn't explain how the Verilog (or VHDL) code will be implemented at gate level, is it expensive or not (in

Sadly the article explains nothing. For example, it doesn't explain how the Verilog (or VHDL) code will be implemented at gate level, is it expensive or not (in terms of gate count), how long the critical path will be, can we pipeline it, how to implement several writing ports etc. I think that one shouldn't write Verilog/VHDL code unless one clearly understands how it will be transformed into gates.

alain94040 3y ago
Correct. The code shown is only good enough for RTL simulation. It won't help actually generate a chip with multiple read and write ports to a register file.
- therealcamino 3y ago
  That code is synthesizeable and will work fine in an ASIC flow.
- tverbeure 3y ago
  On an FPGA, it will infer a dual-ported BRAM memory just fine. On ASIC, it will generate a flip-flop array, which is good enough for many CPUs. E.g. in this physical layout of a Swerv RISC-V CPU, the ARF section is the register file, built out of flip-flops: https://tomverbeure.github.io/2019/03/13/SweRV.html#swerv-physical-design https://tomverbeure.github.io/2019/03/13/SweRV.html#swerv-ph....
  - alain94040 3y ago
    Also, the read ports are asynchronous, which is bad: assign rv1 = registers[rs1]; assign rv2 = registers[rs2];
okl 3y ago
It's Verilog in this article.
monocasa 3y ago
You don't normally write register files in an HDL anyway (at least in the hard and soft flows I've dealt with). You don't want to build them out of regular logic so you end up wrapping some hard IP blocks. Block RAM on FPGAs, or the output of register file hard block generators on ASIC flows. The HDL just ends up being an interface boundary that gets swapped out for simulation.
- bpye 3y ago
  I think in an FPGA flow you could rely on inferring a block RAM no?
  - monocasa 3y ago
    I've found that the synthesizer can infer a lot of the time, but I wouldn't say you can rely on it.
  - d_tr 3y ago
    It can infer lots of stuff yes. But sometimes you have to write that part in a somewhat specific way to get synthesis to infer, or you might want the extra control options that the inputs & outputs of a hard block instance offer, or you might have a more elaborate interconnection between several hard blocks and it ends up being easier to just instantiate these hard blocks and set them up manually.
  - publicmail 3y ago
    In something as simple as the code in the article, yes. It's likely that the tool will infer a block RAM as long as there are BRAM resources with the required number of ports, etc. It gets a little more unreliable when you start accessing it in more complex ways though. From my understanding (I'm no FPGA expert), the code in the article will infer a BRAM with two read ports and one write port. That may be fine. I actually battled with this recently on a project. I found that the tool was not inferring a block RAM when I expected it to, so I had to modify the Verilog to gate the reads and writes so that only one could happen at a time. That wasn't an issue in my case though. My takeaway from the exercise was that it's sort of the equivalent of relying on the optimizer of a compiler to recognize the programming pattern and do the right thing. After talking to one of the FPGA guys I work with, he seemed to feel that it's better to just instantiate a vendor IP BRAM directly. The downside is portability though.
hasheddan 3y ago
Author here -- thanks for the feedback! This is a quick post that is focused on how to logically think about the circuit, but I agree that all of the attributes you enumerated are valuable information as well. I plan to continue diving deeper in future posts. I am currently posting every Friday as part of my goal of gaining a deep understanding of chip design[0]. Please feel free to continue to provide feedback on future posts as well! [0]: https://danielmangum.com/posts/a-three-year-bet-on-chip-design/ https://danielmangum.com/posts/a-three-year-bet-on-chip-desi...
- therealcamino 3y ago
  I think the article is fine but what you're really driving towards is the idea of synchronous design, and how that simplifies design and analysis. Some of the objections here might go away if it were framed that way.
  - hasheddan 3y ago
    That's a great point. Thanks for the feedback!
- boesboes 3y ago
  I liked the post. as a novice with fpgas and hdls, I find posts like this very approachable. Refreshing tbh
- perfopt 3y ago
  Perhaps showing the synthesized gates and how say a structural version of the code will synthesize would explain in more detail
devit 3y ago
It seems you can get a diagram of the actual circuit like this: 1. Go to https://edaplayground.com https://edaplayground.com 2. Paste the code in the right pane labeled "design.sv"; it's probably a good idea to reduce the number of registers to 2 to make the output more readable 3. On the left, select "Yosys" in tools and simulators (it seems to be the only one that works without additional configuration or fiddling) and enable "Show diagram after run" 4. Click "Run" and it should open an image with a graph rendering showing the circuit. If it doesn't work, try to disable adblockers or popup blockers (it opens the output as a pop-up apparently) You can also presumably run yosys locally. In this case, it implements every register as a D flip-flop; the rs outputs are implemented with muxes from the flip flops, and the D flip-flop value is set to either the current value of the register or to data depending whether write_ctrl is set and rd is equal to the register number.
boesboes 3y ago
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

Correct. The code shown is only good enough for RTL simulation. It won't help actually generate a chip with multiple read and write ports to a register file.

therealcamino 3y ago
That code is synthesizeable and will work fine in an ASIC flow.
tverbeure 3y ago
On an FPGA, it will infer a dual-ported BRAM memory just fine. On ASIC, it will generate a flip-flop array, which is good enough for many CPUs. E.g. in this physical layout of a Swerv RISC-V CPU, the ARF section is the register file, built out of flip-flops: https://tomverbeure.github.io/2019/03/13/SweRV.html#swerv-physical-design https://tomverbeure.github.io/2019/03/13/SweRV.html#swerv-ph....
- alain94040 3y ago
  Also, the read ports are asynchronous, which is bad: assign rv1 = registers[rs1]; assign rv2 = registers[rs2];

okl 3y ago

It's Verilog in this article.

monocasa 3y ago

You don't normally write register files in an HDL anyway (at least in the hard and soft flows I've dealt with). You don't want to build them out of regular logic so you end up wrapping some hard IP blocks. Block RAM on FPGAs, or the output of register file hard block generators on ASIC flows. The HDL just ends up being an interface boundary that gets swapped out for simulation.

bpye 3y ago
I think in an FPGA flow you could rely on inferring a block RAM no?
- monocasa 3y ago
  I've found that the synthesizer can infer a lot of the time, but I wouldn't say you can rely on it.
- d_tr 3y ago
  It can infer lots of stuff yes. But sometimes you have to write that part in a somewhat specific way to get synthesis to infer, or you might want the extra control options that the inputs & outputs of a hard block instance offer, or you might have a more elaborate interconnection between several hard blocks and it ends up being easier to just instantiate these hard blocks and set them up manually.
- publicmail 3y ago
  In something as simple as the code in the article, yes. It's likely that the tool will infer a block RAM as long as there are BRAM resources with the required number of ports, etc. It gets a little more unreliable when you start accessing it in more complex ways though. From my understanding (I'm no FPGA expert), the code in the article will infer a BRAM with two read ports and one write port. That may be fine. I actually battled with this recently on a project. I found that the tool was not inferring a block RAM when I expected it to, so I had to modify the Verilog to gate the reads and writes so that only one could happen at a time. That wasn't an issue in my case though. My takeaway from the exercise was that it's sort of the equivalent of relying on the optimizer of a compiler to recognize the programming pattern and do the right thing. After talking to one of the FPGA guys I work with, he seemed to feel that it's better to just instantiate a vendor IP BRAM directly. The downside is portability though.

hasheddan 3y ago

Author here -- thanks for the feedback! This is a quick post that is focused on how to logically think about the circuit, but I agree that all of the attributes you enumerated are valuable information as well. I plan to continue diving deeper in future posts. I am currently posting every Friday as part of my goal of gaining a deep understanding of chip design[0]. Please feel free to continue to provide feedback on future posts as well! [0]: https://danielmangum.com/posts/a-three-year-bet-on-chip-design/ https://danielmangum.com/posts/a-three-year-bet-on-chip-desi...

therealcamino 3y ago
I think the article is fine but what you're really driving towards is the idea of synchronous design, and how that simplifies design and analysis. Some of the objections here might go away if it were framed that way.
- hasheddan 3y ago
  That's a great point. Thanks for the feedback!
boesboes 3y ago
I liked the post. as a novice with fpgas and hdls, I find posts like this very approachable. Refreshing tbh
perfopt 3y ago
Perhaps showing the synthesized gates and how say a structural version of the code will synthesize would explain in more detail

devit 3y ago

It seems you can get a diagram of the actual circuit like this: 1. Go to https://edaplayground.com https://edaplayground.com 2. Paste the code in the right pane labeled "design.sv"; it's probably a good idea to reduce the number of registers to 2 to make the output more readable 3. On the left, select "Yosys" in tools and simulators (it seems to be the only one that works without additional configuration or fiddling) and enable "Show diagram after run" 4. Click "Run" and it should open an image with a graph rendering showing the circuit. If it doesn't work, try to disable adblockers or popup blockers (it opens the output as a pop-up apparently) You can also presumably run yosys locally. In this case, it implements every register as a D flip-flop; the rs outputs are implemented with muxes from the flip flops, and the D flip-flop value is set to either the current value of the register or to data depending whether write_ctrl is set and rd is equal to the register number.

boesboes 3y ago

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.