Verilog and unchanged output registers?

Question

This is probably an absolute newbie question but what happens to "unchanged" output register as in the following example(pseudocode):

module TOP(
 input CLK,
 input A,
 input B,
 output reg O1,
 output reg O2
);
reg state = 0;
always @(posedge CLK) begin
 case(state)
 0: begin 
 O1 <= A;
 state <= 1;
 end
 1: begin 
 O2 <= B;
 state <= 0;
 end
 endcase
endmodule

Do O1 and O2 keep the same value as for the last pass where they were specifically set or are they undefined in the pass where they are not specifically set?

Thank you very much in advance!

• Dave Tweed: Previous values are retained if not otherwise set on any given path through the always block.

Answer 1

Once you assign a register variable^* with = or <=, it retains its value until the next time it is assigned.

^* Verilog "register variables" do not always represent actual registers in synthesized hardware.

Answer 2

When working with a hardware description language you must always think of the hardware implementation to better understand the expected result.

It is a good idea to check some available tools especially for simple descriptions like this one. This lets you mastering the HDL like Verilog.

For instance, the Netlist Viewer can show you the hardware implementation for your description. In your case it is the following:

enter image description here

This shows that at the arrival of the clock, depending on the "state" resulting of the previous clock, B or A are assigned. And "state" is complemented and this complemented value will be used in the next clock for assigning A or B. the outputs of the latches are of course maintained between clocks.

Answer 3

Yes, unchanged registers are implicitly "latched", which may require the compiler to dedicate additional resources to ensuring these semantics (usually you will get a warning here).

If your logic doesn't depend on this behavior, you can explicitly assign an undefined value, which allows for better optimization during synthesis and also shows subtle timing errors in simulation when a value is taken over in a different cycle than expected.