Verilog: is else statement mandatory

In every language, if the condition is true then action1 else action2.

you are free to use if only or add else or else if depending on what you want to do in each case.

If a variable is not assigned in a construct then it retains its value. In synthesisable HDL, this means a latch or register(if clked).

The "missing else problem" is a modern urban legend caused by some ancient textbooks.

Please forget about it, there is no "missing else problem". There was one in the eigthies (more than 20 years ago) and only with one particular tool, but that got propagated in some books.

The code is perfectly legal and safe. Assuming there were no other logic controlling the value and compare signals the code be rewritten to look like:

if(value>=compare) begin
   value      <=0;
   compare <= compare;
end else begin
   value      <= value; 
   compare <= compare - 1;
end

It would have the exact same meaning as the original code. The latter is merely more verbose and adds no value.

Now if you want to get very technical, the two blocks of code can produce different synthesis results (though not in Quartus). I submit that the original code is actually more efficient. In both cases, the synthesis tool has to decide whether to implement the combinatorial logic as a clock enable (if the device has such a thing) or as an always enabled register with feedback from the register output.

Jake

--- Quote Start ---

Is there anything strictly dangerous about doing so in Quartus Verilog? Is is free to treat unspecified variables as "DON'T CARE", or will it enforce that the value not change?

--- Quote End ---

It will enforce a no change. We are all assuming this is part of a synchronous clocked process. If so, then this is ok in most cases.

If it is combinatorial logic, then it might be dangerous because it would normally produce an async latch.

--- Quote Start ---

In both cases, the synthesis tool has to decide whether to implement the combinatorial logic as a clock enable (if the device has such a thing) or as an always enabled register with feedback from the register output.

--- Quote End ---

I read this paragraph, and it sounds a bit misleading to me.

In most modern ASIC technologies, both things are actually the same. In other words, clock enable is usually implemented as a mux with the register feedback.

When talking about an FPGA, matters are different. e.g., in most Altera families, the clock enable is a LAB wide signal. Then both synthesis methods, clock enable or LUT based mux, are indeed different.

Thanks for the clarifications... for the most part the blocks are all part of synchronous (@posedge clock) always blocks.

I'll only enforce the more verbose style in combinatorial blocks.