@amiloradovsky The "generate" statement is also available in plain Verilog. Generate will actually "instantiate" new constructs within it. So if you have a generate for loop with an instance of Module(), you will have the same number of Module() instances as you do loop iterations (of course same applies to wires etc). The names of module instances and wires defined in the loop are all scoped to the generate for loop. I've used that construct quite a bit over time in different scenarios.
@cstanhope Ordinary "for" (not within a "generate") will also generate so many instances of the body, but is indexed by a variable indistinguishable from a signal/register, which in fact is meta-syntax one and is more like "genvar". What isn't clear is where to use "for" without "generate", or why they ever kept the two constructions.
"genvar"s are also untyped AFAICT, prone to errors.
@amiloradovsky I'm not sure. I've definitely used implementations of Verilog (not SystemVerilog) which would not let me create instances of modules or wires outside of generate blocks. I tend to think of generate blocks as a kind of weak templating system or slightly weird C macro system. Of course, what you say about types are true. Although plain Verilog has so few types anyway. ;)
@amiloradovsky Thinking about it, whenever I am working, I tend to be targeting at least two implementations of Verilog: the toolchain used to generate a bitstream and the toolchain used to simulate. Often these disagree about what Verilog is. So I end up writing to the subset of the language they both can agree to, which is hopefully a useful subset. 😆
@cstanhope It's probably the subset which the specification is unambiguous about…
Either way, the point is to use not as much of the specification but as little of it as possible, generating Verilog from a decent language (Koika, BlueSpec, (n)Mingen, etc.).
Not to say that I used any extensively any of those, but that's what to aspire to.
OTOH, I'm not super fond of the proliferation of intermediate forms, and perhaps modern VHDL+OSVVM would be preferable in most cases.
@amiloradovsky I do want to try one of the languages you refer to. Probably Mingen to start. I've stayed away from it for work because it is much easier to find people who can work in Verilog and VHDL than other languages. In a pinch, a contractor can be brought in and they could probably easily get to work. I'll have to explore these options in my own time (like always).
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!