V SEMESTER BE(ECE) VERILOG HDL (18EC55) 2020-21

MODULE 4

SYNTHESIS AND VERIFICATION

Verilog HDL is a hardware description language that can describe hardware not
only at the gate level and the register-transfer level (RTL), but also at the algorithmic
level. This makes translating a design described in Verilog HDL to logic gates a non-
trivial process. It explains how the basics involved in the mapping of a Verilog HDL
model to logic gates.

4.1 What is Synthesis?

Synthesis is the process of constructing a gate level netlist from a register transfer
level model of a circuit described in Verilog HDL. Figure 4-1 shows such a process. A
synthesis system may as an intermediate step, generate a netlist that is comprised of
register-transfer level blocks such as flip-flops, arithmetic-logic-units, and multiplexers,
interconnected by wires. In such a case, a second program called the RTL module builder
is necessary. The purpose of this builder is to build, or acquire from a library of
predefined components, each of the required RTL blocks in the user-specified target
technology.

Figure 4.1 The synthesis process.

Having produced a gate level netlist, a logic optimizer reads in the netlist and optimizes
the circuit for the user-specified area and timing constraints. These area and timing
constraints may also be used by the module builder for appropriate selection or generation
of RTL blocks.

Figure 4-2 shows the basic elements of Verilog HDL and the elements used in
hardware. A mapping mechanism or a construction mechanism has to be provided that

B.S.BALAJI, ASST. PROF, DEPT. ECE. BGSIT – ACU. 1

V SEMESTER BE(ECE) VERILOG HDL (18EC55) 2020-21
translates the Verilog HDL elements into their corresponding hardware elements.
Questions to ask are:

How does a data type translate to hardware?

How are constants mapped to logic values?

How are statements translated to hardware?

The following sections discuss these mappings in more detail.

Figure 4-2 The two worlds of synthesis.

4.2 Synthesis in a Design Process

Verilog HDL is a hardware description language that allows a designer to model a
circuit at different levels of abstraction, ranging from the gate level, register-transfer
level, behavioral level to the algorithmic level. Thus a circuit can be described in many
different ways, not all of which may be synthesizable. Compounding this is the fact that
Verilog HDL was designed primarily as a simulation language and not as a language for
synthesis. Consequently, there are many constructs in Verilog HDL that have no
hardware counterpart, for example, the $display system call. Also there is no standardized
subset of Verilog HDL for register-transfer level synthesis.

Because of these problems, different synthesis systems support different Verilog HDL
subsets for synthesis. Since there is no single object in Verilog HDL that means a latch or
a flip-flop, each synthesis system may provide different mechanisms to model a flip-flop
or a latch. Each synthesis system therefore defines its own subset of Verilog HDL
including its own modeling style.

Figure 4-3 shows a circuit that is described in many different ways using Verilog HDL. A
synthesis system that supports synthesis of styles A and B may not support that of style C
This implies that typically synthesis models are non-portable across different synthesis
systems. Style D may not be synthesizable at all.

B.S.BALAJI, ASST. PROF, DEPT. ECE. BGSIT – ACU. 2

V SEMESTER BE(ECE) VERILOG HDL (18EC55) 2020-21

Figure 4-3 Same behavior, different styles.

This limitation creates a severe handicap because now the designer not only has to
understand Verilog HDL, but also has to understand the synthesis-specific modeling style
before a synthesizable model can be written. The typical design process shown in Figure
4-4 cannot always be followed for Verilog HDL synthesis.

Figure 4-4 Typical design process.

The problem with this design process is that if the Verilog HDL model is written without
knowing the synthesis modeling style (this assumes that the model is being written for
synthesis; if not, then a non-synthesizable model may be perfectly okay), only during the
synthesis phase will the de signer learn about the synthesis-specific modeling restriction
and style for synthesis. A model rewrite may be necessary at this point. Also a lot of time
may have been wasted in the "Write Verilog HDL model" -> "Compile model" ->
"Verify" -> "Edit model” loop. Instead, a more practical design process shown in Figure
4-5 has to be followed for Verilog HDL synthesis. The synthesis methodology checker is
B.S.BALAJI, ASST. PROF, DEPT. ECE. BGSIT – ACU. 3
V SEMESTER BE(ECE) VERILOG HDL (18EC55) 2020-21
needed to ensure that the model being written is synthesizable. Note that this must be
done within the first verification loop. In this way, after the verification results have been
checked, a verified synthesizable model exists, which can then be synthesized.

Figure 4-5 New design process.

4.3 Logic Value System

The common values used in modeling hardware are:

 logic-0

 logic-1

 high-impedance

 don't care

 unknown

All these values are defined explicitly in Verilog HDL except for the don't-care value. A
synthesis system treats the value x, when it is assigned to a variable, as a don't care value.
Here is the mapping between the Verilog HDL values and the hardware modeling values:

B.S.BALAJI, ASST. PROF, DEPT. ECE. BGSIT – ACU. 4

V SEMESTER BE(ECE) VERILOG HDL (18EC55) 2020-21
 0 <--> logic-0

 1 <--> logic-1

 z<--> high-impedance

 z<--> don't care (in casex and casez statements)

 x<--> don't care

 x <--> unknown

 X<--> don't care

 x <--> unknown

4.4 Bit-widths
4.4.1 Data Types
In Verilog HDL, a variable belongs to one of the two data types:

i. Net data type

ii. Register data type

Net Data Type

The size of a net is explicitly specified in a net declaration

wire [4:0] Dak; // A 5-bit wire net.

wor Ax; // 1-bit wor net.

When no size is explicitly specified in a net declaration, the default size is one bit.

Here are the different kinds of net data types that are supported for synthesis.

The wire net is the most commonly used net type. When there are multiple drivers driving
a wire net, the outputs of the drivers are shorted together. Here is an example.

B.S.BALAJI, ASST. PROF, DEPT. ECE. BGSIT – ACU. 5

V SEMESTER BE(ECE) VERILOG HDL (18EC55) 2020-21

//Synthesized netlist is shown in Figure 4-6.

Figure 4-6 Multiple drivers driving a wire net.

The wor nets and wand nets are used when multiple driver resolution needs to be
performed using or-logic and and-logic respectively. Upon synthesis, multiple drivers of
such a net are connected together by an or gate (for a wor net) and by an and gate (for a
wand net). Here is an example that shows this effect.

//Synthesized netlist is shown in Figure 4-7.

B.S.BALAJI, ASST. PROF, DEPT. ECE. BGSIT – ACU. 6

V SEMESTER BE(ECE) VERILOG HDL (18EC55) 2020-21

Figure 4-7 Wand net and wor net have multiple drivers.

The tri net synthesizes just like the wire net.

A supply net synthesizes to a wire that is permanently connected to 0 (logic-0), while a

supply1 net synthesizes to a wire that is permanently connected to 1 (logic-1).

Register Data Type

The different kinds of register types that are supported for synthesis are:

A reg declaration explicitly specifies the size, that is, the corresponding number of bits of
the variable in hardware. For example,

When no size is explicitly specified in a reg declaration, the default is one bit.

For an integer type, the maximum size is 32 bits and the number is assumed to be in 2's
complement form. Optionally a synthesis system may perform data flow analysis of the
model to determine the maximum size of an integer variable. For example,

Size of Arb is determined to be 6 bits. An adder of size 6 is sufficient. The leftmost bit is
the carry bit.

The register types: time and real, are not supported for synthesis.

B.S.BALAJI, ASST. PROF, DEPT. ECE. BGSIT – ACU. 7

V SEMESTER BE(ECE) VERILOG HDL (18EC55) 2020-21
4.4.2 Constants
There are three kinds of constants in Verilog HDL: integer, real and string. Real and
string constants are not supported for synthesis.

An integer constant can be written in either of the following two forms.

i. Simple decimal

in. Base format

When an integer is written in a simple decimal form, it is interpreted as a signed number.

The integer is represented in synthesis as 32 bits in 2's complement form. If an integer is
written in the base format form, then the integer is treated as an unsigned number. If a
size is explicitly specified for the integer, then the specified size is the number of bits
used for the inte ger; if not, 32 bits is used for the size. Here are some examples.

4.4.3 Parameters

A parameter is a named constant. Since no size is allowed to be specified for a parameter,

the size of the parameter is the same as the size of the constant itself.

RED and GREEN are two 32-bit signed constants. READY, BUSY and EXIT is three
parameters of size 2 bits each.

4.5 Value Holders for Hardware Modeling

The basic value holders in hardware are:

 wire

 flip-flop (an edge-triggered storage element)

 latch (a level-sensitive storage element)

A variable in Verilog HDL can either be of the net data type or the register data type. For
synthesis, a variable of net type maps to a wire in hardware and a variable of the register
type maps either to a wire or a storage element (flip-flop or latch) depending on the
B.S.BALAJI, ASST. PROF, DEPT. ECE. BGSIT – ACU. 8
V SEMESTER BE(ECE) VERILOG HDL (18EC55) 2020-21
context under which the variable is assigned a value. Let us look at a variable of register
type in more detail.

In Verilog HDL, a register variable retains its value through the entire simulation run,
thus inferring memory. However, this is too general for synthesis. Here is an example of a
variable that is used as a temporary and therefore need not be a candidate for a storage
element.

Variable Trq is assigned in the first statement and then used in the right hand-side
expression of the second statement. Verilog HDL semantics indicate that Trq retains its
value through the entire simulation run. However, it is not necessary to store the value of
Trq as a storage element in hardware, since it is assigned and used immediately. Figure 4-
8 shows the logic generated.

Figure 4-8 Variable Trq is a wire.

Let us look at another example. In this case, variable Trq is used before its assignment.

The semantics of this always statement is very clear in Verilog HDL. Whenever an event
occurs on Bar, Acr, or Fra (those in the event list), execute the always statement. Since
Trq is used before its assignment, Trq has to hold its value during repeated executions of
the always statement, thus inferring memory. However, it is not clear how to build a latch
for Trq because Trq is not assigned a value under the control of any condition.

B.S.BALAJI, ASST. PROF, DEPT. ECE. BGSIT – ACU. 9

V SEMESTER BE(ECE) VERILOG HDL (18EC55) 2020-21
A synthesis system may not create a latch in this case and may generate the circuit shown
in Figure 4-9. Variable Trq is synthesized to a wire again. However, for functionality to
match between the Verilog HDL model and the synthesized netlist, Trq must also be in
the event list of the always statement.

Figure 4-9 No latch for variable Trq.

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 4-10. How is a flip-flop inferred? It depends
on the modeling style being followed and the context under which a variable is assigned a
value.

Figure 4-10 Variable Fox is a latch.

This and other examples for flip-flop and latch inferencing are discussed in the next
chapter. A memory in hardware can be modeled as an array of flip flops or latches.

4.6 Verification
B.S.BALAJI, ASST. PROF, DEPT. ECE. BGSIT – ACU. 10
V SEMESTER BE(ECE) VERILOG HDL (18EC55) 2020-21

Having synthesized a Verilog HDL model into a netlist, it is important to verify the
functionality of the synthesized netlist to ensure that it still matches the intended
functionality. This step is important since a synthesis system may make certain
assumptions or interpretations of the Verilog HDL code that may not match those
intended by the model writer.
In this chapter, we assume that this verification step is performed using simulation which
verifies the functionality between the design model and its synthesized netlist. We
illustrate some cases of functional mismatches between the design model and its
synthesized netlist that might possibly occur, describe their cause, and provide
recommendations for avoiding them.
In this chapter, we assume that the synthesis process produces a synthesized netlist in
Verilog HDL as shown in Figure 4-11. A Verilog HDL netlist is a collection of module
instances interconnected by nets.

Figure 4-11 A netlist is produced from synthesis.

4.7 A Test Bench

One approach to verifying functionality is to simulate the netlist with the same set of
stimulus as used during design model simulation, save the results in a results file and
compare to see if the results are identical. This scenario is shown in Figure 4-12.

Figure 4-12 Verification by simulation.

Another approach is to write a test bench; a test bench is a model writ ten in Verilog HDL
that applies stimulus, compares the output responses, and reports any functional
mismatches. Figure 4-13 shows such a scenario A test bench for a full-adder is shown
next. The stimulus is read from a vector file "Inputs.vec"; its contents are of the form:

B.S.BALAJI, ASST. PROF, DEPT. ECE. BGSIT – ACU. 11

V SEMESTER BE(ECE) VERILOG HDL (18EC55) 2020-21

Figure 4-13 Using a common test bench.

This test bench prints all mismatch violations that occur.

B.S.BALAJI, ASST. PROF, DEPT. ECE. BGSIT – ACU. 12

V SEMESTER BE(ECE) VERILOG HDL (18EC55) 2020-21
In the following sections, we see examples of how mismatches may occur that may be
caused due to different interpretations by synthesis (as compared to Verilog HDL
language semantics).

4.8 Delays in Assignment Statements

Delays specified in a design model may cause a functional mismatch between the model
and the synthesized netlist. Here is an example of an adder model that uses a delay in a
continuous assignment, and its synthesized netlist.

If vectors from a stimulus file were applied, say every 1 ns, and all the module instances
in the netlist represent behavioral models with no delay, the results between the design
B.S.BALAJI, ASST. PROF, DEPT. ECE. BGSIT – ACU. 13
V SEMESTER BE(ECE) VERILOG HDL (18EC55) 2020-21
model and the netlist will be skewed because of the difference in delays. The correct
approach in such a case is:

i. Either to delete all delays from the design model,

ii. Or to apply the stimulus with a period greater than 5 ns: a better rule. When delays are
present in the models for the library modules, these delays must also be considered in
determining the stimulus period.

Recommendation: To avoid delays in a design model from causing functional

mismatches, the maximum delay in the model must be computed. The stimulus
application time must be greater than this maximum delay.

4.9 Unconnected ports

It could happen that a synthesized netlist has a module instance with an unconnected
input port. Such a case is shown in the following example.

B.S.BALAJI, ASST. PROF, DEPT. ECE. BGSIT – ACU. 14

V SEMESTER BE(ECE) VERILOG HDL (18EC55) 2020-21
Notice that in the synthesized netlist, the first input of the AND2 module instance SI_I is
open. During the simulation of module A0122_NetList, the open input takes the value z',
whereas the unassigned value of C in module AO122" takes on a default value of x. The
fact that different values are used for C during the design model simulation and the
synthesized netlist simulation, a potential exists for functional mismatch to occur due to
different values being the default in the two different domains.

Recommendation: A good synthesis system will issue warning messages about a value
used before being assigned (such as variable C in the module AO122). Pay attention to
these warnings.

4.10 Missing Latches

In Module 3, 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 consider the first case.

In this always statement, variable DebugX is assigned in all branches of the if statement.
However, data flow analysis reveals that the value of DebugX needs to be saved (since its
value is used before an assignment when Control is false). In this case, a synthesis system
may produce a warning message about variable DebugX being used before its assignment
and also about a potential functional mismatch that may occur between the design model
and its synthesized netlist.

Let us reiterate the rules for inferring latches once more:

i. A variable is assigned in a conditional statement (if or case), and

ii. Variable is NOT assigned in all branches of the conditional statement, and

iii. Value of variable needs to be saved between multiple invocations of the always
statement.

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.

Here is another example.

B.S.BALAJI, ASST. PROF, DEPT. ECE. BGSIT – ACU. 15

V SEMESTER BE(ECE) VERILOG HDL (18EC55) 2020-21

In this always statement, it appears that there should be a latch for either DebugX or Bdy.
There is no latch for DebugX since it violates rule (ii). There is no latch for Bdy since it
violates rule (i). Language semantics however indicate that value for Bdy needs to be
saved. A synthesis system in this case may not produce a latch; instead it may issue a
warning message about Bdy being used before its assignment and in addition, produce a
warning message about a potential for functional mismatch that may occur.

In the following always statement, no latch is produced for DebugX since it violates rule
(ii) but a latch is produced for Bdy.

What about the following always statement?

B.S.BALAJI, ASST. PROF, DEPT. ECE. BGSIT – ACU. 16

V SEMESTER BE(ECE) VERILOG HDL (18EC55) 2020-21
There are no latches for DebugX and Bdy. However language semantics indicate that Bdy
needs to be saved. A synthesis system may not produce a latch; it may generate a warning
about the variable being used before its assignment and that there is a potential for a
functional mismatch.

4.11 More on Delays

Delays are often ignored by a synthesis system. The fact that they are ignored may simply
cause simulation results to differ between the synthesized netlist and the design model. A
case in point.

Model simulation shows a value of 1 on LX after 3 ns and the value going to 0 after 5 ns
if the condition CondA is true. However, since a synthesis system ignores delays, if
CondA is true, the net effect is as if a 0 is assigned to LX and the appropriate hardware
gets synthesized to reflect this. Notice that if the synthesized netlist is simulated, the value
of LX will not go to 1 if CondA is true.

Recommendation: Avoid inserting delays into a design model that is to be synthesized. If

necessary, lump total delays for a variable in one place.

4.12 Event List

Quite often, a synthesis system ignores the event list of an always statement during
synthesis. This can lead to functional mismatches if proper care is not taken in modeling.
Here is a simple example.

// Synthesized netlist is shown in Figure 4-14.

Figure 4-14 Netlist is sensitive to both Read and Clock.

B.S.BALAJI, ASST. PROF, DEPT. ECE. BGSIT – ACU. 17

V SEMESTER BE(ECE) VERILOG HDL (18EC55) 2020-21
The synthesized netlist, as shown in Figure 4-14, evaluates on all changes of Read and
Clock, while the always statement executes only on changes to Read.

Here is another example of an always statement with an incomplete event list that may
cause functional mismatches.

The variable Pbus is not in the event list of the always statement. However in the
synthesized netlist, any changes on Pbus will propagate into Treg if the if condition is
false. This is not consistent with the design model semantics and thus a functional
mismatch occurs.

Recommendation: For an always statement without a clock event (that is, when modeling
combinational logic), include all variables read in the always statement in the event list.

4.13 Synthesis Directives

The two synthesis directives we have seen so far, full_case and parallel_case, can
potentially cause functional mismatches to occur between the design model and the
synthesized netlist. The problem is that these directives are recognized only by a synthesis
tool and not by a simulation tool. In either of the cases, if the designer is not careful in
specifying the directive, mismatches can occur.

Here is an example of a full_case synthesis directive.

The full_case directive tells the synthesis tool that all possible values that can possibly
occur in CurrentState have been listed and the value of Next State is a don't care for all
other cases, and therefore, the synthesis tool should not generate latches for NextState.
However this may not be true in simulation. It could happen that CurrentState for some
reason, gets a value of 2'b00. In such a case, the case statement simulates as if NextState
value is saved, but in the synthesized netlist, the value of NextState may not be saved.

B.S.BALAJI, ASST. PROF, DEPT. ECE. BGSIT – ACU. 18

V SEMESTER BE(ECE) VERILOG HDL (18EC55) 2020-21
Here is an example of a parallel_case synthesis directive.

Simulation semantics of the case statement (the parallel_case directive is ignored since it
is a comment) specifies that if Gatel is a 1, then assign 1 to Mask1, else if Gate2 is a 1,
assign 1 to Mask2, else if Gate3 is a 1, assign 1 to Mask3. However, with the
parallel_case directive, instead of a priority if-structure being synthesized, a parallel
decoder is synthesized. This can cause functional mismatches to occur. What if both
Gate3 and Gatel were 1 at the same time? In the case statement, the first branch is taken,
whereas in the synthesized netlist, both branches 1 and 3 are enabled. Here is the
semantics for the case statement expressed using an if statement.

This is the semantics of the synthesized netlist.

Recommendation: Use caution when using the synthesis directives: full case and
parallel_case. Use only if really necessary.

4.14 Variable Asynchronous Preset

When synthesizing an asynchronous preset clear flip-flop, the recommendation is to
assign only constant values under the asynchronous conditions. If a variable is
asynchronously read, there is a potential for a functional mismatch to occur. Here is an
example.

B.S.BALAJI, ASST. PROF, DEPT. ECE. BGSIT – ACU. 19

V SEMESTER BE(ECE) VERILOG HDL (18EC55) 2020-21
// Synthesized netlist is shown in Figure 4-15.

Figure 4-15 Variable asynchronous preset.

Two flip-flops with asynchronous preset and clear are synthesized for the variable
QuickBus. The variable LoadData is connected to the preset clear inputs of the flip-flops
through other logic. When PreLoad is active (is 0) and LoadData changes, the outputs of
the flip-flops are immediately affected because of the asynchronous data change.
However in the design model, any change on LoadData has no effect on the output
QuickBus. Thus there is a mismatch.
Recommendation: Avoid asynchronously reading a variable and as signing it to a flip-
flop; else ensure that there are no changes on asynchronous data when the asynchronous
conditions are active.

4.15 Blocking and Non-blocking Assignments

In Chapter 2, we recommended that: blocking assignments be used for modeling
combinational logic, and non-blocking assignments be used for modeling sequential
logic; blocking assignments may be used for variables that are assigned and used, all
within an always statement.
In this section, we explain why this recommendation is important to be followed; else
there is a risk of getting functional mismatches.

4.15.1 Combinational Logic

Blocking assignments mirror the dataflow in a combinational circuit. Consider the
following always statement.

B.S.BALAJI, ASST. PROF, DEPT. ECE. BGSIT – ACU. 20

V SEMESTER BE(ECE) VERILOG HDL (18EC55) 2020-21
All the assignments are blocking assignments. Statements within the sequential block
imply to compute the value of TM first, then execute the second statement, assign to TN,
then go to third statement, assign to TO, and so on. This mimics the dataflow through the
combinational logic.

Let us now change all these to non-blocking assignments.

When the first assignment statement executes, TM does not get updated immediately but
is scheduled to be assigned at the end of the current simulation cycle. Since all statement
executions occur sequentially and in zero time, so when the third statement is executed,
the old value of TM is used to compute the value of TO (TM has not been assigned its
new value yet). Consequently, the output TZ does not reflect the and-or-invert behavior
of the logic. The problem is that TM, TN, and TO all get updated at the end of the current
simulation cycle and these updated values are not used again to reevaluate the logic.

A solution to this problem is to place variables TM, TN and TO also in the event list of
the always statement, such as:

In this case, when TM, TN or TO changes, the always statement is re evaluated and
eventually TZ does get the correct value. So there are two problems that have been
identified:

 non-blocking assignments do not show the logical flow

 need to put all targets of assignments in the event list

These problems can simply be avoided by using blocking assignments when modeling
combinational logic and are therefore recommended.

B.S.BALAJI, ASST. PROF, DEPT. ECE. BGSIT – ACU. 21

V SEMESTER BE(ECE) VERILOG HDL (18EC55) 2020-21
4.15.2 Sequential Logic
Let us first consider what happens if blocking assignments are exclusively used for
modeling sequential logic. Consider the following two always statements.

The always statement, labeled AwB, assigns a value to DataOut in a blocking

fashion and the always statement, labeled AwA, reads the value of DataOut. If these
always statements were simulated in the sequence shown (a simulator orders the always
statements to be executed in sequence based on event changes in the event list), and if
CikA had a positive edge, the always statement AwA reads the current value of DataOut
first and then the always statement AwB causes a new value to be assigned to DataOut. If
the order of the always statements were reversed (or if a simulator chooses to reorder the
execution of the always statements), execution of the always statement AwB occurs first
causing DataOut to be assigned a new value in zero time. Subsequently, the read of
DataOut in the always statement AwA uses the new updated value of DataOut. Thus it
appears that depending on the order in which the always statements are executed,
different results are obtained. The problem is really caused by the fact that when both
always statements are ready for execution, the assignment to DataOut occurs in zero time
and completes. So depending on which always statements gets executed first, the read of
DataOut in AwA will either be an old value of DataOut or a new value of DataOut.

To avoid this simulation behavior dependence, it is best to force the assignment to occur
at a later time, a time after which all reads are guaranteed to have been completed. This
can be achieved by using the non blocking assignment. In such a case, the read of
DataOut occurs at the current time, while a new value is assigned to DataOut at the end of
the current simulation step (that is, after all reads are completed). This makes the behavior
of the model insensitive to the order of the always state ments. Here are the always
statements with non-blocking assignments used.

So we see that if a variable is assigned a value in one always statement and its value read
external to that always statement, the assignment should be a non-blocking procedural
assignment.

What if the assignment and reading of a variable all occur in the same clocked always
statement? In such a case, blocking assignments may be used.

B.S.BALAJI, ASST. PROF, DEPT. ECE. BGSIT – ACU. 22

V SEMESTER BE(ECE) VERILOG HDL (18EC55) 2020-21

Total is a variable assigned and then read within the same always statement. In this case,
we would like the assignment to Total to be completed before the if condition is
evaluated. Total is a temporary; a value is assigned to it and then read. Thus a blocking
assignment is suitable for Total.

If a non-blocking assignment is used, such as:

then the value of Total when the if condition is evaluated is the old value of Total, not the
value that is scheduled to be assigned to it in the previous assignment.

Therefore, the recommendation is to use non-blocking assignments for variables that are
read outside of the always statement in which they are assigned. Additionally, for
variables that are assigned and used only within an always statement, use blocking
assignments.

B.S.BALAJI, ASST. PROF, DEPT. ECE. BGSIT – ACU. 23