# Why would this cause a latch?

To transcribe the Verilog code:

input   wire            i_S;
input   wire    [7:0]   i_V;
output  reg     [7:0]   o_R;

always @(*)
if (i_S)
o_R = i_V;


I can understand that if o_R is declared as a wire, then a latch will be inferred as wires have no memory, and thus some external memory is required to keep the previous value. However, o_R is a register here, and registers can keep their state. For example, we can simply connect i_S to the "write enable" pin of the flip-flop corresponding to o_R, so why do we have a latch now?

As a bonus, why is a latch, rather than a flip-flop, inferred in such a situation? I'm under the impression that they basically serve the same purpose.

The always block is evaluated every time i_S or i_V changes. You haven't specified what the value of o_R should be when i_S is false, so the simulator and synthesizer assume that you just want to retain the old value of o_R in this case. Therefore, a latch is inserted.

The terms latch and flip-flop are not standardized, but most people use latch to mean a level-sensitive bistable element while a flip-flop is an edge-sensitive bistable element. They are not the same.

• "you just want to retain the old value of o_R" I understand this, but registers/flip-flops (which I assume would be inferred from the keyword reg) are born to retain their previous value! Why do we need an additional latch then? – nalzok Dec 12 '19 at 13:58
• No, you are mistaken about the reg keyword, it does not infer a latch by default. Latch inference is determined by the behavior of the HDL code. – Elliot Alderson Dec 12 '19 at 14:01
• Hi Alderson, please kindly re-read my comment (and preferably the question too). Would reg definitely infer a register/flip-flop (not latch)? Speaking of the behavior, AFAIK o_R is required to keep its previous value because reg is used, so it will infer a register/flip-flop. – nalzok Dec 12 '19 at 14:08
• NO, reg does not definitely infer a flip-flop or a latch. The keyword reg defines something that acts like a regular variable in a typical programming language, meaning that it allows sequential evaluation within an always block. But a latch or flip-flop is only inferred if the behavior of the code indicates that a latch or flip-flop is required. One last time...using reg does not inherently cause a latch or flip-flop to be inferred. – Elliot Alderson Dec 12 '19 at 14:13
• Thanks, let's see if my understanding is correct now: so I write Verilog to specify the behavior, and the synthesizer will figure out which hardware to use to fulfill my requirement. In the code above, always @(*) requires o_R to change when any input is changed, so a level-sensitive latch is inferred instead of an edge-sensitive flip-flop (we don't even have a CLK signal here!). In addition, if I add o_R = 0 just above the if (i_S) line, neither latches nor flip-flops will be inferred despite the keyword reg, because the behavior can be fulfill with purely combinational logic. – nalzok Dec 12 '19 at 14:31

First: the 'reg' keyword in Verilog has little to do with the final circuit. I can produce registers but also combinatorial logic.... and latches. It is confusing and I assume the main the reason why in System Verilog they switched to the 'logic' type.

Register outputs only change on a clock edge (or asynchronous reset/set). They keep their output value even if the input changes.

A latch does not. As long as your I_s is high the o_R will change if the I_V changes. We say that "o_R follows the I_V".

Thus a register and latch definitely do not serve the same purpose.

• Forgive my ignorance, but why do we need to care about what happened between two posedges? I mean, even flip-flops have setup/hold time, but people don't seem to care about that. I assume we just need to make sure the values are "correct" at each posedge, because that is all what our code asks for? – nalzok Dec 12 '19 at 13:55
• @nalzok In the real world, people care very, very much about setup and hold time. – Elliot Alderson Dec 12 '19 at 14:13
• @ElliotAlderson Thanks for the explanation. I just realized that timing analysis is at least partially based on setup and hold time. Maybe I can even say people don't need to care about them because timing analysis ensures the signals will be stable at each clock edge. – nalzok Dec 12 '19 at 14:21