Always statement

An always statement is used to model the procedural behavior of a circuit. Here is an example of an always statement that contains procedural assignment statements. 

All variables whose values are read in the always statement must appear in the event list (the parenthesized list following the symbol) otherwise the functionality of the synthesized netlist may not match that of the design model. Here is a simple example that illustrates this point. 

The semantics of the always statement specifies that whenever an event occurs on B, the assignment is to be executed and Z gets a value. If any events occur on A, this has no impact on the value of Z. However, the synthesized netlist of the above module, shown in Figure 2-21, shows an and gate. Here any time A or B changes, the value of Z is updated. Hence a... 

A good practice is to include all variables read in the always statement in the event list this is true only when modeling combinational logic. When modeling sequential logic, a different kind of event list is required this is described later. 

A variable declared within an always statement holds a temporary value and does not necessarily infer a unique wire in hardware as the following example shows. 

The semantics of the always statement specifies that every time an event occurs on Phy or Ones (variables present in the event list), the if statement executes and the variable Z gets the value of Ones incremented by 1 if Phy is a 1. If Phy is a 0, the value in Z is retained this is done using latches. 

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. 

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. 

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. 

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. 

A flip-flop is inferred from a variable when it is assigned a value in a special form of always statement. This always statement is of the form ... 

The semantics of the always statement implies that all statements in are to be executed only when a rising edge or a falling edge of clock occurs. We shall call this special always statement as a clocked always statement. 

Figure 2-45 Sequential logic synthesized using a special always statement.

The logic in the always statement implies that every time there is a rising edge on ClockA, variable Counter is incremented. Since Counter is as-... 

Hip-flop inference rule is simple If a variable is assigned a value under the control of a clock edge, a flip-flop is generated an exception to this rule is when a variable is assigned and used only locally within an always statement as an intermediate variable. 

In all the above cases, a variable was assigned under the control of a clock and its value was used outside of the always statement, thus requiring its value to be saved in a flip-flop. 

What if a variable is defined globally (outside the always statement) but used only locally within an always statement Here is an example. 

What happens in the above case if we switch the order of the statements around In this case, since the value of Temp is used before its assignment, its value needs to be retained across multiple clock cycles, thereby inferring flip-flops for Temp. Temp models the internal state of the always statement. This is shown in the following example, where Temp is used before its assignment. 

What if variables are declared locally within an always statement ... 

Variables (reg and integer types) declared locally within an always statement do not infer flip-flops. This may potentially lead to a functional mismatch between the Verilog HDL model and the synthesized netlist. Here is an example of a locally declared variable Temp that does not get inferred as a flip-flop. 

No flip-flops are inferred for Temp since it is locally declared within the always statement and a value is assigned to the variable and used immediately in the same clock edge. Flip-flops are inferred for NextState (as this... 

It is possible to have a single module that has multiple clocked always statements. Here is such an example of multiple clocks used in a single model. 

This module has two always statements. The statements in the first always statement are controlled by a positive edge of clock Vt 15Clock, while the statements in the second always statement are controlled by the positive edge of clock Dsl Clock. 

A restriction usually imposed by a synthesis system is that a variable cannot be assigned under the control of more than one clock. For example, it would be illegal to assign to AddState in the second always statement. 

What if we want to model a flip-flop with synchronous preset and clear In such a case, simply describe the synchronous preset and clear logic within a clocked always statement (an always statement with a clock event). Here is an example. 

In this case, the assignment to FCR must complete first before assignment 2 is done. Thus to mimic the language semantics, the right-hand-side expression of assignment 1 must be used to form the logic for the data for Claim. This is shown in the synthesized netlist. In addition, no flip-flop is inferred for FCR since its value is assigned and then used the value of FCR does not have to be saved between different iterations of the always statement. 

A task call can represent either combinational logic or sequential logic depending on the context under which the task call occurs. By this, we mean that the output parameters of a task call may imply memory depending on the context in which they are assigned. For example, if a task call occurs in a clocked always statement (always statement with a clock event), then an output parameter in a task call may be synthesized as a flip-flop this is determined by using the flip-flop inference rales. A synthesis system implements a task call by expanding the task call in-line with the rest of the code in effect, no separate hierarchy for the task call is maintained. 

If a variable is assigned a value z in an always statement in which the variable is also inferred as a flip-flop, then it becomes necessary to save the enabling logic of the three-state also in a flip-flop. Here is the same example as above except that the always statement is controlled by a clock event. 

Notice that in this case a temporary variable TempSelectl is introduced that is used to communicate between the first always statement (sequential part) with the second always statement (combinational part). Only one flip-flop is synthesized for TempSelectl. 

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. 

---