Return to previous page Advance to next page
Verilog Reference Guide
Chapter 5: Functional Descriptions

always Blocks

An always block can imply latches or flip-flops, or it can specify purely combinatorial logic. An always block can contain logic triggered in response to a change in a level or the rising or falling edge of a signal. The syntax of an always block follows.

always @ (event-expression [or event-expression*]) begin
   ... statements ...
end

Event Expression

The event expression declares the triggers or timing controls. The word or groups several triggers together. The Verilog language specifies that if triggers in the event expression occur, the block is executed. Only one trigger in a group of triggers needs to occur for the block to be executed. However, Foundation Express ignores the event expression unless it is a synchronous trigger that infers a register. Refer to the “Register and Three-State Inference” chapter for details.

In the following example, a, b, and c are asynchronous triggers. If any triggers change, the simulator simulates the always block again and recalculates the value of f. Foundation Express ignores the triggers in this example because they are not synchronous. However, you must indicate all variables that are read in the always block as triggers.

always @ ( a or b or c ) begin
   f = a & b & c
end

If you do not indicate all the variables as triggers, Foundation Express gives a warning message similar to the following.

Warning: Variable `foo' is being read in block `bar'declared on line 88 but does not occur in the timing control of the block.

For a synchronous always block, Foundation Express does not require all variables to be listed.

An always block is triggered by any of the following types of event expressions.

When the event expression does not contain posedge or negedge, combinatorial logic (no registers) is usually generated, although flow-through latches can be generated.

Note: The statements @ (posedge clock) and @ (negedge clock) are not supported in functions or tasks.

Incomplete Event Specification

An always block can be misinterpreted if you do not list all signals entering an always block in the event specification.

Foundation Express builds a 3-input AND gate for the description in the following example. However, when this description is simulated, f is not recalculated when c changes, because c is not listed in the event expression. The simulated behavior is not that of a 3-input AND gate.

always @(a or b) begin
   f = a & b & c;
end

The simulated behavior of the description in the following example is correct because it includes all signals in event expression.

always @(a or b or c) begin
   f = a & b & c;
end

In some cases, you cannot list all signals in the event specification. The following example illustrates this problem.

always @ (posedge c or posedge p)
   if (p)
      z = d;
   else
      z = a;

In the logic synthesized for the example above, if d changes while p is high, the change is reflected immediately in the output (z). However, when this description is simulated, z is not recalculated when d changes, because d is not listed in the event specification. As a result, synthesis might not match simulation.

Asynchronous preloads can be correctly modeled in Foundation Express only when you want changes in the load data to be immediately reflected in the output. In the example of an incomplete event list, data d must change to the preload value before preload condition p transits from low to high. If you attempt to read a value in an asynchronous preload, Foundation Express prints a warning similar to the one shown below.

Warning: Variable `d' is being read asynchronously in routine reset line 21 in file `/usrests/hdl/asyn.v'. This might cause simulation-synthesis mismatches.