Smartzworld.com Smartworld.

asia

Unit- V
SYLLABUS
Sequential Models – Feedback Model, Capacitive Model, Implicit Model, Basic Memory, Components,
Functional Register, Static Machine Coding, Sequential Synthesis, Component Test and Verification: Test
bench – Combinational Circuit Testing, Sequential Circuit, Testing, Test bench Techniques, Design
Verification, Assertion Verification.
---------------------------------------------------------------------------------------------------------------------
Sequential Models
Sequential
Models

Feedback Capacitive Implicit

Model Model Model
In digital circuits, storage of data is done either by feedback, or by gate capacitances that are refreshed
frequently. Verilog provides language constructs for building memory elements using both these schemes.
However, more abstract models also exist and are used in most sequen-tial circuit models.

Feedback Model
A -state -bit
S Memory
two (one )
element
R S Q

Q
RFeedback
Line shown in Fig. 5.1 is the most basic feedback circuit that has data storage capability.
The construct
This circuit has one feedback line that makes it a two-state (feedback 0 and feedback 1), or a 1-bit,
memory element. Many Verilog con-structs can be used for proper modeling of this circuit.

Capacitive model
Another hardware structure with storage capability is shown in Fig. 5.2. When C becomes 1 the value of D
is saved in the input gate of the inverter and when C becomes 0, this value will be saved until the next time
that c becomes 1 again. The output of the inverter is equal to the complement of the stored data.
Because of powerful switch level capabilities of Verilog, the circuit of Fig. 5.2 can be very closely
modeled in Verilog. Chapter 7 of this book discusses switch level modeling for combinational and
sequential circuits in great detail.
Implicit model
Feedback and capacitive models discussed above are technology depend-ent, and they have the problem of
being too detailed and thus too slow to simulate. Of course, where such details are needed, this level of
mod-eling is possible in Verilog.
Verilog also offers language constructs that model storage elements at more abstract levels than the
previous models. Such modelings are tech-nology independent and allow much more efficient simulation
of circuits with a large number of storage elements. Figure shows an SR-latch model without gate level
details.

63 | P a g e

jntuworldupdates.org Specworld.in
Smartzworld.com Smartworld.asia

Because gate and transistor details of models at the block diagram level are not known, Verilog provides
timing check constructs for ensuring cor-rect operation of this level of modeling. The sections that follow
present lan-guage constructs for feedback modeling of storage elements, but concentrate on the more
abstract models in which storage is implied by the Verilog code.

Basic Memory Components

This section shows modeling memory components in Verilog. We start with latches and discuss 1-bit and
multidimensional memories. In the use of Verilog constructs, we show how gates, primitives, assignments,
and procedural blocks are used for memory modeling.

Gate level primitives

Figure 5.4 shows a cross-coupled NOR structure that forms a 1-bit storage element. This circuit is no
different than that of Fig. 5.1, and its storage is due to the feedback from q back to g1.

The Verilog code of this diagram is shown in Fig. 5.5. The q and q_b out-puts are driven by two NOR
gates, and are therefore initially X. The out-puts remain at this ambiguous state for as long as s and r
remain 0. After a delay of 4 ns after s becomes 1, q becomes 1 and after another 4 ns delay, q_b becomes0.
Simultaneous assertion of both inputs results in loss ofmemory.

This memory element is the base of most static memory components. Adding control gates and a clock
input results in a clocked SR-latch. Figure 5.6 shows an all-NAND version of a clocked SR-latch.

The Verilog code that corresponds to the diagram of Fig. 5.6 is shown in Fig. 5.7. As shown, the circuit
is parameterized so that delay values can be controlled when the latch is instantiated. We have declared
64 | P a g e

jntuworldupdates.org Specworld.in
Smartzworld.com Smartworld.asia

our parameters in the module header along with module name and ports. Wire names _s and _r are used
for the set and reset inputs to the cross-coupled core of this memory element.

Behavioral memory elements

The previous sections showed Verilog models for latches and flip-flops by explicit use of feedback or
present and next states. Such a model cor-responds to the actual hardware implementing a memory
element, and has the potential of having all gate level delays specified.
A more abstract and easier way of writing Verilog code for a latch or flip-flop is by behavioral coding.
This way, the storage of data and its sensitivity to its clock and other control inputs will be implied in the
way model is written.

Flip-flop modeling. A basic edge trigger flip-flop model at thebehavioral level is shown in Fig. 5.17. This
model is sensitive to the pos-itive edge of the clock, and uses nonblocking assignments for assign-ments to
q and q_b.

Flow into the procedural block is controlled by the eventcontrol statement that hasposedge clk as its
event expression.Assignments to q and q_b are reached immediately after the flow in the always block
begins. As shown, the actual assignment of values toqandq_b are delayed by 4 and 3 ns, respectively. With
each clock edge, theentire procedural block is executed once from begin to end.
Figure 5.18 shows a partial waveform of a simulation run of our D flip-flop. At 60 ns when we have the
positive edge of the clock, the value of d is read and scheduled into q and q_b for times 64 and 63 ns,
respec-tively. The sensitivity to the positive edge of the clock in this example is illustrated by the fact that
during the time that clk is 1 (from 60 to 80 ns, exclusive of 60 ns, and inclusive of 80 ns), changes on d do
not affect the state of the flip-flop.

Flip-flop with set-reset control. The style presented ind_ff can be expanded to cover flip-flops with
synchronous and asyn-chronous set and reset control inputs. The Verilog code is a D-type flip-flop with
synchronous set and reset (s and r) inputs.

As shown in this figure, a single always statement is used for describ-ing the d_ff_sr_Synch module.
The flow into the always block is only initiated by the posedge of clk. Therefore, the if-statements with s
and r conditions are only examined after the positive edge of the clock. Thisbehavior is in accordance with
synchronicity of s and r control inputs.

The Verilog code of Fig. 5.20 is a D-type flip-flop with asynchronous set and reset inputs. Unlike the
code of Fig. 5.19, the sensitivity list of the always block in the d_ff_sr_Asynch module includes posedges
and posedge ras well as posedge clk. Inclusion of posedge sand posedge r enables flow into
thealwaysblock when clock changes to1or when s or r become active. The arrangement ofifconditions and
this sensi-tivity makes this model a positive edge trigger with asynchronous set and reset control inputs.

65 | P a g e

jntuworldupdates.org Specworld.in
Smartzworld.com Smartworld.asia

Although posedge is used for clk, s, and r, the d_ff_sr_Asynch is sen-sitive to the edge of the clock, but
to the levels of s and r. This is because the if statements examine s and r and the default else is used for
clk; being last in the condition of the if statements makes assignment of d to q sensitive to the clock edge.
Examining this description with vari-ous values of s, r, and clk proves correctness of this model.
Figure 5.21 shows output waveforms of d_ff_sr_Synch and d_ff_sr_Asynch for data applied to d, s, and r.
In the first half of thiswaveform (before 120 ns), changes to q are triggered by the clock and q_Synch and
q_Asynch are exactly the same.

Functional Registers
A register is defined as a group of flip-flops with a common clock. The term register also applies to a
group of latches, but to differentiate them we will be very precise in using the correct terminology. We
will refer to a group of latches by its size, e.g., octal latch, or nibble latch. We define a functional register
as a group of flip-flops with a common clock and with some functionality, such as counting and shifting.
Styles used for Verilog coding of functional registers are similar to those of flip-flops and registers
described in the previous section. The difference is the added arithmetic or logical functionality to the
code of functional registers.

Shift registers
Coding shift registers in Verilog is very similar to registers of the previ-ous section. The addition of shift
operations to these styles will be discussed here. Several shift register examples in this section take
advantage of shift operators and concatenation.

Basic shifter. Shown in Fig. 5.38 is a 4-bit shift register withload, reset, and shift capabilities. The l_r
input controls left or right shift-ing. In either case, the vacated bit will be filled with the contents of s_in
serial input.
Verilog code of Fig. 5.39 corresponds to this shift register. As shown, all shift register operations are
synchronized with the positive edge of the circuit clock. The active high rst input causes 4'b0000 to be
loaded into the q output. The ld input performs parallel loading of d into q. If

66 | P a g e

jntuworldupdates.org Specworld.in
Smartzworld.com Smartworld.asia

neither rst nor ld are active, l_r determines left or right shifting. Left shifting is performed by
concatenating s_in to the right of q[2:0] form-ing a 4-bit vector that is clocked into q[3:0]. Similarly, for
right shifting, a 4-bit vector is formed by concatenating s_in to the left of q[3:1]. In this case s_in goes
into q[3], and q[3], q[2], and q[1] go into q[2], q[1], and q[0], respectively, causing the right shifting of
q. All operations of this circuit are done in an always block that is sensitive to the positive edge of the
circuit clock. A nesting of if-else statements handles assignments to the q output. The lastelsecovers all
conditions not mentioned in the previ-ous if statements. This technique guarantees that all conditions are
taken care of by the if statement, and leaves no room for ambiguities.

5.3.1.2 Universal shift register. The Verilog code of auniversal shift register with bidirectional io. The
circuit has s1, s0 inputs forming a 2-bit number ranging from 3 to 0. The shifter does nothing, shifts right,
shifts left, or performs a parallel load depending on the value of {s1, s0}. The synchronous rst input resets
the shifter.
Because this circuit has a bidirectional inout port, we have declared q_int to hold the shift register
output at all times. Inside analwaysblock that is sensitive to the positive edge of the clock, assignments to
q_int take place. If rst is1, this variable is set to 0. Otherwise, acase

Basic Shifter Verilog Code

`timescale 1ns/100ps

module shift_reg (input [3:0] d, input clk, ld, rst, l_r, s_in, output reg [3:0]
q);
always @( posedge clk ) begin if( rst )
#5 q <= 4’b0000; else if( ld )
#5 q <= d; else if( l_r )
#5 q <= {q[2:0], s_in}; else
#5 q <= {s_in, q[3:1]};
End endmodule

67 | P a g e

jntuworldupdates.org Specworld.in
Smartzworld.com Smartworld.asia

Universal Shift Register

`timescale 1ns/100ps

module shift_reg (input clk, rst, r_in, l_in, en, s1, s0, inout [7:0] io);
reg [7:0] q_int;
assign io = (en) ? q_int : 8’bz; always @( posedge clk ) begin
if( rst )
#5 q_int = 8’b0; else
case ( {s1,s0} )
2’b01 : // Shift right
q_int <= { r_in, q_int[7:1] }; 2’b10 : // Shift left
q_int <= { q_int[6:0], l_in }; 2’b11 : // Parallel load
q_int = io;
default : // Do nothingq_int <= q_int;
endcase
end

endmodule

statement uses {s1, s0} to decide value assigned to q_int. The case statement uses the default alternative to
cover {s1, s0} of 2’b00 and all possible ambiguous values. This default alternative is like the else of the
previous example, which guarantees that all conditions areaccounted for.
The ionet is the bidirectional port of this shift register. When {s1, s0} is 2’b11 (parallel loading the shift-
register), io is read and put into q_int. For outputting through io, an assign statement assigns q_int or eight
Zs to this bidirectional bus. Ifenis 1 q_intis put oni0, and if it is 0,8’bZdrives io. An external device
wanting to drive io from outside of this module can only do so when en is 0.

State Machine Coding

Coding styles presented so far can further be generalized to cover finite state machines of any type. This
section shows coding for Moore and Mealy state machines. The examples we will use are simple sequence
detectors, yet they represent coding for complex control-heavy digital cir-cuits, or the controller part of an
RT level design.

Moore machines
A Moore machine is a state machine in which all outputs are fully syn-chronized with the circuit clock. In
the state diagram form, each state of the machine specifies its output(s) independent of circuit inputs. In
the Verilog code of a Moore state machine, only circuit state variables participate in the output expression
of the circuit.

A 101 Moore sequence detector with its corre-sponding block diagram related to its Verilog coding. The
machine searches for 101 on its input and when received, the output of the cir-cuit becomes 1 and remains
at this level for a complete clock period. As shown in the state diagram, when the machine reaches the
got101 state, its output becomes 1.
The block diagram of the Verilog coding that will be used for this machine is also shown An always
block that handles state transitions and clocking generates current state of the machine. This variable is
used by an assign statement that generates the z output of the circuit.
The Verilog code of moore_detector. We have used a localparam declaration to assign values to the
states of the machine.

68 | P a g e

jntuworldupdates.org Specworld.in
Smartzworld.com Smartworld.asia

Because our machine has four states, 2-bit parameters are used for the state names. Furthermore, the
declaration part of the moore_detector module declares current as a 2-bit reg. This variable is used for
hold-ing the current state of the machine.
The always block of Fig. 5.54 implements a positive edge trigger sequential block with a synchronous
reset (rst) input. If rst is active, cur-rent is set to reset, otherwise, acasestatement assigns next state
valuesto current. Next states of the machine are decided by the current state that is the case expression,
and input values.
Each state of the machine is implemented by a case alternative, and its next state transitions are
implemented by if statements conditioned by the x input of the circuit. Figure 5.55 shows a
correspondence between the got10 state of the machine and its Verilog coding. This state branches out to
got101 or reset depending on x. The output of the circuit is imple-mented by a separate assign statement
that puts a 1 on z when cur-rent is got101.
Because this is a Moore machine, the condition for asserting the output of the circuit only includes the
current variable, and circuit input(s) are not included. Figure 5.56 shows another Moore machine example.
This machine searches for 110 or 101 sequences on its x input. The search allows overlapping sequences.
The Verilog code of the Moore machine of Fig. 5.56 is shown in Fig. 5.57. We are using `define
directives for assigning values to the state names. Note that using names is only for readability purposes,
and instead of using `define or localparam, as in the previous example, state values could be used in the
case statement of this Verilog code.
The Verilog code shown here implements a state machine with asyn-chronous active high reset (rst)
input. For this purpose, posedgerst is included in the sensitivity list of the always block. In this always
block, the last case alternative is the default case that accounts.

Mealy machines
A Mealy machine is different from a Moore machine in that its output(s) depend on its current state
and inputs while in that state. State tran-sitions, clocking, and resetting the machine are not
different from those of a Moore machine, and the same coding techniques are used for describing
them.

69 | P a g e

jntuworldupdates.org Specworld.in
Smartzworld.com Smartworld.asia

a 101 Mealy sequence detector and its correspon-ding Verilog code block diagram. This circuit has a
synchronous rst input that resets the machine to its reset state.
The Verilog code of Fig. 5.59 corresponds to this Mealy machine. A 2-bit localparam construct is used
for defining the states of this machine. Because the machine has three states and two state variables are
used to represent them, one combination (i.e., 11) of the state variables becomes unused. As in the
previous example, the default in the case statement of this Verilog code handles this unspecified
combination and ambiguous values that may appear on current.
The coding of the states and output of this machine are illustrated in Fig. 5.60. Each state is specified by
a case alternative of a case state-ment for which current is its case expression. Transitions to the next
states of the machine are handled by if-else statements. The output of the machine is set to 1 using an
assign statement that uses a conditional expression on its right-hand side. This conditional expression uses
the circuit input as well as the current state of the machine.

Sequential Synthesis
The process of synthesis involves describing a hardware in an accept-able form for the synthesis tool to
recognize and then specifying a target library representing available low-power components to map to.
The target library has combinational and sequential components. Exactly how a synthesizable Verilog
input description translates to hardware depends on the specific target library. For example, if an input
descrip-tion involves a latch and the target library does not have a latch, then a latch will be build using
gates or logic functions that are available in the target library.
Verilog models described in this chapter, except those with initial statements loading a memory, are
synthesizable. In this section, we will go back and look at several typical styles of coding and discuss the
kind of hardware that they synthesize to.

Latch models
Except for the delay values, the latch Verilog description of Fig. 5.14 is synthesizable. If a target hardware
library contains a D-latch, it will be used for mapping this description, otherwise it will be built by wiring
existing target hardware parts.
an Altera field programmable gate array (FPGA) logic element that has several logic gates, a look-up
table, and a flip-flip. The implementation of a D-latch is highlighted in this diagram. The gray areas are

70 | P a g e

jntuworldupdates.org Specworld.in
Smartzworld.com Smartworld.asia

those parts of the logic element (LE) that are actually used for our latch. As shown, the latch is
implemented by programming the look-up table (the rectangular box with A, B, C, D inputs). The output
of this table is the latch output and also feeds back to the table to cause the latching action. Note in this
figure that the flip-flop (the rectangu-lar box on the right) of the FPGA logic element is not used.

Testbench
Verilog simulation environments provide tools for graphical or textual display of simulation results. Some
simulation environments go fur-ther, and provide graphical tools for editing input test data to a design
module that is being tested. Such tools are referred to as waveform edi-tors, and are usually good for small
designs. They become too complex to use for a design with many busses and control signals. Another
prob-lem with waveform editors is that each simulation environment uses a different procedure for
waveform editing, and moving from one simu-lator to another requires relearning a whole new set of
procedures.
This problem can be alleviated by use of Verilog testbenches. A Verilog testbench is a Verilog module
that instantiates an MUT, applies data to it, and monitors its output. Because a testbench is in Verilog, it
can go from one simulation environment to another. A module and its corresponding testbench form a
simulation model in which MUT is tested for the same input data regardless of what simulation
environment is used.
To facilitate development of testbenches, some simulation environ-ments provide testbench tools that
automatically generate a template testbench. Such tools also provide ways of inserting templates for gen-
eration of test data for applying them to MUT. Using templates is help-ful, but a designer must understand
testbenches and language constructs that are used for testing a design module. In the next two sub-sections
basics of testbenches are discussed.

Combinational circuit testing

Developing a testbench for a combinational circuit is straight forward, however selection of data and how
much testing should be done depends on the MUT and its functionality.
Chapter 4 presented a simple arithmetic logical unit (ALU) (Fig. 4.63) that we use here to test. Module
header and declarations of its ports are repeated in Fig. 6.1 for reference. The alu_4bit module is a four
func-tion ALU. Data inputs are a and b, and its function input is f. In addi-tion to its y data output, the
ALU generates parity (p), overflow (ov), and compare outputs.
A testbench for alu_4bit is shown in Fig. 6.2. Variables correspon-ding to inputs and outputs of the
module under test are declared in the testbench. Variables connecting to the inputs are declared as reg and
outputs as wire. Instantiation of alu_4bit shown in the testbench asso-ciates local regs and wires with the
ports of this module.
Variables that are associated with the inputs of alu_4bit have been given initial values when declared.
Application of data to the b data input and oe output-enable of ALU are done in an initial statement. For
the first 60 ns every 20 ns, a new value is assigned to b. The initial block then waits for 80 ns, disables the
ALU output by setting oe to 0, and after 20 ns it finishes the simulation. This last 20 ns wait, allows effects
of the last input change to be shown in simulation results.
Application of data to the f input of alu_4bit is done in an always state-ment. Starting with the initial
value of 0, f is increment by 1 every 23 ns.
The $finish statement in the initial block of the testbench is reached at 160 ns. At this time all active
procedural blocks stop and simulation terminates. Figure 6.3 shows simulation results of the alu_4bit
module.
Throughout the simulation a remains constant, and b changes from 6 to B and then to E at 40 ns. The f
function input changes every 23 ns causing various ALU functions to be examined. At 140 ns, oe changes
to 0, causing the y output become Z.

71 | P a g e

jntuworldupdates.org Specworld.in
Smartzworld.com Smartworld.asia

Sequential circuit testing

Testing sequential circuits involves synchronization of circuit clock with other data inputs. We use the
misr module of Chap. 5 for an example here. This circuit, repeated in Fig. 6.4 for reference, has a clock
input, a reset, data inputs, and outputs.
The circuit has a poly parameter that determines its signature and data compression. With each clock a
new signature will be calculated with the new data and existing misr register data.
Figure 6.5 show a testbench for misr. As before, variables correspon-ding to the ports of MUT are
declared in the testbench. When misr is instantiated, these variables are connected to its actual ports. Our
misr instance also includes specification of its poly parameter.
The initial block of this testbench generates a positive pulse on rst that begins at 13 ns and ends at 63
ns. The timing is so chosen to cover at least one positive clock edge, so that the synchronous rst input can
initialize the misr register. The d_in data input begins with x, and is ini-tialized to 4’b1000 while rst is 1.
In addition to the initial block, the test_misr module includes two always blocks that generate data
ond_inandclk. Clock is given a peri-odic signal that toggles every 11 ns. The misr d_in input is assigned a
new value every 37 ns. In order to reduce chance of several inputs chang-ing at the same time, we usually
use prime numbers for timing of sequential circuit inputs.

module #(parameter [3:0] poly=0) misr (input clk, rst, input [3:0] d_in, output reg
[3:0] d_out );

always @( posedge clk ) if( rst )

d_out =4’b0000;
else
d_out = d_in ^ ({4{d_out[0]}} & poly) ^ {1’b0,d_out[3:1]};

endmodule

module test_misr; reg clk=0, rst=0; reg [3:0] d_in;

wire [3:0] d_out;

misr #(4’b1100) MUT ( clk, rst, d_in, d_out );

initial begin
#13 rst=1’b1; #19 d_in=4’b1000; #31 rst=0’b0;
#330 $finish;
end

always #37 d_in = d_in + 3;

always #11 clk = ~clk;

endmodule

As shown starting at 40 ns with this and every positive edge of clk, a new signature is generated in misr.
Since prior to time 80 ns, misr is reset to0, the first signature that happens at 80 ns is the sameas d_in.

Testbench Techniques
Various Verilog coding techniques for generation of test data and observ-ing circuit responses are
discussed in this section. We use state machines of Chap. 5 for our test modules. The first example is a
101 Moore detec-tor circuit depicted
We have used a coding style that is somewhat different than that used. The z output becomes 1 in state d
when a sequence of 101 is detected onx. The circuit has a synchronous reset input.

72 | P a g e

jntuworldupdates.org Specworld.in
Smartzworld.com Smartworld.asia

Test data
A testbench for moore_detector. As before, our testbench is a module with no ports. Within this module,
four pro-cedural blocks provide data for testing the state machine. Variables connected to inputs of MUT
and used on the left-hand sides in the pro-cedural blocks are declared as reg. Instead of initializing reg
variables when they are declared, we have used an initial block for this purpose. It is important to
initialize vari-ables, like clock, for which their old values are used for determining their new values. If not
done so, clock would start with value X and comple-menting it would never change its value. The always
block shown gen-erates a periodic signal with a period of 10 ns on clock.
Following the always block producing clock, another always block generates a periodic signal on x with
a period of 14 ns. The waveform generated on x may or may not be able to test our machine for a correct
101 sequence. However, periods ofclockandxcan be changed to makethis happen. With the timing used
here, the moore_detector output becomes 1 at 55 ns, and every 70 ns from then on.

Design Verification
The previous section discussed test techniques for testing a Verilog design. We presented several methods
of test data generation and test application, and suggested ways of observing and inspecting test results.
Stimuli generation and response analysis require significant efforts on the part of a hardware designer.
Learning correct test techniques is good, but automation of either of these procedures will be very useful
for a design engineer.
Formal verification is a way of automating design verification by elim-inating testbenches and problems
associated with their data generation and response observation. In formal verification, a designer writes
prop-erties to check his or her design. Formal verification tools do not per-form simulation, but come up
with a Yes/No answer for every property the design is being checked for. Although this method of design
verifica-tion helps discover many design errors, most designs still need testbench

development and simulation for validating that their Verilog code indeed functions as expected. In other
words, an all ―Yes‖ answers to design properties checked by formal verification tools is still not enough.
Instead of eliminating data generation and response observation (like the formal verification tools), a
step in the direction of automating design validation is to reduce or eliminate efforts needed for analyzing
output responses. For this purpose assertion verification is used. Assertion ver-ification adds monitors to a
design to improve its observability. While the design is being simulated with its testbench data, assertion
moni-tors that represent certain design properties continuously check for cor-rect design behavior by
validating these properties. If the simulation data leads into conditions that indicate to an assertion monitor
that the design is misbehaving, the monitor is said to fire to alert the designer of the problem.
As mentioned, we still need to develop a testbench and careful plan-ning of test inputs for the design
being tested is needed in assertion ver-ification. But, in many cases, assertions automatically check to
make sure events that occur in the design are as expected. This significantly reduces the need for
processing long output lists or waveforms.

Assertion Verification
Unlike simulation that a testbench or a human has to interpret the results, in assertion verification, in-code
monitors take the responsibil-ity of issuing a message if something happens that is not expected. In
Verilog, these monitors are modules, and they are instantiated in a design to check for certain design
properties. Instantiating an assertion module is not to be regarded as instantiation of a hardware module.
Instead, this kind of instantiation is more like an always-active proce-dure that continuously checks for
events in the design module.
The present set of assertion monitors are available in a library that is referred to as open verification
library (OVL). Designers can develop their own set of assertions, and use them in their designs. The
existing monitors check for values of signals, relation of several signals with each other, sequence of
73 | P a g e

jntuworldupdates.org Specworld.in
Smartzworld.com Smartworld.asia

events, and expected patterns on vectors or groups of signals. For using assertions, a designer compiles
OVL and his or her own assertion library into a simulation library and makes this library available to
designs being verified. When a design is developed, assertions are placed at key points in the design to
check for key func-tionalities. When the design is being simulated as a stand-alone com-ponent, or in a
hierarchy of a larger design, the monitors check signals for their expected values. If a signal does not have
a value expected by a monitor, the assertion monitor displays a message and the time that the discrepancy
(violation of the property) has occurred. Usually, such messages appear in the simulation report area,
transcript, or console.

Assertion verification benefits

Ways in which placement of assertion monitors in a design are helpful are discussed here.
Designer discipline. When a designer places an assertion in a design,he or she is disciplining
him/herself to look into the design more care-fully and extract properties.
Observability. Assertions add monitoring points to a design that makeit more observable.
Formal verification ready. Assertions correspond to properties that areused in formal verification
tools. Having inserted assertion monitors to a design, readies it for verification by a formal verification
tool.
Executable comments. Assertion monitors can be regarded as commentsthat explain some features or
behavior of a design. These comments pro-duce messages when the behavior they are explaining is
violated.
Self-contained designs. A design with assertion monitors has the designdescription and its test
procedure all in one Verilog module.

74 | P a g e

jntuworldupdates.org Specworld.in