Structural vs Behavioral

Personally I like neither of these descriptions of a decoder; how about the following:

always @(address) begin row = 0; row[address] = 1'b1; end

This is likely to be efficient both for synthesis and for simulation, and (at least to me) it is crystal-clear that it represents a decoder, unlike "1

Well the third way juste requires a few extra bytes :

always @(address) // that's a decoder row = 2**address;

:-)

MB

Personally I would use

wire [3:0] row = 1

Not that this answers your question... but I believe both of these code fragments are behavorial code. Structural code instantiates components.

The style of code I use is always based on the synthesis tool's guidelines doc. It's the first thing I read before writing any code.

Fascinating... I can't easily think of another four lines of text that could be as diametrically opposed to my own position as these.

Point by point...

Succinct - yes, but it needs a comment to make it easily comprehensible, thus dramatically reducing the (IMHO imaginary) benefit of brevity. Why is brevity good, for heavens' sake? Any half-decent piece of code will be at least 50% comment, so there is at the very most 50% saving to be made from brevity of code - and nothing, not even the tiniest thing, that compromises clarity and maintainability is worth that. Code is written once but read (and modified) often; saving a few keystrokes is not something that's worth chasing.

Commented - yes, for sure. But the comments are just that, comments; they can get out-of-step with the code, and nobody gets to check. If, by writing somewhat more verbose code, I can "animate" the comments so that they are part of the code's functionality, then I don't have that risk. In general I am deeply distrustful of comments that describe the behaviour of procedural code, which tends to be almost self-evident to anyone skilled in the language; the teacher in me still comes out in a cold sweat at the sight of this vacuity: i = i + 1; // increment i So, let's have the comments as far as possible embedded in the code itself. Intriguingly, the most useful part of your commentary, where you say "assert row[address]", could easily be a piece of procedural Verilog (see my earlier post). Note, by the way, that assertions provide an even better way to add "animated comments" that *are* checked by tools. An assertion could easily check for one-hot-ness of the output, for example.

Why bother with always? - Because it gives me a lot more room to manoeuvre if I later decide I need to change something. Especially in Verilog, where the change from "assign" to "always" also impacts the declaration of various things, I lean towards using "always" right from the start so that there's less to change later. Of course there are exceptions: some places you have little choice but to use assign (three-state drivers, etc); certain patterns of glue logic, like fixes for the polarity of strobe signals, are nicer done as assigns. But any logic with some real functionality behind it IMHO belongs in a procedural block.

These are emphatically my own opinions and I am very much aware that many skilled people will profoundly disagree with me. I'm sure there is a place for both points of view, and for many in between. Just so long as everyone is aware that the choice is not obvious :-)

I'd have to vote with John_H here but I know many won't.

wire [3:0] row = 1

I could also say it wasn't that long ago that I would have written

DEC4_1 u0 (.addr(i), .out(o)); // or whatever the std cell was called

Now that synthesis has fully taken over except at the very top end of the speed curve, its not so necessary, only on interesting block level.

Although instancing of blocks is usually considered structural or schematic thinking, you can then put anything at all into the module that describes that it even the original case statement as the visual clutter from it is now elsewhere.

There is another way to have it both ways and that is to use a folding text editor, click on the 1 liner and see the the 1 or 5 or 100 lines it represents. Pretty much a schematic thing to do to when you could push down into sub sheets.

Does anyone actually use such a thing, recomendations esp Windows,

I half suspect Emacs can do it but never took to it.

johnjakson at usa dot com

I used to use CodeWright - dunno if it even still exists, but that did folding IIRC.

:-) Yes, I use folding-mode a lot in my VHDL - the emacs VHDL-mode is the reason I finally took the plunge with emacs!

I don't think the verilog-mode is as fully-featured - so maybe it won't suit you so much...

Cheers, Martin

I'd say that a compiler that warns about unnecessary parenthesis in expressions with bit manipulation is broken. It is far more helpful for the compiler to warn about not having enough parenthesis to make the meaning clear - gcc does this, with appropriate flags.

Code should be written to be easily read and easily understood - not to be typed with the minimal number of characters. When C was first used, minimal character count was a priority - and the results of that language design decision have been felt ever since. Writing long-winded or excessively commented code is just as bad as overly terse and compact code, however.