Inferring latch

Arithmetic operations as conditional expressions, as in the previous example, should be avoided when inferring latches since there is a very high probability of race condition between the conditionals in the synthesized netlist this might cause the latched value in the synthesized netlist to differ from that in the Verilog HDL model. 

The rules for inferring latches apply to casex and casez statements equally as well. 

An alternative way to avoid latches in the above example is to specify a default branch in the case statement or to make a default assignment to all variables assigned in a case statement (in this example, NextToggle), prior to the case statement. Here is an example that uses a default branch to avoid inferring latches. 

In this case, no latches are inferred for Z and NextState since the full case synthesis directive states that no other case item values can occur. However, the preferred style for not inferring latches is to use the default branch. 

In Chapter 2, we described rules for inferring latches. We also described an exception to the rule, that is, a variable does not infer a latch if it is used as a temporary. However, there are a few other cases where a variable may not infer a latch, even though it appears from the code sequence that it should. 

Let us reiterate the rales for inferring latches once more ... 

If you do not have the next state <= current state statement in the combinational process statement, DC will infer latches for the next state signal. In general, when using a case statement, one must cover all the possibilities or, in other words, assign the next state under all conditions. 

Here is an example where a latch is inferred for a variable. 

The variable Fox is not assigned in the else-branch of the conditional statement. Consequently, a latch is inferred for Fox since it needs to retain its value when Sat is true. The circuit synthesized in shown in Figure 1-10. 

A general rule for latch inferencing is that if a variable is not assigned in all possible executions of an always statement (for example, when a variable is not assigned in all branches of an if statement), then a latch is inferred. 

In this example, what should be the value of Grade if Marks has the value 12 It may be intended to be a don t care, but from the language semantics viewpoint, the variable Grade retains its last value, since no value is assigned to the variable explicitly when Marks has the value 12. Therefore a latch is inferred for Grade in keeping with the simulation semantics of a reg variable. 

A latch may be inferred for a variable assigned in a case statement, just like in an if statement. If a variable is not assigned a value in all possible executions of the always statement, such as when a variable is assigned a value in only some branches of a case statement, a latch is inferred for that variable. See the following example. 

Figure 2-33 Latch inferred for a variable in a case statement.

In the previous section, we saw that a latch may be inferred for a variable that is not assigned a value for all possible values of a case expression. Sometimes it is the case that the designer does not expect the case expression to have any value other than those listed in the case items. Here is an example. 

A synthesis tool on encountering such a directive on a case statement understands that all possible values (that can occur in the design) of the case expression have been listed and no other values are possible. Consequently, a variable assigned in all branches of the case statement will never infer a latch. Here is the case statement in the NextStateLogic module with the directive specified. 

As the synthesized netlist shows, no latches are inferred for NextToggle when the full case synthesis directive is used. 

Here is the always statement that has a default assignment for NextToggle no latches are inferred for NextToggle. 

It is necessary to specify the full case synthesis directive, otherwise latches are inferred for Address. Alternatively, an initial assignment to Address before the case statement can also be made to avoid latches no synthesis directive is then necessary. This is shown in the following always statement. 

Figure 2-39 An incompletely specified condition infers a latch.

The variable NextState is assigned a value only when ClockA is 1. If ClockA is 0, NextState retains its previous value, thus inferring a latch. 

A variable declared locally within an always statement is also inferred as a latch if it is incompletely assigned in a conditional statement (if statement or case statement). This is shown in the following module. 

If a variable is used before it is assigned in an incompletely specified conditional statement, then a latch is inferred. Here is such a module. 

If a variable, that is inferred as a latch, is assigned constant values in some branches of a conditional statement, bits that are 1 get assigned to the preset terminal of the latch, while those with 0 get assigned to the clear terminal. This is shown in the following example. 

Sequential logic elements, that is, flip-flops and latches, can be inferred by writing statements within an always statement using styles described in Chapter 2. It is best not to synthesize a memory as a two-dimensional array of flip-flops because this is an inefficient way to implement a memory. The best way to create a memory is to instantiate a predefined memory block using a module instantiation statement. 

Synthesis infers four flip-flops for this model, three for variable Previous and one for SeqFound. However, optimization reveals that one of the flip-flops for Previous is not necessary and hence it is removed. In this model, the output is latched since it is assigned a value under the control of a clock edge. If a latched output is not desired, then the assignment to SeqFound must be done outside the always statement. Such a module is shown next. 

In this module, the output SeqFound is not latched. Synthesis infers three flip-flops for variable Previous note that in this case, all the bits of Previous have to be latched. 

A variable that does not have a value assigned in all branches of a case statement or an if statement can lead to a latch being built. This is because in Verilog HDL, a reg variable (assigned within an always statement) infers memory, and thus if the variable is not assigned a value in all branches of a conditional statement, the value needs to be saved in memory. Here is an example. 

The best way to avoid latches is to first determine from the synthesis tool how many latches have been inferred. A designer now needs to go back and check if each latch inferred really needs to be a latch. It could be that the designer never intended for a latch or the designer forgot to specify values under all conditions. The best rale is to check the latches that get synthesized and go back and determine why each latch got synthesized and fix code if necessary to avoid any unwanted latches. 

All the three conditions must be satisfied before a variable is inferred as a latch. In the above always statement, DebugX violates rule (ii). Therefore no latch is produced for DebugX. 

In addition, passing the FPGA Express syntax checker does always NOT mean that the HDL code can be synthesized correctly since problems can arise later in the synthesis process. Also, synthesis may work, but not produce useful results. For example, you have to search the output schematic carefully to see whether latches are inferred by your incomplete if or case statements. 

HDL code can be behavioral or RTL. In the synthesis domain, the latter is usually considered to be the synthesizable form of HDL code. Since the focus of this book is on logic synthesis, all examples discussed are in synthesizable RTL code. As a preliminary introduction to HDL coding and synthesis let us consider the following simple examples. Four examples of HDL code which infer on synthesis a D-flip flop, a latch, an AND gate, and a multiplexer (referred to as mux throughout this book) respectively are discussed. 

---