You Could Download File D - FF.V

Introduction
Verilog is a HARDWARE DESCRIPTION LANGUAGE (HDL). A hardware

description language is a language used to describe a digital system: for example, a
network switch, a microprocessor or a memory or a simple flip-flop. This just means that,
by using a HDL, one can describe any (digital) hardware at any level.
1 // D flip-flop Code
2 module d_ff ( d, clk, q, q_bar);
3 input d ,clk;
4 output q, q_bar;
5 wire d ,clk;
6 reg q, q_bar;
7
8 always @ (posedge clk)
9 begin
10 q <= d;
11 q_bar <= ! d;
12 end
13
14 endmodule
You could download file d_ff.v here
One can describe a simple Flip flop as that in the above figure, as well as a complicated
design having 1 million gates. Verilog is one of the HDL languages available in the
industry for hardware designing. It allows us to design a Digital design at Behavior
Level, Register Transfer Level (RTL), Gate level and at switch level. Verilog allows
hardware designers to express their designs with behavioral constructs, deferring the
details of implementation to a later stage in the final design.
Many engineers who want to learn this language, very often ask this question, how much
time will it take to learn Verilog? Well my answer to them is "It may take no more than
one week, if you happen to know at least one programming language".
Design Styles
Verilog, like any other hardware description language, permits a design in either Bottom-
up or Top-down methodology.
Bottom-Up Design
The traditional method of electronic design is bottom-up. Each design is performed at the
gate-level using the standard gates (refer to the Digital Section for more details). With the
increasing complexity of new designs this approach is nearly impossible to maintain.
New systems consist of ASIC or microprocessors with a complexity of thousands of
transistors. These traditional bottom-up designs have to give way to new structural,
hierarchical design methods. Without these new practices it would be impossible to
handle the new complexity.
Top-Down Design
The desired design-style of all designers is the top-down one. A real top-down design
allows early testing, easy change of different technologies, a structured system design and
offers many other advantages. But it is very difficult to follow a pure top-down design.
Due to this fact most designs are a mix of both methods, implementing some key
elements of both design styles.
Figure shows a Top-Down design approach.
Verilog Abstraction Levels
Verilog supports designing at many different levels of abstraction. Three of them are very
important:
• Behavioral level
• Register-Transfer Level
• Gate Level
Behavioral level
This level describes a system by concurrent algorithms (Behavioral). Each algorithm

itself is sequential, that means it consists of a set of instructions that are executed one
after the other. Functions, Tasks and Always blocks are the main elements. There is no
regard to the structural realization of the design.
Register-Transfer Level
Designs using the Register-Transfer Level specify the characteristics of a circuit by

operations and the transfer of data between the registers. An explicit clock is used. RTL
design contains exact timing bounds: operations are scheduled to occur at certain times.
Modern RTL code definition is "Any code that is synthesizable is called RTL code".
Gate Level
Within the logic level the characteristics of a system are described by logical links and
their timing properties. All signals are discrete signals. They can only have definite
logical values (`0', `1', `X', `Z`). The usable operations are predefined logic primitives
(AND, OR, NOT etc gates). Using gate level modeling might not be a good idea for any
level of logic design. Gate level code is generated by tools like synthesis tools and this
netlist is used for gate level simulation and for backend.
Introduction
Every new learner's dream is to understand Verilog in one day, at least enough to use it.
The next few pages are my attempt to make this dream a reality. There will be some
theory and examples followed by some exercises. This tutorial will not teach you how to
program; it is designed for those with some programming experience. Even though
Verilog executes different code blocks concurrently as opposed to the sequential
execution of most programming languages, there are still many parallels. Some
background in digital design is also helpful.
Life before Verilog was a life full of schematics. Every design, regardless of complexity,
was designed through schematics. They were difficult to verify and error-prone, resulting
in long, tedious development cycles of design, verification... design, verification... design,
verification...
When Verilog arrived, we suddenly had a different way of thinking about logic circuits.
The Verilog design cycle is more like a traditional programming one, and it is what this
tutorial will walk you through. Here's how it goes:
• Specifications (specs)
• High level design
• Low level (micro) design
• RTL coding
• Verification
• Synthesis.
First on the list is specifications - what are the restrictions and requirements we will
place on our design? What are we trying to build? For this tutorial, we'll be building a
two agent arbiter: a device that selects among two agents competing for mastership. Here
are some specs we might write up.
• Two agent arbiter.
• Active high asynchronous reset.
• Fixed priority, with agent 0 having priority over agent 1
• Grant will be asserted as long as request is asserted.
Once we have the specs, we can draw the block diagram, which is basically an
abstraction of the data flow through a system (what goes into or comes out of the black
boxes?). Since the example that we have taken is a simple one, we can have a block
diagram as shown below. We don't worry about what's inside the magical black boxes
just yet.
Block diagram of arbiter
Now, if we were designing this machine without Verilog, the standard procedure would
dictate that we draw a state machine. From there, we'd make a truth table with state
transitions for each flip-flop. And after that we'd draw Karnaugh maps, and from K-maps
we could get the optimized circuit. This method works just fine for small designs, but
with large designs this flow becomes complicated and error prone. This is where Verilog
comes in and shows us another way.
Low level design
To see how Verilog helps us design our arbiter, let's go on to our state machine - now
we're getting into the low-level design and peeling away the cover of the previous
diagram's black box to see how our inputs affect the machine.
Each of the circles represents a state that the machine can be in. Each state corresponds
to an output. The arrows between the states are state transitions, labeled by the event that
causes the transition. For instance, the leftmost orange arrow means that if the machine is
in state GNT0 (outputting the signal that corresponds to GNT0) and receives an input of !
req_0, the machine moves to state IDLE and outputs the signal that corresponds to that.
This state machine describes all the logic of the system that you'll need. The next step is
to put it all in Verilog.
Modules
We'll need to backtrack a bit to do this. If you look at the arbiter block in the first picture,
we can see that it has got a name ("arbiter") and input/output ports (req_0, req_1, gnt_0,
and gnt_1).
Since Verilog is a HDL (hardware description language - one used for the conceptual
design of integrated circuits), it also needs to have these things. In Verilog, we call our
"black boxes" module. This is a reserved word within the program used to refer to things
with inputs, outputs, and internal logic workings; they're the rough equivalents of
functions with returns in other programming languages.
Code of module "arbiter"
If you look closely at the arbiter block we see that there are arrow marks, (incoming for
inputs and outgoing for outputs). In Verilog, after we have declared the module name and
port names, we can define the direction of each port. (version note: In Verilog 2001 we
can define ports and port directions at the same time) The code for this is shown below.
1 module arbiter (
2 // Two slashes make a comment line.
3 clock , // clock
4 reset , // Active high, syn reset
5 req_0 , // Request 0
6 req_1 , // Request 1
7 gnt_0 , // Grant 0
8 gnt_1 // Grant 1
9 );
10 //-------------Input Ports-----------------------------
11 // Note : all commands are semicolon-delimited
12 input clock ;
13 input reset ;
14 input req_0 ;
15 input req_1 ;
16 //-------------Output Ports----------------------------
17 output gnt_0 ;
18 output gnt_1 ;
You could download file one_day1.v here
Here we have only two types of ports, input and output. In real life, we can have bi-
directional ports as well. Verilog allows us to define bi-directional ports as "inout."
Bi-Directional Ports Example -
inout read_enable; // port named read_enable is bi-directional
How do you define vector signals (signals composed of sequences of more than one bit)?
Verilog provides a simple way to define these as well.
Vector Signals Example -
inout [7:0] address; //port "address" is bidirectional
Note the [7:0] means we're using the little-endian convention - you start with 0 at the
rightmost bit to begin the vector, then move to the left. If we had done [0:7], we would be
using the big-endian convention and moving from left to right. Endianness is a purely
arbitrary way of deciding which way your data will "read," but does differ between
systems, so using the right endianness consistently is important. As an analogy, think of
some languages (English) that are written left-to-right (big-endian) versus others (Arabic)
written right-to-left (little-endian). Knowing which way the language flows is crucial to
being able to read it, but the direction of flow itself was arbitrarily set years back.
Summary
• We learnt how a block/module is defined in Verilog.
• We learnt how to define ports and port directions.
• We learnt how to declare vector/scalar ports.
Data Type
What do data types have to do with hardware? Nothing, actually. People just wanted to
write one more language that had data types in it. It's completely gratuitous; there's no
point.
But wait... hardware does have two kinds of drivers.
(Drivers? What are those?)
A driver is a data type which can drive a load. Basically, in a physical circuit, a driver
would be anything that electrons can move through/into.
• Driver that can store a value (example: flip-flop).

• Driver that can not store value, but connects two points (example: wire).
The first type of driver is called a reg in Verilog (short for "register"). The second data
type is called a wire (for... well, "wire"). You can refer to tidbits section to understand it
better.
There are lots of other data types - for instance, registers can be signed, unsigned, floating
point... as a newbie, don't worry about them right now.
Examples :
wire and_gate_output; // "and_gate_output" is a wire that only outputs
reg d_flip_flop_output; // "d_flip_flop_output" is a register; it stores and outputs a value
reg [7:0] address_bus; // "address_bus" is a little-endian 8-bit register
Summary
• Wire data type is used for connecting two points.

• Reg data type is used for storing values.
• May god bless the rest of data types. You'll see them someday.
Operators
Operators, thankfully, are the same things here as they are in other programming
languages. They take two values and compare (or otherwise operate on) them to yield a
third result - common examples are addition, equals, logical-and... To make life easier for
us, nearly all operators (at least the ones in the list below) are exactly the same as their
counterparts in the C programming language.
Operator Type Operator Symbol Operation Performed
Arithmetic * Multiply
/ Division
+ Add
- Subtract
% Modulus
+ Unary plus
- Unary minus
Logical ! Logical negation
&& Logical and
|| Logical or
Relational > Greater than
< Less than
>= Greater than or equal
<= Less than or equal
Equality == Equality
!= inequality
Reduction ~ Bitwise negation
~& nand
| or
~| nor
^ xor
^~ xnor
~^ xnor
Shift >> Right shift
<< Left shift
Concatenation {} Concatenation
Conditional ? conditional
Example -
• a = b + c ; // That was very easy

• a = 1 << 5; // Hum let me think, ok shift '1' left by 5 positions.
• a = !b ; // Well does it invert b???
• a = ~b ; // How many times do you want to assign to 'a', it could cause multiple-
drivers.
Summary
• Let's attend the C language training again, they're (almost) just like the C ones.
History Of Verilog
Verilog was started initially as a proprietary hardware modeling language by Gateway

Design Automation Inc. around 1984. It is rumored that the original language was
designed by taking features from the most popular HDL language of the time, called
HiLo, as well as from traditional computer languages such as C. At that time, Verilog
was not standardized and the language modified itself in almost all the revisions that
came out within 1984 to 1990.
Verilog simulator was first used beginning in 1985 and was extended substantially
through 1987. The implementation was the Verilog simulator sold by Gateway. The first
major extension was Verilog-XL, which added a few features and implemented the
infamous "XL algorithm" which was a very efficient method for doing gate-level
simulation.
The time was late 1990. Cadence Design System, whose primary product at that time
included Thin film process simulator, decided to acquire Gateway Automation System.
Along with other Gateway products, Cadence now became the owner of the Verilog
language, and continued to market Verilog as both a language and a simulator. At the
same time, Synopsys was marketing the top-down design methodology, using Verilog.
This was a powerful combination.
In 1990, Cadence recognized that if Verilog remained a closed language, the pressures of
standardization would eventually cause the industry to shift to VHDL. Consequently,
Cadence organized the Open Verilog International (OVI), and in 1991 gave it the
documentation for the Verilog Hardware Description Language. This was the event
which "opened" the language.
OVI did a considerable amount of work to improve the Language Reference Manual
(LRM), clarifying things and making the language specification as vendor-independent as
possible.
Soon it was realized that if there were too many companies in the market for Verilog,
potentially everybody would like to do what Gateway had done so far - changing the
language for their own benefit. This would defeat the main purpose of releasing the
language to public domain. As a result in 1994, the IEEE 1364 working group was
formed to turn the OVI LRM into an IEEE standard. This effort was concluded with a
successful ballot in 1995, and Verilog became an IEEE standard in December 1995.
When Cadence gave OVI the LRM, several companies began working on Verilog
simulators. In 1992, the first of these were announced, and by 1993 there were several
Verilog simulators available from companies other than Cadence. The most successful of
these was VCS, the Verilog Compiled Simulator, from Chronologic Simulation. This was
a true compiler as opposed to an interpreter, which is what Verilog-XL was. As a result,
compile time was substantial, but simulation execution speed was much faster.
In the meantime, the popularity of Verilog and PLI was rising exponentially. Verilog as a
HDL found more admirers than well-formed and federally funded VHDL. It was only a
matter of time before people in OVI realized the need of a more universally accepted
standard. Accordingly, the board of directors of OVI requested IEEE to form a working
committee for establishing Verilog as an IEEE standard. The working committee 1364
was formed in mid 1993 and on October 14, 1993, it had its first meeting.
The standard, which combined both the Verilog language syntax and the PLI in a single
volume, was passed in May 1995 and now known as IEEE Std. 1364-1995.
After many years, new features have been added to Verilog, and the new version is called
Verilog 2001. This version seems to have fixed a lot of problems that Verilog 1995 had.
This version is called 1364-2001.
Introduction
Being new to Verilog you might want to try some examples and try designing something
new. I have listed the tool flow that could be used to achieve this. I have personally tried
this flow and found this to be working just fine for me. Here I have taken only the front
end design part and bits of FPGA design of the tool flow, that can be done without any
fat money spent on tools.
Various stages of ASIC/FPGA
• Specification : Word processor like Word, Kwriter, AbiWord, Open Office.

• High Level Design : Word processor like Word, Kwriter, AbiWord, for drawing
waveform use tools like waveformer or testbencher or Word, Open Office.
• Micro Design/Low level design: Word processor like Word, Kwriter, AbiWord,
for drawing waveform use tools like waveformer or testbencher or Word.
• RTL Coding : Vim, Emacs, conTEXT, HDL TurboWriter
• Simulation : Modelsim, VCS, Verilog-XL, Veriwell, Finsim, Icarus.
• Synthesis : Design Compiler, FPGA Compiler, Synplify, Leonardo Spectrum.
You can download this from FPGA vendors like Altera and Xilinx for free.
• Place & Route : For FPGA use FPGA' vendors P&R tool. ASIC tools require
expensive P&R tools like Apollo. Students can use LASI, Magic.
• Post Si Validation : For ASIC and FPGA, the chip needs to be tested in real
environment. Board design, device drivers needs to be in place.
Figure : Typical Design flow
Specification
This is the stage at which we define what are the important parameters of the
system/design that you are planning to design. A simple example would be: I want to
design a counter; it should be 4 bit wide, should have synchronous reset, with active high
enable; when reset is active, counter output should go to "0".
High Level Design
This is the stage at which you define various blocks in the design and how they
communicate. Let's assume that we need to design a microprocessor: high level design
means splitting the design into blocks based on their function; in our case the blocks are
registers, ALU, Instruction Decode, Memory Interface, etc.
Figure : I8155 High Level Block Diagram
Micro Design/Low level design
Low level design or Micro design is the phase in which the designer describes how each
block is implemented. It contains details of State machines, counters, Mux, decoders,
internal registers. It is always a good idea to draw waveforms at various interfaces. This
is the phase where one spends lot of time.
Figure : Sample Low level design
RTL Coding
In RTL coding, Micro design is converted into Verilog/VHDL code, using synthesizable
constructs of the language. Normally we like to lint the code, before starting verification
or synthesis.
1 module addbit (
2 a , // first input
3 b , // Second input
4 ci , // Carry input
5 sum , // sum output
6 co // carry output
7 );
8 //Input declaration
9 input a;
10 input b;
11 input ci;
12 //Ouput declaration
13 output sum;
14 output co;
15 //Port Data types
16 wire a;
17 wire b;
18 wire ci;
19 wire sum;
20 wire co;
21 //Code starts here
22 assign {co,sum} = a + b + ci;
23
24 endmodule // End of Module addbit
You could download file addbit.v here
Simulation
Simulation is the process of verifying the functional characteristics of models at any level
of abstraction. We use simulators to simulate the Hardware models. To test if the RTL
code meets the functional requirements of the specification, we must see if all the RTL
blocks are functionally correct. To achieve this we need to write a testbench, which
generates clk, reset and the required test vectors. A sample testbench for a counter is
shown below. Normally we spend 60-70% of time in design verification.
Figure : Sample Testbench Env
We use the waveform output from the simulator to see if the DUT (Device Under Test) is
functionally correct. Most of the simulators come with a waveform viewer. As design
becomes complex, we write self checking testbench, where testbench applies the test
vector, then compares the output of DUT with expected values.
There is another kind of simulation, called timing simulation, which is done after
synthesis or after P&R (Place and Route). Here we include the gate delays and wire
delays and see if DUT works at rated clock speed. This is also called as SDF simulation
or gate level simulation.
Figure : 4 bit Up Counter Waveform
Synthesis
Synthesis is the process in which synthesis tools like design compiler or Synplify take
RTL in Verilog or VHDL, target technology, and constrains as input and maps the RTL
to target technology primitives. Synthesis tool, after mapping the RTL to gates, also do
the minimal amount of timing analysis to see if the mapped design is meeting the timing
requirements. (Important thing to note is, synthesis tools are not aware of wire delays,
they only know of gate delays). After the synthesis there are a couple of things that are
normally done before passing the netlist to backend (Place and Route)
• Formal Verification : Check if the RTL to gate mapping is correct.

• Scan insertion : Insert the scan chain in the case of ASIC.
Figure : Synthesis Flow
Place & Route
The gatelevel netlist from the synthesis tool is taken and imported into place and route
tool in Verilog netlist format. All the gates and flip-flops are placed; clock tree synthesis
and reset is routed. After this each block is routed. The P&R tool output is a GDS file,
used by foundry for fabricating the ASIC. Backend team normally dumps out SPEF
(standard parasitic exchange format) /RSPF (reduced parasitic exchange format)/DSPF
(detailed parasitic exchange format) from layout tools like ASTRO to the frontend team,
who then use the read_parasitic command in tools like Prime Time to write out SDF
(standard delay format) for gate level simulation purposes.
Figure : Sample micro-processor placement
Figure : J-K Flip-Flop
Post Silicon Validation
Once the chip (silicon) is back from fab, it needs to be put in a real environment and
tested before it can be released into Market. Since the simulation speed (number of clocks
per second) with RTL is very slow, there is always the possibility to find a bug in Post
silicon validation.
Introduction
If you refer to any book on programming languages, it starts with an "Hello World"
program; once you have written it, you can be sure that you can do something in that
language .
Well I am also going to show how to write a "hello world" program, followed by a
"counter" design, in Verilog.
Hello World Program
1 //-----------------------------------------------------
2 // This is my first Verilog Program
3 // Design Name : hello_world
4 // File Name : hello_world.v
5 // Function : This program will print 'hello world'
6 // Coder : Deepak
7 //-----------------------------------------------------
8 module hello_world ;
9
10 initial begin
11 $display ("Hello World by Deepak");
12 #10 $finish;
13 end
14
15 endmodule // End of Module hello_world
You could download file hello_world.v here
Words in green are comments, blue are reserved words. Any program in Verilog starts
with reserved word 'module' <module_name>. In the above example line 8 contains
module hello_world. (Note: We can have compiler pre-processor statements like
ìnclude', `define' before module declaration)
Line 10 contains the initial block: this block gets executed only once after the simulation
starts, at time=0 (0ns). This block contains two statements which are enclosed within
begin, at line 10, and end, at line 13. In Verilog, if you have multiple lines within a block,
you need to use begin and end. Module ends with 'endmodule' reserved word, in this case
at line 15.
Hello World Program Output
Hello World by Deepak
Counter Design Block
Counter Design Specs
• 4-bit synchronous up counter.

• active high, synchronous reset.
• Active high enable.
Counter Design
1 //-----------------------------------------------------
2 // This is my second Verilog Design
3 // Design Name : first_counter
4 // File Name : first_counter.v
5 // Function : This is a 4 bit up-counter with
6 // Synchronous active high reset and
7 // with active high enable signal
8 //-----------------------------------------------------
9 module first_counter (
10 clock , // Clock input of the design
11 reset , // active high, synchronous Reset input
12 enable , // Active high enable signal for counter
13 counter_out // 4 bit vector output of the counter
14 ); // End of port list
15 //-------------Input Ports-----------------------------
16 input clock ;
17 input reset ;
18 input enable ;
19 //-------------Output Ports----------------------------
20 output [3:0] counter_out ;
21 //-------------Input ports Data Type-------------------
22 // By rule all the input ports should be wires
23 wire clock ;
24 wire reset ;
25 wire enable ;
26 //-------------Output Ports Data Type------------------
27 // Output port can be a storage element (reg) or a wire
28 reg [3:0] counter_out ;
29
30 //------------Code Starts Here-------------------------
31 // Since this counter is a positive edge trigged one,
32 // We trigger the below block with respect to positive
33 // edge of the clock.
34 always @ (posedge clock)
35 begin : COUNTER // Block Name
36 // At every rising edge of clock we check if reset is active
37 // If active, we load the counter output with 4'b0000
38 if (reset == 1'b1) begin
39 counter_out <= #1 4'b0000;
40 end
41 // If enable is active, then we increment the counter
42 else if (enable == 1'b1) begin
43 counter_out <= #1 counter_out + 1;
44 end
45 end // End of Block COUNTER
46
47 endmodule // End of Module counter
You could download file first_counter.v here
Counter Test Bench

Any digital circuit, no matter how complex, needs to be tested. For the counter logic, we
need to provide clock and reset logic. Once the counter is out of reset, we toggle the
enable input to the counter, and check the waveform to see if the counter is counting
correctly. This is done in Verilog.
The counter testbench consists of clock generator, reset control, enable control and
monitor/checker logic. Below is the simple code of testbench without the
monitor/checker logic.
1 ìnclude "first_counter.v"
2 module first_counter_tb();
3 // Declare inputs as regs and outputs as wires
4 reg clock, reset, enable;
5 wire [3:0] counter_out;
6
7 // Initialize all variables
8 initial begin
9 $display ("time\t clk reset enable counter");
10 $monitor ("%g\t %b %b %b %b",
11 $time, clock, reset, enable, counter_out);
12 clock = 1; // initial value of clock
13 reset = 0; // initial value of reset
14 enable = 0; // initial value of enable
15 #5 reset = 1; // Assert the reset
16 #10 reset = 0; // De-assert the reset
17 #10 enable = 1; // Assert enable
18 #100 enable = 0; // De-assert enable
19 #5 $finish; // Terminate simulation
20 end
21
22 // Clock generator
23 always begin
24 #5 clock = ~clock; // Toggle clock every 5 ticks
25 end
26
27 // Connect DUT to test bench
28 first_counter U_counter (
29 clock,
30 reset,
31 enable,
32 counter_out
33 );
34
35 endmodule
You could download file first_counter_tb.v here
time clk reset enable counter

0 1 0 0 xxxx
5 0 1 0 xxxx
10 1 1 0 xxxx
11 1 1 0 0000
15 0 0 0 0000
20 1 0 0 0000
25 0 0 1 0000
30 1 0 1 0000
31 1 0 1 0001
35 0 0 1 0001
40 1 0 1 0001
41 1 0 1 0010
45 0 0 1 0010
50 1 0 1 0010
51 1 0 1 0011
55 0 0 1 0011
60 1 0 1 0011
61 1 0 1 0100
65 0 0 1 0100
70 1 0 1 0100
71 1 0 1 0101
75 0 0 1 0101
80 1 0 1 0101
81 1 0 1 0110
85 0 0 1 0110
90 1 0 1 0110
91 1 0 1 0111
95 0 0 1 0111
100 1 0 1 0111
101 1 0 1 1000
105 0 0 1 1000
110 1 0 1 1000
111 1 0 1 1001
115 0 0 1 1001
120 1 0 1 1001
121 1 0 1 1010
125 0 0 0 1010
Counter Waveform
Lexical Conventions
The basic lexical conventions used by Verilog HDL are similar to those in the C
programming language. Verilog HDL is a case-sensitive language. All keywords are in
lowercase.
White Space
White space can contain the characters for blanks, tabs, newlines, and form feeds. These
characters are ignored except when they serve to separate other tokens. However, blanks
and tabs are significant in strings.
White space characters are :
• Blank spaces
• Tabs
• Carriage returns
• New-line
• Form-feeds
Examples of White Spaces
Functional Equivalent Code
Bad Code : Never write code like this.
1 module addbit(a,b,ci,sum,co);
2 input a,b,ci;output sum co;
3 wire a,b,ci,sum,co;endmodule
You could download file bad_code.v here
Good Code : Nice way to write code.
1 module addbit (
2 a,
3 b,
4 ci,
5 sum,
6 co);
7 input a;
8 input b;
9 input ci;
10 output sum;
11 output co;
12 wire a;
13 wire b;
14 wire ci;
15 wire sum;
16 wire co;
17
18 endmodule
You could download file good_code.v here
Comments
There are two forms to introduce comments.
• Single line comments begin with the token // and end with a carriage return
• Multi line comments begin with the token /* and end with the token */
Examples of Comments
1 /* This is a
2 Multi line comment
3 example */
4 module addbit (
5 a,
6 b,
7 ci,
8 sum,
9 co);
10
11 // Input Ports Single line comment
12 input a;
13 input b;
14 input ci;
15 // Output ports
16 output sum;
17 output co;
18 // Data Types
19 wire a;
20 wire b;
21 wire ci;
22 wire sum;
23 wire co;
24
25 endmodule
You could download file comment.v here
Case Sensitivity
Verilog HDL is case sensitive
• Lower case letters are unique from upper case letters

• All Verilog keywords are lower case
Examples of Unique names
1 input // a Verilog Keyword

2 wire // a Verilog Keyword
3 WIRE // a unique name ( not a keyword)
4 Wire // a unique name (not a keyword)
You could download file unique_names.v here
NOTE : Never use Verilog keywords as unique names, even if the case is different.
Identifiers
Identifiers are names used to give an object, such as a register or a function or a module,
a name so that it can be referenced from other places in a description.
• Identifiers must begin with an alphabetic character or the underscore character (a-
z A-Z _ )
• Identifiers may contain alphabetic characters, numeric characters, the underscore,
and the dollar sign (a-z A-Z 0-9 _ $ )
• Identifiers can be up to 1024 characters long.
Examples of legal identifiers
data_input mu
clk_input my$clk
i386 A
Escaped Identifiers
Verilog HDL allows any character to be used in an identifier by escaping the identifier.
Escaped identifiers provide a means of including any of the printable ASCII characters in
an identifier (the decimal values 33 through 126, or 21 through 7E in hexadecimal).
• Escaped identifiers begin with the back slash ( \ )

• Entire identifier is escaped by the back slash.
• Escaped identifier is terminated by white space (Characters such as commas,
parentheses, and semicolons become part of the escaped identifier unless
preceded by a white space)
• Terminate escaped identifiers with white space, otherwise characters that should
follow the identifier are considered as part of it.
Examples of escape identifiers

Verilog does not allow to identifier to start with a numeric character. So if you really
want to use a identifier to start with a numeric value then use a escape character as shown
below.
1 // There must be white space after the

2 // string which uses escape character
3 module \1dff (
4 q, // Q output
5 \q~ , // Q_out output
6 d, // D input
7 cl$k, // CLOCK input
8 \reset* // Reset input
9 );
10
11 input d, cl$k, \reset* ;
12 output q, \q~ ;
13
14 endmodule
You could download file escape_id.v here
Numbers in Verilog
You can specify constant numbers in decimal, hexadecimal, octal, or binary format.
Negative numbers are represented in 2's complement form. When used in a number, the
question mark (?) character is the Verilog alternative for the z character. The underscore
character (_) is legal anywhere in a number except as the first character, where it is
ignored.
Integer Numbers
Verilog HDL allows integer numbers to be specified as
• Sized or unsized numbers (Unsized size is 32 bits)

• In a radix of binary, octal, decimal, or hexadecimal
• Radix and hex digits (a,b,c,d,e,f) are case insensitive
• Spaces are allowed between the size, radix and value
Syntax: <size>'<radix><value>;
Example of Integer Numbers
Integer Stored as
1 00000000000000000000000000000001
8'hAA 10101010
6'b10_0011 100011
'hF 00000000000000000000000000001111
Verilog expands <value> filling the specified <size> by working from right-to-left
• When <size> is smaller than <value>, then leftmost bits of <value> are truncated
• When <size> is larger than <value>, then leftmost bits are filled, based on the
value of the leftmost bit in <value>.
o Leftmost '0' or '1' are filled with '0'
o Leftmost 'Z' are filled with 'Z'
o Leftmost 'X' are filled with 'X'
Note : X Stands for unknown and Z stands for high impedance, 1 for logic high or 1 and
0 for logic low or 0.
Example of Integer Numbers
Integer Stored as
6'hCA 001010
6'hA 001010
16'bZ ZZZZZZZZZZZZZZZZ
8'bx xxxxxxxx
Real Numbers
• Verilog supports real constants and variables

• Verilog converts real numbers to integers by rounding
• Real Numbers can not contain 'Z' and 'X'
• Real numbers may be specified in either decimal or scientific notation
• < value >.< value >
• < mantissa >E< exponent >
• Real numbers are rounded off to the nearest integer when assigning to an integer.
Example of Real Numbers
Real Number Decimal notation

1.2 1.2
0.6 0.6
3.5E6 3,500000.0
Signed and Unsigned Numbers
Verilog Supports both types of numbers, but with certain restrictions. Like in C language
we don't have int and unint types to say if a number is signed integer or unsigned integer.
Any number that does not have negative sign prefix is a positive number. Or indirect way
would be "Unsigned".
Negative numbers can be specified by putting a minus sign before the size for a constant
number, thus they become signed numbers. Verilog internally represents negative
numbers in 2's complement format. An optional signed specifier can be added for signed
arithmetic.
Examples
Number Description
32'hDEAD_BEEF Unsigned or signed positive number
-14'h1234 Signed negative number
The example file below shows how Verilog treats signed and unsigned numbers.
1 module signed_number;
2
3 reg [31:0] a;
4
5 initial begin
6 a = 14'h1234;
7 $display ("Current Value of a = %h", a);
8 a = -14'h1234;
10 a = 32'hDEAD_BEEF;
12 a = -32'hDEAD_BEEF;
14 #10 $finish;
15 end
16
17 endmodule
You could download file signed_number.v here
Current Value of a = 00001234
Current Value of a = ffffedcc
Current Value of a = deadbeef
Current Value of a = 21524111
Introduction
Verilog has built in primitives like gates, transmission gates, and switches. These are
rarely used in design (RTL Coding), but are used in post synthesis world for modeling the
ASIC/FPGA cells; these cells are then used for gate level simulation, or what is called as
SDF simulation. Also the output netlist format from the synthesis tool, which is imported
into the place and route tool, is also in Verilog gate level primitives.
Note : RTL engineers still may use gate level primitivies or ASIC library cells in RTL
when using IO CELLS, Cross domain synch cells.
Gate Primitives
The gates have one scalar output and multiple scalar inputs. The 1st terminal in the list of
gate terminals is an output and the other terminals are inputs.
Gate Description
and N-input AND gate
nand N-input NAND gate
or N-input OR gate
nor N-input NOR gate
xor N-input XOR gate
xnor N-input XNOR gate
Examples
1 module gates();
2
3 wire out0;
4 wire out1;
5 wire out2;
6 reg in1,in2,in3,in4;
7
8 not U1(out0,in1);
9 and U2(out1,in1,in2,in3,in4);
10 xor U3(out2,in1,in2,in3);
11
12 initial begin
13 $monitor(
14 "in1=%b in2=%b in3=%b in4=%b out0=%b out1=%b out2=%b",
15 in1,in2,in3,in4,out0,out1,out2);
16 in1 = 0;
17 in2 = 0;
18 in3 = 0;
19 in4 = 0;
20 #1 in1 = 1;
21 #1 in2 = 1;
22 #1 in3 = 1;
23 #1 in4 = 1;
24 #1 $finish;
25 end
26
27 endmodule
You could download file gates.v here
in1 = 0 in2 = 0 in3 = 0 in4 = 0 out0 = 1 out1 = 0 out2 = 0

Transmission Gate Primitives
Transmission gates are bi-directional and can be resistive or non-resistive.
Syntax: keyword unique_name (inout1, inout2, control);
Gate Description
not N-output inverter
buf N-output buffer.
bufif0 Tri-state buffer, Active low en.
bufif1 Tri-state buffer, Active high en.
notif0 Tristate inverter, Low en.
notif1 Tristate inverter, High en.
Transmission gates tran and rtran are permanently on and do not have a control line. Tran
can be used to interface two wires with seperate drives, and rtran can be used to weaken
signals.
Examples
1 module transmission_gates();
2
3 reg data_enable_low, in;
4 wire data_bus, out1, out2;
5
6 bufif0 U1(data_bus,in, data_enable_low);
7 buf U2(out1,in);
8 not U3(out2,in);
9
10 initial begin
11 $monitor(
12 "@%g in=%b data_enable_low=%b out1=%b out2= b data_bus=%b",
13 $time, in, data_enable_low, out1, out2, data_bus);
14 data_enable_low = 0;
15 in = 0;
16 #4 data_enable_low = 1;
17 #8 $finish;
18 end
19
20 always #2 in = ~in;
21
22 endmodule
You could download file transmission_gates.v here
@0 in = 0 data_enable_low = 0 out1 = 0 out2 = 1 data_bus = 0

@2 in = 1 data_enable_low = 0 out1 = 1 out2 = 0 data_bus = 1
@4 in = 0 data_enable_low = 1 out1 = 0 out2 = 1 data_bus = z
Switch Primitives
There are six different switch primitives (transistor models) used in Verilog, nmos, pmos
and cmos and the corresponding three resistive versions rnmos, rpmos and rcmos. The
cmos type of switches have two gates and so have two control signals.
Syntax: keyword unique_name (drain. source, gate)
Gate Description
1. pmos Uni-directional PMOS switch
1. rpmos Resistive PMOS switch
2. nmos Uni-directional NMOS switch
2. rnmos Resistive NMOS switch
3. cmos Uni-directional CMOS switch
3. rcmos Resistive CMOS switch
4. tranif1 Bi-directional transistor (High)
4. tranif0 Bi-directional transistor (Low)
5. rtranif1 Resistive Transistor (High)
5. rtranif0 Resistive Transistor (Low)
6. tran Bi-directional pass transistor
6. rtran Resistive pass transistor
7. pullup Pull up resistor
8. pulldown Pull down resistor
Transmission gates are bi-directional and can be resistive or non-resistive. Resistive
devices reduce the signal strength which appears on the output by one level. All the
switches only pass signals from source to drain, incorrect wiring of the devices will result
in high impedance outputs.
Examples
1 module switch_primitives();
2
3 wire net1, net2, net3;
4 wire net4, net5, net6;
5
6 tranif0 my_gate1 (net1, net2, net3);
7 rtranif1 my_gate2 (net4, net5, net6);
8
9 endmodule
You could download file switch_primitives.v here
Transmission gates tran and rtran are permanently on and do not have a control line. Tran
can be used to interface two wires with separate drives, and rtran can be used to weaken
signals. Resistive devices reduce the signal strength which appears on the output by one
level. All the switches only pass signals from source to drain, incorrect wiring of the
devices will result in high impedance outputs.
Logic Values and signal Strengths
The Verilog HDL has got four logic values
Logic Value Description

0 zero, low, false
1 one, high, true
z or Z high impedance, floating
x or X unknown, uninitialized, contention
Verilog Strength Levels
Strength Level Specification Keyword

7 Supply Drive supply0 supply1
6 Strong Pull strong0 strong1
5 Pull Drive pull0 pull1
4 Large Capacitance large
3 Weak Drive weak0 weak1
2 Medium Capacitance medium
1 Small Capacitance small
0 Hi Impedance highz0 highz1
Example : Strength Level
Two buffers that has output
A : Pull 1
B : Supply 0
Since supply 0 is stronger then pull 1, Output C takes value of B.

Example 2 : Strength Level
Two buffers that has output
A : Supply 1
B : Large 1
Since Supply 1 is stronger then Large 1, Output C takes the value of A
Introduction
Verilog has built-in primitives like gates, transmission gates, and switches. This is a
rather small number of primitives; if we need more complex primitives, then Verilog
provides UDP, or simply User Defined Primitives. Using UDP we can model
• Combinational Logic
• Sequential Logic
We can include timing information along with these UDP to model complete ASIC
library models.
Syntax
UDP begins with reserve word primitive and ends with endprimitive. Ports/terminals of
primitive should follow. This is similar to what we do for module definition. UDPs
should be defined outside module and endmodule
1 //This code shows how input/output ports

2 // and primitve is declared
3 primitive udp_syntax (
4 a, // Port a
5 b, // Port b
6 c, // Port c
7 d // Port d
8 );
9 output a;
10 input b,c,d;
11
12 // UDP function code here
13
14 endprimitive
You could download file udp_syntax.v here
In the above code, udp_syntax is the primitive name, it contains ports a, b,c,d.
The formal syntax of the UDP definition is as follows:
<UDP>
::= primitive <name_of_UDP> ( <output_terminal_name>,
<input_terminal_name> <,<input_terminal_name>>* ) ;
<UDP_declaration>+
<UDP_initial_statement>?
<table_definition>
endprimitive
<name_of_UDP>
::= <IDENTIFIER>
<UDP_declaration>
::= <UDP_output_declaration>
||= <reg_declaration>
||= <UDP_input_declaration>
<UDP_output_declaration>
::= output <output_terminal _name>;
<reg_declaration>
::= reg <output_terminal_name> ;
<UDP_input_declaration>
::= input <input_terminal_name> <,<input_terminal_name>>* ;
<UDP_initial_statement>
::= initial <output_terminal_name> = <init_val> ;
<init_val>
::= 1'b0
||= 1'b1
||= 1'bx
||= 1
||= 0
<table_definition>
::= table
<table_entries>
endtable
<table_entries>
::= <combinational_entry>+
||= <sequential_entry>+
<combinational_entry>
::= <level_input_list> : <OUTPUT_SYMBOL> ;
<sequential_entry>
::= <input_list> : <state> : <next_state> ;
<input_list>
::= <level_input_list>
||= <edge_input_list>
<level_input_list>
::= <LEVEL_SYMBOL>+
<edge_input_list>
::= <LEVEL_SYMBOL>* <edge> <LEVEL_SYMBOL>*
<edge>
::= ( <LEVEL_SYMBOL> <LEVEL_SYMBOL> )
||= <EDGE_SYMBOL>
<state>
::= <LEVEL_SYMBOL>
<next_state>
::= <OUTPUT_SYMBOL>
||= -
UDP ports rules
• An UDP can contain only one output and up to 10 inputs.

• Output port should be the first port followed by one or more input ports.
• All UDP ports are scalar, i.e. Vector ports are not allowed.
• UDPs can not have bidirectional ports.
• The output terminal of a sequential UDP requires an additional declaration as type
reg.
• It is illegal to declare a reg for the output terminal of a combinational UDP
Body
Functionality of primitive (both combinational and sequential) is described inside a table,

and it ends with reserved word 'endtable' as shown in the code below. For sequential
UDP, we can use initial to assign an initial value to output.
1 // This code shows how UDP body looks like

2 primitive udp_body (
3 a, // Port a
4 b, // Port b
5 c // Port c
6 );
7 output a;
8 input b,c;
9
10 // UDP function code here
11 // A = B | C;
12 table
13 // B C : A
14 ? 1 : 1;
15 1 ? : 1;
16 0 0 : 0;
17 endtable
18
19 endprimitive
You could download file udp_body.v here
Note: An UDP cannot use 'z' in the input table
TestBench to check the above UDP
1 ìnclude "udp_body.v"
2 module udp_body_tb();
3
4 reg b,c;
5 wire a;
6
7 udp_body udp (a,b,c);
8
9 initial begin
10 $monitor(" B = %b C = %b A = %b",b,c,a);
11 b = 0;
12 c = 0;
13 #1 b = 1;
14 #1 b = 0;
15 #1 c = 1;
16 #1 b = 1'bx;
17 #1 c = 0;
18 #1 b = 1;
19 #1 c = 1'bx;
20 #1 b = 0;
21 #1 $finish;
22 end
23
24 endmodule
You could download file udp_body_tb.v here
Simulator Output
B = 0 C = 0 A = 0
B = 1 C = 0 A = 1
B = 0 C = 0 A = 0
B = 0 C = 1 A = 1
B = x C = 1 A = 1
B = x C = 0 A = x
B = 1 C = 0 A = 1
B = 1 C = x A = 1
B = 0 C = x A = x
Table
Table is used for describing the function of UDP. Verilog reserved word table marks the
start of table and reserved word endtable marks the end of table.
Each line inside a table is one condition; when an input changes, the input condition is
matched and the output is evaluated to reflect the new change in input.
Initial
Initial statement is used for initialization of sequential UDPs. This statement begins with
the keyword 'initial'. The statement that follows must be an assignment statement that
assigns a single bit literal value to the output terminal reg.
1 primitive udp_initial (a,b,c);

2 output a;
3 input b,c;
4 reg a;
5 // a has value of 1 at start of sim
6 initial a = 1'b1;
7
8 table
9 // udp_initial behaviour
10 endtable
11
12 endprimitive
You could download file udp_initial.v here
Symbols
UDP uses special symbols to describe functions like rising edge, don't care and so on.
The table below shows the symbols that are used in UDPs:
Symbol Interpretation Explanation

? 0 or 1 or X ? means the variable can be 0 or 1 or x
b 0 or 1 Same as ?, but x is not included
f (10) Falling edge on an input
r (01) Rising edge on an input
(01) or (0x) or (x1) or (1z)
p Rising edge including x and z
or (z1)
(10) or (1x) or (x0) or (0z)
n Falling edge including x and z
or (z0)
* (??) All transitions
- no change No Change
Arithmetic Operators
• Binary: +, -, *, /, % (the modulus operator)

• Unary: +, - (This is used to specify the sign)
• Integer division truncates any fractional part
• The result of a modulus operation takes the sign of the first operand
• If any operand bit value is the unknown value x, then the entire result value is x
• Register data types are used as unsigned values (Negative numbers are stored in
two's complement form)
Example
1 module arithmetic_operators();
2
3 initial begin
4 $display (" 5 + 10 = %d", 5 + 10);
5 $display (" 5 - 10 = %d", 5 - 10);
6 $display (" 10 - 5 = %d", 10 - 5);
7 $display (" 10 * 5 = %d", 10 * 5);
8 $display (" 10 / 5 = %d", 10 / 5);
9 $display (" 10 / -5 = %d", 10 / -5);
10 $display (" 10 %s 3 = %d","%", 10 % 3);
11 $display (" +5 = %d", +5);
12 $display (" -5 = %d", -5);
13 #10 $finish;
14 end
15
16 endmodule
You could download file arithmetic_operators.v here
5 + 10 = 15
5 - 10 = -5
10 - 5 = 5
10 * 5 = 50
10 / 5 = 2
10 / -5 = -2
10 % 3 = 1
+5 = 5
-5 = -5
Relational Operators
Operator Description
a<b a less than b
a>b a greater than b
a <= b a less than or equal to b
a >= b a greater than or equal to b
• The result is a scalar value (example a < b)

• 0 if the relation is false (a is bigger then b)
• 1 if the relation is true ( a is smaller then b)
• x if any of the operands has unknown x bits (if a or b contains X)
Note: If any operand is x or z, then the result of that test is treated as false (0)
Example
1 module relational_operators();
2
3 initial begin
4 $display (" 5 <= 10 = %b", (5 <= 10));
5 $display (" 5 >= 10 = %b", (5 >= 10));
6 $display (" 1'bx <= 10 = %b", (1'bx <= 10));
7 $display (" 1'bz <= 10 = %b", (1'bz <= 10));
8 #10 $finish;
9 end
10
11 endmodule
You could download file relational_operators.v here
5 <= 10 = 1
5 >= 10 = 0
1'bx <= 10 = x
1'bz <= 10 = x
Equality Operators
There are two types of Equality operators. Case Equality and Logical Equality.
a === b a equal to b, including x and z (Case equality)
a !== b a not equal to b, including x and z (Case inequality)
a == b a equal to b, result may be unknown (logical equality)
a != b a not equal to b, result may be unknown (logical equality)
• Operands are compared bit by bit, with zero filling if the two operands do not
have the same length
• Result is 0 (false) or 1 (true)
• For the == and != operators, the result is x, if either operand contains an x or a z
• For the === and !== operators, bits with x and z are included in the comparison
and must match for the result to be true
Note : The result is always 0 or 1.
Example
1 module equality_operators();
2
3 initial begin
4 // Case Equality
5 $display (" 4'bx001 === 4'bx001 = %b", (4'bx001 === 4'bx001));
6 $display (" 4'bx0x1 === 4'bx001 = %b", (4'bx0x1 === 4'bx001));
7 $display (" 4'bz0x1 === 4'bz0x1 = %b", (4'bz0x1 === 4'bz0x1));
8 $display (" 4'bz0x1 === 4'bz001 = %b", (4'bz0x1 === 4'bz001));
9 // Case Inequality
10 $display (" 4'bx0x1 !== 4'bx001 = %b", (4'bx0x1 ! == 4'bx001));
11 $display (" 4'bz0x1 !== 4'bz001 = %b", (4'bz0x1 ! ==
4'bz001));
12 // Logical Equality
13 $display (" 5 == 10 = %b", (5 == 10));
14 $display (" 5 == 5 = %b", (5 == 5));
15 // Logical Inequality
16 $display (" 5 != 5 = %b", (5 ! = 5));
17 $display (" 5 != 6 = %b", (5 ! = 6));
18 #10 $finish;
19 end
20
21 endmodule
You could download file equality_operators.v here
4'bx001 === 4'bx001 = 1

4'bx0x1 === 4'bx001 = 0
4'bz0x1 === 4'bz0x1 = 1
4'bz0x1 === 4'bz001 = 0
4'bx0x1 !== 4'bx001 = 1
4'bz0x1 !== 4'bz001 = 1
5 == 10 = 0
5 == 5 = 1
5 != 5 = 0
5 != 6 = 1
Logical Operators
! logic negation
&& logical and
|| logical or
• Expressions connected by && and || are evaluated from left to right

• Evaluation stops as soon as the result is known
• The result is a scalar value:
o 0 if the relation is false
o 1 if the relation is true
o x if any of the operands has x (unknown) bits
Example
1 module logical_operators();
2
3 initial begin
4 // Logical AND
5 $display ("1'b1 && 1'b1 = %b", (1'b1 && 1'b1));
6 $display ("1'b1 && 1'b0 = %b", (1'b1 && 1'b0));
7 $display ("1'b1 && 1'bx = %b", (1'b1 && 1'bx));
8 // Logical OR
9 $display ("1'b1 || 1'b0 = %b", (1'b1 || 1'b0));
10 $display ("1'b0 || 1'b0 = %b", (1'b0 || 1'b0));
11 $display ("1'b0 || 1'bx = %b", (1'b0 || 1'bx));
12 // Logical Negation
13 $display ("! 1'b1 = %b", ( ! 1'b1));
14 $display ("! 1'b0 = %b", ( ! 1'b0));
15 #10 $finish;
16 end
17
18 endmodule
You could download file logical_operators.v here
1'b1 && 1'b1 = 1

1'b1 && 1'b0 = 0
1'b1 && 1'bx = x
1'b1 || 1'b0 = 1
1'b0 || 1'b0 = 0
1'b0 || 1'bx = x
! 1'b1 = 0
! 1'b0 = 1
Bit-wise Operators
Bitwise operators perform a bit wise operation on two operands. They take each bit in
one operand and perform the operation with the corresponding bit in the other operand. If
one operand is shorter than the other, it will be extended on the left side with zeroes to
match the length of the longer operand.
~ negation
& and
| inclusive or
^ exclusive or
^~ or ~^ exclusive nor (equivalence)
• Computations include unknown bits, in the following way:

o ~x = x
o 0&x = 0
o 1&x = x&x = x
o 1|x = 1
o 0|x = x|x = x
o 0^x = 1^x = x^x = x
o 0^~x = 1^~x = x^~x = x
• When operands are of unequal bit length, the shorter operand is zero-filled in the
most significant bit positions.
Example
1 module bitwise_operators();
2
3 initial begin
4 // Bit Wise Negation
5 $display (" ~4'b0001 = %b", (~4'b0001));
6 $display (" ~4'bx001 = %b", (~4'bx001));
7 $display (" ~4'bz001 = %b", (~4'bz001));
8 // Bit Wise AND
9 $display (" 4'b0001 & 4'b1001 = %b", (4'b0001 & 4'b1001));
10 $display (" 4'b1001 & 4'bx001 = %b", (4'b1001 & 4'bx001));
11 $display (" 4'b1001 & 4'bz001 = %b", (4'b1001 & 4'bz001));
12 // Bit Wise OR
13 $display (" 4'b0001 | 4'b1001 = %b", (4'b0001 | 4'b1001));
14 $display (" 4'b0001 | 4'bx001 = %b", (4'b0001 | 4'bx001));
15 $display (" 4'b0001 | 4'bz001 = %b", (4'b0001 | 4'bz001));
16 // Bit Wise XOR
17 $display (" 4'b0001 ^ 4'b1001 = %b", (4'b0001 ^ 4'b1001));
18 $display (" 4'b0001 ^ 4'bx001 = %b", (4'b0001 ^ 4'bx001));
19 $display (" 4'b0001 ^ 4'bz001 = %b", (4'b0001 ^ 4'bz001));
20 // Bit Wise XNOR
21 $display (" 4'b0001 ~^ 4'b1001 = %b", (4'b0001 ~^ 4'b1001));
22 $display (" 4'b0001 ~^ 4'bx001 = %b", (4'b0001 ~^ 4'bx001));
23 $display (" 4'b0001 ~^ 4'bz001 = %b", (4'b0001 ~^ 4'bz001));
24 #10 $finish;
25 end
26
27 endmodule
You could download file bitwise_operators.v here
~4'b0001 = 1110
~4'bx001 = x110
~4'bz001 = x110
4'b0001 & 4'b1001 = 0001
4'b1001 & 4'bx001 = x001
4'b1001 & 4'bz001 = x001
4'b0001 | 4'b1001 = 1001
4'b0001 | 4'bx001 = x001
4'b0001 | 4'bz001 = x001
4'b0001 ^ 4'b1001 = 1000
4'b0001 ^ 4'bx001 = x000
4'b0001 ^ 4'bz001 = x000
4'b0001 ~^ 4'b1001 = 0111
4'b0001 ~^ 4'bx001 = x111
4'b0001 ~^ 4'bz001 = x111
Verilog HDL Abstraction Levels
• Behavioral Models : Higher level of modeling where behavior of logic is

modeled.
• RTL Models : Logic is modeled at register level
• Structural Models : Logic is modeled at both register level and gate level.
Procedural Blocks
Verilog behavioral code is inside procedure blocks, but there is an exception: some
behavioral code also exist outside procedure blocks. We can see this in detail as we make
progress.
There are two types of procedural blocks in Verilog:
• initial : initial blocks execute only once at time zero (start execution at time zero).
• always : always blocks loop to execute over and over again; in other words, as the
name suggests, it executes always.
Example - initial
1 module initial_example();
2 reg clk,reset,enable,data;
3
4 initial begin
5 clk = 0;
6 reset = 0;
7 enable = 0;
8 data = 0;
9 end
10
11 endmodule
You could download file initial_example.v here
In the above example, the initial block execution and always block execution starts at
time 0. Always block waits for the event, here positive edge of clock, whereas initial
block just executed all the statements within begin and end statement, without waiting.
Example - always
1 module always_example();
2 reg clk,reset,enable,q_in,data;
3
5 if (reset) begin
6 data <= 0;
7 end else if (enable) begin
8 data <= q_in;
9 end
10
11 endmodule
You could download file always_example.v here
In an always block, when the trigger event occurs, the code inside begin and end is
executed; then once again the always block waits for next event triggering. This process
of waiting and executing on event is repeated till simulation stops.
Procedural Assignment Statements
• Procedural assignment statements assign values to reg, integer, real, or time

variables and can not assign values to nets (wire data types)
• You can assign to a register (reg data type) the value of a net (wire), constant,
another register, or a specific value.
Example - Bad procedural assignment
1 module initial_bad();
2 reg clk,reset;
3 wire enable,data;
4
5 initial begin
6 clk = 0;
7 reset = 0;
8 enable = 0;
9 data = 0;
10 end
11
12 endmodule
You could download file initial_bad.v here
Example - Good procedural assignment
1 module initial_good();
3
4 initial begin
5 clk = 0;
6 reset = 0;
7 enable = 0;
8 data = 0;
9 end
10
11 endmodule
You could download file initial_good.v here
Procedural Assignment Groups
If a procedure block contains more than one statement, those statements must be enclosed
within
• Sequential begin - end block

• Parallel fork - join block
When using begin-end, we can give name to that group. This is called named blocks.
Example - "begin-end"
1 module initial_begin_end();
3
4 initial begin
5 $monitor(
6 "%g clk=%b reset=%b enable=%b data=%b",
7 $time, clk, reset, enable, data);
8 #1 clk = 0;
9 #10 reset = 0;
10 #5 enable = 0;
11 #3 data = 0;
12 #1 $finish;
13 end
14
15 endmodule
You could download file initial_begin_end.v here
Begin : clk gets 0 after 1 time unit, reset gets 0 after 11 time units, enable after 16 time
units, data after 19 units. All the statements are executed sequentially.
Simulator Output
0 clk=x reset=x enable=x data=x

1 clk=0 reset=x enable=x data=x
11 clk=0 reset=0 enable=x data=x
16 clk=0 reset=0 enable=0 data=x
19 clk=0 reset=0 enable=0 data=0
Example - "fork-join"
1 module initial_fork_join();
3
4 initial begin
5 $monitor("%g clk=%b reset=%b enable=%b data=%b",
7 fork
8 #1 clk = 0;
9 #10 reset = 0;
10 #5 enable = 0;
11 #3 data = 0;
12 join
13 #1 $display ("%g Terminating simulation", $time);
14 $finish;
15 end
16
17 endmodule
You could download file initial_fork_join.v here
Fork : clk gets its value after 1 time unit, reset after 10 time units, enable after 5 time
units, data after 3 time units. All the statements are executed in parallel.
Simulator Output

3 clk=0 reset=x enable=x data=0
5 clk=0 reset=x enable=0 data=0
11 Terminating simulation
Sequential Statement Groups
The begin - end keywords:
• Group several statements together.

• Cause the statements to be evaluated sequentially (one at a time)
o Any timing within the sequential groups is relative to the previous
statement.
o Delays in the sequence accumulate (each delay is added to the previous
delay)
o Block finishes after the last statement in the block.
Example - sequential
1 module sequential();
2
3 reg a;
4
5 initial begin
6 $monitor ("%g a = %b", $time, a);
7 #10 a = 0;
8 #11 a = 1;
9 #12 a = 0;
10 #13 a = 1;
11 #14 $finish;
12 end
13
14 endmodule
You could download file sequential.v here
Simulator Output
0 a = x
10 a = 0
21 a = 1
33 a = 0
46 a = 1
Parallel Statement Groups

The fork - join keywords:
• Group several statements together.

• Cause the statements to be evaluated in parallel (all at the same time).
o Timing within parallel group is absolute to the beginning of the group.
o Block finishes after the last statement completes (Statement with highest
delay, it can be the first statement in the block).
Example - Parallel
1 module parallel();
2
3 reg a;
4
5 initial
6 fork
7 $monitor ("%g a = %b", $time, a);
8 #10 a = 0;
9 #11 a = 1;
10 #12 a = 0;
11 #13 a = 1;
12 #14 $finish;
13 join
14
15 endmodule
You could download file parallel.v here
Simulator Output
0 a = x
10 a = 0
11 a = 1
12 a = 0
13 a = 1
Example - Mixing "begin-end" and "fork - join"
1 module fork_join();
2
4
5 initial begin
6 $display ("Starting simulation");
7 $monitor("%g clk=%b reset=%b enable=%b data=%b",
9 fork : FORK_VAL
10 #1 clk = 0;
11 #5 reset = 0;
12 #5 enable = 0;
13 #2 data = 0;
14 join
15 #10 $display ("%g Terminating simulation", $time);
16 $finish;
17 end
18
19 endmodule
You could download file fork_join.v here
Simulator Output

2 clk=0 reset=x enable=x data=0
15 Terminating simulation
Blocking and Nonblocking assignment
Blocking assignments are executed in the order they are coded, hence they are sequential.
Since they block the execution of next statment, till the current statement is executed,
they are called blocking assignments. Assignment are made with "=" symbol. Example a
= b;
Nonblocking assignments are executed in parallel. Since the execution of next statement
is not blocked due to execution of current statement, they are called nonblocking
statement. Assignments are made with "<=" symbol. Example a <= b;
Note : Correct way to spell 'nonblocking' is 'nonblocking' and not 'non-blocking'.
Example - blocking and nonblocking
1 module blocking_nonblocking();
2
3 reg a,b,c,d;
4 // Blocking Assignment
5 initial begin
6 #10 a = 0;
7 #11 a = 1;
8 #12 a = 0;
9 #13 a = 1;
10 end
11
12 initial begin
13 #10 b <= 0;
14 #11 b <= 1;
15 #12 b <= 0;
16 #13 b <= 1;
17 end
18
19 initial begin
20 c = #10 0;
21 c = #11 1;
22 c = #12 0;
23 c = #13 1;
24 end
25
26 initial begin
27 d <= #10 0;
28 d <= #11 1;
29 d <= #12 0;
30 d <= #13 1;
31 end
32
33 initial begin
34 $monitor("TIME = %g A = %b B = %b C = %b D = %b",$time, a, b, c,
d);
35 #50 $finish;
36 end
37
38 endmodule
You could download file blocking_nonblocking.v here
Simulator Output
TIME = 0 A = x B = x C = x D = x
TIME = 10 A = 0 B = 0 C = 0 D = 0
TIME = 11 A = 0 B = 0 C = 0 D = 1
TIME = 12 A = 0 B = 0 C = 0 D = 0
TIME = 13 A = 0 B = 0 C = 0 D = 1
TIME = 21 A = 1 B = 1 C = 1 D = 1
TIME = 33 A = 0 B = 0 C = 0 D = 1
TIME = 46 A = 1 B = 1 C = 1 D = 1
Waveform
assign and deassign
The assign and deassign procedural assignment statements allow continuous assignments
to be placed onto registers for controlled periods of time. The assign procedural statement
overrides procedural assignments to a register. The deassign procedural statement ends a
continuous assignment to a register.
Example - assign and deassign
1 module assign_deassign ();

2
3 reg clk,rst,d,preset;
4 wire q;
5
6 initial begin
7 $monitor("@%g clk %b rst %b preset %b d %b q %b",
8 $time, clk, rst, preset, d, q);
9 clk = 0;
10 rst = 0;
11 d = 0;
12 preset = 0;
13 #10 rst = 1;
14 #10 rst = 0;
15 repeat (10) begin
16 @ (posedge clk);
17 d <= $random;
18 @ (negedge clk) ;
19 preset <= ~preset;
20 end
21 #1 $finish;
22 end
24 always #1 clk = ~clk;
25
26 // assign and deassign q of flip flop module
27 always @(preset)
28 if (preset) begin
29 assign U.q = 1; // assign procedural statement
30 end else begin
31 deassign U.q; // deassign procedural statement
32 end
33
34 d_ff U (clk,rst,d,q);
35
36 endmodule
37
38 // D Flip-Flop model
39 module d_ff (clk,rst,d,q);
40 input clk,rst,d;
41 output q;
42 reg q;
43
45 if (rst) begin
46 q <= 0;
47 end else begin
48 q <= d;
49 end
50
51 endmodule
You could download file assign_deassign.v here
Simulator Output
@0 clk 0 rst 0 preset 0 d 0 q x

@1 clk 1 rst 0 preset 0 d 0 q 0
force and release
Another form of procedural continuous assignment is provided by the force and release
procedural statements. These statements have a similar effect on the assign-deassign pair,
but a force can be applied to nets as well as to registers.
One can use force and release while doing gate level simulation to work around reset
connectivity problems. Also can be used insert single and double bit errors on data read
from memory.
Example - force and release
1 module force_release ();

2
3 reg clk,rst,d,preset;
4 wire q;
5
6 initial begin
7 $monitor("@%g clk %b rst %b preset %b d %b q %b",
8 $time, clk, rst, preset, d, q);
9 clk = 0;
10 rst = 0;
11 d = 0;
12 preset = 0;
13 #10 rst = 1;
14 #10 rst = 0;
15 repeat (10) begin
16 @ (posedge clk);
17 d <= $random;
18 @ (negedge clk) ;
19 preset <= ~preset;
20 end
21 #1 $finish;
22 end
24 always #1 clk = ~clk;
25
26 // force and release of flip flop module
27 always @(preset)
28 if (preset) begin
29 force U.q = preset; // force procedural statement
30 end else begin
31 release U.q; // release procedural statement
32 end
33
34 d_ff U (clk,rst,d,q);
35
36 endmodule
37
38 // D Flip-Flop model
39 module d_ff (clk,rst,d,q);
40 input clk,rst,d;
41 output q;
42 wire q;
43 reg q_reg;
44
45 assign q = q_reg;
46
48 if (rst) begin
49 q_reg <= 0;
50 end else begin
51 q_reg <= d;
52 end
53
54 endmodule
You could download file force_release.v here
Simulator Output
@0 clk 0 rst 0 preset 0 d 0 q x

Procedural blocks and timing controls.
• Delay controls.
• Edge-Sensitive Event controls.
• Level-Sensitive Event controls-Wait statements.
• Named Events.
Delay Controls
Delays the execution of a procedural statement by specific simulation time.
#< time > < statement >;

Example - clk_gen
1 module clk_gen ();

2
3 reg clk, reset;
4
5 initial begin
6 $monitor ("TIME = %g RESET = %b CLOCK = %b", $time, reset, clk);
7 clk = 0;
8 reset = 0;
9 #2 reset = 1;
10 #5 reset = 0;
11 #10 $finish;
12 end
13
14 always
15 #1 clk = ! clk;
16
17 endmodule
You could download file clk_gen.v here
Simulation Output
TIME = 0 RESET = 0 CLOCK = 0

Waveform
Edge sensitive Event Controls
Delays execution of the next statement until the specified transition on a signal.
syntax : @ (< posedge >|< negedge > signal) < statement >;
Example - Edge Wait
1 module edge_wait_example();
2
3 reg enable, clk, trigger;
4
5 always @ (posedge enable)
6 begin
7 trigger = 0;
8 // Wait for 5 clock cycles
9 repeat (5) begin
10 @ (posedge clk) ;
11 end
12 trigger = 1;
13 end
14
15 //Testbench code here
16 initial begin
17 $monitor ("TIME : %g CLK : %b ENABLE : %b TRIGGER : %b",
18 $time, clk,enable,trigger);
19 clk = 0;
20 enable = 0;
21 #5 enable = 1;
22 #1 enable = 0;
23 #10 enable = 1;
24 #1 enable = 0;
25 #10 $finish;
26 end
27
28 always
29 #1 clk = ~clk;
30
31 endmodule
You could download file edge_wait_example.v here
Simulator Output
TIME : 0 CLK : 0 ENABLE : 0 TRIGGER : x

TIME : 5 CLK : 1 ENABLE : 1 TRIGGER : 0
Level-Sensitive Even Controls ( Wait statements )
Delays execution of the next statement until < expression > evaluates to true
syntax : wait (< expression >) < statement >;
Example - Level Wait
1 module wait_example();
2
3 reg mem_read, data_ready;
4 reg [7:0] data_bus, data;
5
6 always @ (mem_read or data_bus or data_ready)
7 begin
8 data = 0;
9 while (mem_read == 1'b1) begin
10 // #1 is very important to avoid infinite loop
11 wait (data_ready == 1) #1 data = data_bus;
12 end
13 end
14
15 // Testbench Code here
16 initial begin
17 $monitor ("TIME = %g READ = %b READY = %b DATA = %b",
18 $time, mem_read, data_ready, data);
19 data_bus = 0;
20 mem_read = 0;
21 data_ready = 0;
22 #10 data_bus = 8'hDE;
23 #10 mem_read = 1;
24 #20 data_ready = 1;
25 #1 mem_read = 1;
27 #10 data_bus = 8'hAD;
28 #10 mem_read = 1;
30 #1 mem_read = 1;
32 #10 $finish;
33 end
34
35 endmodule
You could download file wait_example.v here
Simulator Output
TIME = 0 READ = 0 READY = 0 DATA = 00000000

Intra-Assignment Timing Controls
Intra-assignment controls always evaluate the right side expression immediately and
assign the result after the delay or event control.
In non-intra-assignment controls (delay or event control on the left side), the right side
expression is evaluated after the delay or event control.
Example - Intra-Assignment
1 module intra_assign();
2
3 reg a, b;
4
5 initial begin
6 $monitor("TIME = %g A = %b B = %b",$time, a , b);
7 a = 1;
8 b = 0;
9 a = #10 0;
10 b = a;
11 #20 $display("TIME = %g A = %b B = %b",$time, a , b);
12 $finish;
13 end
14
15 endmodule
You could download file intra_assign.v here
Simulation Output
TIME = 0 A = 1 B = 0
TIME = 10 A = 0 B = 0
TIME = 30 A = 0 B = 0
Waveform
Modeling Combo Logic with Continuous Assignments

Whenever any signal changes on the right hand side, the entire right-hand side is re-
evaluated and the result is assigned to the left hand side.
Example - Tri-state Buffer
1 module tri_buf_using_assign();
2 reg data_in, enable;
3 wire pad;
4
5 assign pad = (enable) ? data_in : 1'bz;
6
7 initial begin
8 $monitor ("TIME = %g ENABLE = %b DATA : %b PAD %b",
9 $time, enable, data_in, pad);
10 #1 enable = 0;
11 #1 data_in = 1;
12 #1 enable = 1;
13 #1 data_in = 0;
14 #1 enable = 0;
15 #1 $finish;
16 end
17
18 endmodule
You could download file tri_buf_using_assign.v here
Simulation Output
TIME = 0 ENABLE = x DATA : x PAD x

TIME = 1 ENABLE = 0 DATA : x PAD z
TIME = 2 ENABLE = 0 DATA : 1 PAD z
TIME = 3 ENABLE = 1 DATA : 1 PAD 1
TIME = 4 ENABLE = 1 DATA : 0 PAD 0
TIME = 5 ENABLE = 0 DATA : 0 PAD z
Waveform
Example - Mux
1 module mux_using_assign();
2 reg data_in_0, data_in_1;
3 wire data_out;
4 reg sel;
5
6 assign data_out = (sel) ? data_in_1 : data_in_0;
7
8 // Testbench code here
9 initial begin
10 $monitor("TIME = %g SEL = %b DATA0 = %b DATA1 = %b OUT = %b",
11 $time,sel,data_in_0,data_in_1,data_out);
12 data_in_0 = 0;
13 data_in_1 = 0;
14 sel = 0;
15 #10 sel = 1;
16 #10 $finish;
17 end
18
19 // Toggel data_in_0 at #1
20 always
21 #1 data_in_0 = ~data_in_0;
22
23 // Toggel data_in_1 at #2
24 always
25 #2 data_in_1 = ~data_in_1;
26
27 endmodule
You could download file mux_using_assign.v here
Simulation Output
TIME = 0 SEL = 0 DATA0 = 0 DATA1 = 0 OUT = 0

Waveform
Task
Tasks are used in all programming languages, generally known as procedures or

subroutines. The lines of code are enclosed in task....end task brackets. Data is passed to
the task, the processing done, and the result returned. They have to be specifically called,
with data ins and outs, rather than just wired in to the general netlist. Included in the main
body of code, they can be called many times, reducing code repetition.
• tasks are defined in the module in which they are used. It is possible to define a
task in a separate file and use the compile directive 'include to include the task in
the file which instantiates the task.
• tasks can include timing delays, like posedge, negedge, # delay and wait.
• tasks can have any number of inputs and outputs.
• The variables declared within the task are local to that task. The order of
declaration within the task defines how the variables passed to the task by the
caller are used.
• tasks can take, drive and source global variables, when no local variables are
used. When local variables are used, basically output is assigned only at the end
of task execution.
• tasks can call another task or function.
• tasks can be used for modeling both combinational and sequential logic.
• A task must be specifically called with a statement, it cannot be used within an
expression as a function can.
Syntax
• A task begins with keyword task and ends with keyword endtask
• Inputs and outputs are declared after the keyword task.
• Local variables are declared after input and output declaration.
Example - Simple Task
1 module simple_task();
2
3 task convert;
4 input [7:0] temp_in;
5 output [7:0] temp_out;
6 begin
7 temp_out = (9/5) *( temp_in + 32)
8 end
9 endtask
10
11 endmodule
You could download file simple_task.v here
Example - Task using Global Variables
1 module task_global();
2
3 reg [7:0] temp_out;
4 reg [7:0] temp_in;
5
6 task convert;
7 begin
8 temp_out = (9/5) *( temp_in + 32);
9 end
10 endtask
11
12 endmodule
You could download file task_global.v here
Calling a Task
Let's assume that the task in example 1 is stored in a file called mytask.v. Advantage of
coding a task in a separate file, is that it can be used in multiple modules.
1 module task_calling (temp_a, temp_b, temp_c, temp_d);

2 input [7:0] temp_a, temp_c;
3 output [7:0] temp_b, temp_d;
4 reg [7:0] temp_b, temp_d;
5 ìnclude "mytask.v"
6
7 always @ (temp_a)
8 begin
9 convert (temp_a, temp_b);
10 end
11
12 always @ (temp_c)
13 begin
14 convert (temp_c, temp_d);
15 end
16
17 endmodule
You could download file task_calling.v here
Example - CPU Write / Read Task
Below is the waveform used for writing into memory and reading from memory. We
make the assumption that there is a need to use this interface from multiple agents. So we
write the read/write as tasks.
1 module bus_wr_rd_task();
2
3 reg clk,rd,wr,ce;
4 reg [7:0] addr,data_wr,data_rd;
5 reg [7:0] read_data;
6
7 initial begin
8 clk = 0;
9 read_data = 0;
10 rd = 0;
11 wr = 0;
12 ce = 0;
13 addr = 0;
14 data_wr = 0;
15 data_rd = 0;
16 // Call the write and read tasks here
17 #1 cpu_write(8'h11,8'hAA);
18 #1 cpu_read(8'h11,read_data);
19 #1 cpu_write(8'h12,8'hAB);
21 #1 cpu_write(8'h13,8'h0A);
23 #100 $finish;
24 end
25 // Clock Generator
26 always
27 #1 clk = ~clk;
28 // CPU Read Task
29 task cpu_read;
30 input [7:0] address;
31 output [7:0] data;
32 begin
33 $display ("%g CPU Read task with address : %h", $time,
address);
34 $display ("%g -> Driving CE, RD and ADDRESS on to bus", $time);
35 @ (posedge clk);
36 addr = address;
37 ce = 1;
38 rd = 1;
39 @ (negedge clk);
40 data = data_rd;
41 @ (posedge clk);
42 addr = 0;
43 ce = 0;
44 rd = 0;
45 $display ("%g CPU Read data : %h", $time, data);
46 $display ("======================");
47 end
48 endtask
49 // CU Write Task
50 task cpu_write;
51 input [7:0] address;
52 input [7:0] data;
53 begin
54 $display ("%g CPU Write task with address : %h Data : %h",
55 $time, address,data);
56 $display ("%g -> Driving CE, WR, WR data and ADDRESS on to
bus",
57 $time);
58 @ (posedge clk);
59 addr = address;
60 ce = 1;
61 wr = 1;
62 data_wr = data;
63 @ (posedge clk);
64 addr = 0;
65 ce = 0;
66 wr = 0;
67 $display ("======================");
68 end
69 endtask
70
71 // Memory model for checking tasks
72 reg [7:0] mem [0:255];
73
74 always @ (addr or ce or rd or wr or data_wr)
75 if (ce) begin
76 if (wr) begin
77 mem[addr] = data_wr;
78 end
79 if (rd) begin
80 data_rd = mem[addr];
81 end
82 end
83
84 endmodule
You could download file bus_wr_rd_task.v here
Simulation Output
1 CPU Write task with address : 11 Data : aa

1 -> Driving CE, WR, WR data and ADDRESS on to bus
======================
4 CPU Read task with address : 11
4 -> Driving CE, RD and ADDRESS on to bus
7 CPU Read data : aa
======================
8 CPU Write task with address : 12 Data : ab
======================
15 CPU Read data : ab
======================
16 CPU Write task with address : 13 Data : 0a
======================
23 CPU Read data : 0a
======================
Function
A Verilog HDL function is the same as a task, with very little differences, like function
cannot drive more than one output, can not contain delays.
• functions are defined in the module in which they are used. It is possible to define
functions in separate files and use compile directive 'include to include the
function in the file which instantiates the task.
• functions can not include timing delays, like posedge, negedge, # delay, which
means that functions should be executed in "zero" time delay.
• functions can have any number of inputs but only one output.
• The variables declared within the function are local to that function. The order of
declaration within the function defines how the variables passed to the function by
the caller are used.
• functions can take, drive, and source global variables, when no local variables are
used. When local variables are used, basically output is assigned only at the end
of function execution.
• functions can be used for modeling combinational logic.
• functions can call other functions, but can not call tasks.
Syntax
• A function begins with keyword function and ends with keyword endfunction
• inputs are declared after the keyword function.
Example - Simple Function
1 module simple_function();
2
3 function myfunction;
4 input a, b, c, d;
5 begin
6 myfunction = ((a+b) + (c-d));
7 end
8 endfunction
9
10 endmodule
You could download file simple_function.v here
Example - Calling a Function

1 module function_calling(a, b, c, d, e, f);
2
3 input a, b, c, d, e ;
4 output f;
5 wire f;
6 ìnclude "myfunction.v"
7
8 assign f = (myfunction (a,b,c,d)) ? e :0;
9
10 endmodule
You could download file function_calling.v here
Introduction
There are tasks and functions that are used to generate input and output during
simulation. Their names begin with a dollar sign ($). The synthesis tools parse and ignore
system functions, and hence can be included even in synthesizable models.
$display, $strobe, $monitor
These commands have the same syntax, and display text on the screen during simulation.
They are much less convenient than waveform display tools like GTKWave. or Undertow
or Debussy. $display and $strobe display once every time they are executed, whereas
$monitor displays every time one of its parameters changes. The difference between
$display and $strobe is that $strobe displays the parameters at the very end of the current
simulation time unit rather than exactly when it is executed. The format string is like that
in C/C++, and may contain format characters. Format characters include %d (decimal),
%h (hexadecimal), %b (binary), %c (character), %s (string) and %t (time), %m
(hierarchy level). %5d, %5b etc. would give exactly 5 spaces for the number instead of
the space needed. Append b, h, o to the task name to change default format to binary,
octal or hexadecimal.
Syntax
• $display ("format_string", par_1, par_2, ... );

• $strobe ("format_string", par_1, par_2, ... );
• $monitor ("format_string", par_1, par_2, ... );
• $displayb (as above but defaults to binary..);
• $strobeh (as above but defaults to hex..);
• $monitoro (as above but defaults to octal..);
$time, $stime, $realtime
These return the current simulation time as a 64-bit integer, a 32-bit integer, and a real
number, respectively.
$reset, $stop, $finish
$reset resets the simulation back to time 0; $stop halts the simulator and puts it in
interactive mode where the user can enter commands; $finish exits the simulator back to
the operating system.
$scope, $showscope
$scope(hierarchy_name) sets the current hierarchical scope to hierarchy_name.

$showscopes(n) lists all modules, tasks and block names in (and below, if n is set to 1)
the current scope.
$random
$random generates a random integer every time it is called. If the sequence is to be
repeatable, the first time one invokes random giving it a numerical argument (a seed).
Otherwise the seed is derived from the computer clock.
$dumpfile, $dumpvar, $dumpon, $dumpoff, $dumpall
These can dump variable changes to a simulation viewer like Debussy. The dump files
are capable of dumping all the variables in a simulation. This is convenient for
debugging, but can be very slow.
Syntax
• $dumpfile("filename.vcd")
• $dumpvar dumps all variables in the design.
• $dumpvar(1, top) dumps all the variables in module top and below, but not
modules instantiated in top.
• $dumpvar(2, top) dumps all the variables in module top and 1 level below.
• $dumpvar(n, top) dumps all the variables in module top and n-1 levels below.
• $dumpvar(0, top) dumps all the variables in module top and all level below.
• $dumpon initiates the dump.
• $dumpoff stop dumping.
$fopen, $fdisplay, $fstrobe $fmonitor and $fwrite
These commands write more selectively to files.
• $fopen opens an output file and gives the open file a handle for use by the other
commands.
• $fclose closes the file and lets other programs access it.
• $fdisplay and $fwrite write formatted data to a file whenever they are executed.
They are the same except $fdisplay inserts a new line after every execution and
$write does not.
• $strobe also writes to a file when executed, but it waits until all other operations
in the time step are complete before writing. Thus initial #1 a=1; b=0;
$fstrobe(hand1, a,b); b=1; will write write 1 1 for a and b.
• $monitor writes to a file whenever any of its arguments changes.
Syntax
• handle1=$fopen("filenam1.suffix")
• handle2=$fopen("filenam2.suffix")
• $fstrobe(handle1, format, variable list) //strobe data into filenam1.suffix
• $fdisplay(handle2, format, variable list) //write data into filenam2.suffix
• $fwrite(handle2, format, variable list) //write data into filenam2.suffix all on one
line. Put in the format string where a new line is desired.
Introduction
Writing a testbench is as complex as writing the RTL code itself. These days ASICs are
getting more and more complex and thus verifying these complex ASIC has become a
challenge. Typically 60-70% of time needed for any ASIC is spent on
verification/validation/testing. Even though the above facts are well known to most ASIC
engineers, still engineers think that there is no glory in verification.
I have picked up some examples from the VLSI classes that I used to teach during 1999-
2001, when I was in Chennai. Please feel free to give your feedback on how to improve
the tutorial below.
Before you Start
For writing testbenches it is important to have the design specification of "design under
test" or simply DUT. Specs need to be understood clearly and a test plan, which basically
documents the test bench architecture and the test scenarios (test cases) in detail, needs to
be made.
Example - Counter
Let's assume that we have to verify a simple 4-bit up counter, which increments its count
whenever enable is high, and resets to zero when reset is asserted high. Reset is
synchronous to clock.
Code for Counter
1 //-----------------------------------------------------
2 // Design Name : counter
3 // File Name : counter.v
4 // Function : 4 bit up counter
5 // Coder : Deepak
6 //-----------------------------------------------------
7 module counter (clk, reset, enable, count);
8 input clk, reset, enable;
9 output [3:0] count;
10 reg [3:0] count;
11
13 if (reset == 1'b1) begin
14 count <= 0;
15 end else if ( enable == 1'b1) begin
16 count <= count + 1;
17 end
18
19 endmodule
You could download file counter.v here
Test Plan
We will write a self-checking test bench, but we will do this in steps to help you
understand the concept of writing automated test benches. Our testbench environment
will look something like the figure below.
DUT is instantiated in the testbench, and the testbench will contain a clock generator,
reset generator, enable logic generator and compare logic, which basically calculates the
expected count value of counter and compares it with the output of counter.
Test Cases
• Reset Test : We can start with reset de-asserted, followed by asserting reset for
few clock ticks and deasserting the reset, See if counter sets its output to zero.
• Enable Test : Assert/deassert enable after reset is applied.
• Random Assert/deassert of enable and reset.
We can add some more test cases; but we are not here to test the counter, rather to learn
how to write test benches.
Memory Modeling
To help modeling of memory, Verilog provides support for two dimensions arrays.
Behavioral models of memories are modeled by declaring an array of register variables;
any word in the array may be accessed using an index into the array. A temporary
variable is required to access a discrete bit within the array.
Syntax
reg [wordsize:0] array_name [0:arraysize]
Examples
Declaration
reg [7:0] my_memory [0:255];
Here [7:0] is the memory width and [0:255] is the memory depth with the following
parameters:
• Width : 8 bits, little endian

• Depth : 256, address 0 corresponds to location 0 in the array.
Storing Values
my_memory[address] = data_in;
Reading Values
data_out = my_memory[address];
Bit Read
Sometimes there may be need to read just one bit. Unfortunately Verilog does not allow
to read or write only one bit: the workaround for such a problem is as shown below.
data_out = my_memory[address];
data_out_it_0 = data_out[0];
Initializing Memories
A memory array may be initialized by reading memory pattern file from disk and storing
it on the memory array. To do this, we use system tasks $readmemb and $readmemh.
$readmemb is used for binary representation of memory content and $readmemh for hex
representation.
Syntax
$readmemh("file_name",mem_array,start_addr,stop_addr);
Note : start_addr and stop_addr are optional.
Example - Simple memory
1 module memory();
2 reg [7:0] my_memory [0:255];
3
4 initial begin
5 $readmemh("memory.list", my_memory);
6 end
7 endmodule
You could download file memory.v here
Example - Memory.list file
1 //Comments are allowed

2 1100_1100 // This is first address i.e 8'h00
3 1010_1010 // This is second address i.e 8'h01
4 @ 55 // Jump to new address 8'h55
5 0101_1010 // This is address 8'h55
6 0110_1001 // This is address 8'h56
You could download file memory.list here
$readmemh system task can also be used for reading testbench vectors. I will cover this
in detail in the test bench section ... when I find time.
Refer to the examples section for more details on different types of memories.
Introduction
Let's assume that we have a design which requires us to have counters of various width,
but with the same functionality. Maybe we can assume that we have a design which
requires lots of instants of different depth and width of RAMs of similar functionality.
Normally what we do is creating counters of different widths and then use them. The
same rule applies to the RAM we talked about.
But Verilog provides a powerful way to overcome this problem: it provides us with
something called parameter; these parameters are like constants local to that particular
module.
We can override the default values, either using defparam or by passing a new set of
parameters during instantiation. We call this parameter overriding.
Parameters
A parameter is defined by Verilog as a constant value declared within the module

structure. The value can be used to define a set of attributes for the module which can
characterize its behavior as well as its physical representation.
• Defined inside a module.

• Local scope.
• Maybe overridden at instantiation time.
o If multiple parameters are defined, they must be overridden in the order
they were defined. If an overriding value is not specified, the default
parameter declaration values are used.
• Maybe changed using the defparam statement.
Parameter Override using defparam
1 module secret_number;
2 parameter my_secret = 0;
3
4 initial begin
5 $display("My secret number is %d", my_secret);
6 end
7
8 endmodule
9
10 module defparam_example();
11
12 defparam U0.my_secret = 11;
13 defparam U1.my_secret = 22;
14
15 secret_number U0();
16 secret_number U1();
17
18 endmodule
You could download file defparam_example.v here
Parameter Override during instantiating.
1 module secret_number;
2 parameter my_secret = 0;
3
4 initial begin
5 $display("My secret number in module is %d", my_secret);
6 end
7
8 endmodule
9
10 module param_overide_instance_example();
11
12 secret_number #(11) U0();
13 secret_number #(22) U1();
14
15 endmodule
You could download file param_overide_instance_example.v here
Passing more than one parameter
1 module ram_sp_sr_sw (
2 clk , // Clock Input
3 address , // Address Input
4 data , // Data bi-directional
5 cs , // Chip Select
6 we , // Write Enable/Read Enable
7 oe // Output Enable
8 );
9
10 parameter DATA_WIDTH = 8 ;
11 parameter ADDR_WIDTH = 8 ;
12 parameter RAM_DEPTH = 1 << ADDR_WIDTH;
13 // Actual code of RAM here
14
15 endmodule
You could download file param_more_then_one.v here
When instantiating more than the one parameter, parameter values should be passed in
the order they are declared in the sub module.
1 module ram_controller ();//Some ports

2
3 // Controller Code
4
5 ram_sp_sr_sw #(16,8,256) ram(clk,address,data,cs,we,oe);
6
7 endmodule
You could download file param_more_then_one1.v here
Verilog 2001
In Verilog 2001, the code above will work, but the new feature makes the code more
readable and error free.
1 module ram_controller ();//Some ports

2
3 ram_sp_sr_sw #(
4 .DATA_WIDTH(16),
5 .ADDR_WIDTH(8),
6 .RAM_DEPTH(256)) ram(clk,address,data,cs,we,oe);
7
8 endmodule
You could download file param_more_then_one2.v here
Was this copied from VHDL?
What is logic synthesis ?
Logic synthesis is the process of converting a high-level description of design into an

optimized gate-level representation. Logic synthesis uses a standard cell library which
have simple cells, such as basic logic gates like and, or, and nor, or macro cells, such as
adder, muxes, memory, and flip-flops. Standard cells put together are called technology
library. Normally the technology library is known by the transistor size (0.18u, 90nm).
A circuit description is written in Hardware Description Language (HDL) such as

Verilog. The designer should first understand the architectural description. Then he
should consider design constraints such as timing, area, testability, and power.
We will see a typical design flow with a large example in the last chapter of Verilog
tutorial.
Life before HDL (Logic synthesis)
As you must have experienced in college, everything (all the digital circuits) is designed
manually. Draw K-maps, optimize the logic, draw the schematic. This is how engineers
used to design digital logic circuits in early days. Well this works fine as long as the
design is a few hundred gates.
Impact of HDL and Logic synthesis.
High-level design is less prone to human error because designs are described at a higher
level of abstraction. High-level design is done without significant concern about design
constraints. Conversion from high-level design to gates is done by synthesis tools, using
various algorithms to optimize the design as a whole. This removes the problem with
varied designer styles for the different blocks in the design and suboptimal designs. Logic
synthesis tools allow technology independent design. Design reuse is possible for
technology-independent descriptions.
What do we discuss here ?
When it comes to Verilog, the synthesis flow is the same as for the rest of the languages.
What we try to look in next few pages is how particular code gets translated to gates. As
you must have wondered while reading earlier chapters, how could this be represented in
Hardware ? An example would be "delays". There is no way we could synthesize delays,
but of course we can add delay to particular signals by adding buffers. But then this
becomes too dependent on synthesis target technology. (More on this in the VLSI
section).
First we will look at the constructs that are not supported by synthesis tools; the table
below shows the constructs that are supported by the synthesis tool.
Introduction
Verilog PLI (Programming Language Interface) is a mechanism to invoke C or C++

functions from Verilog code.
The function invoked in Verilog code is called a system call. An example of a built-in
system call is $display, $stop, $random. PLI allows the user to create custom system
calls, something that Verilog syntax does not allow us to do. Some of these are:-
• Power analysis.
• Code coverage tools.
• Modifying the Verilog simulation data structure - more accurate delays.
• Custom output displays.
• Co-simulation.
• Design debug utilities.
• Simulation analysis.
• C-model interface to accelerate simulation.
• Testbench modeling.
To achieve these applications of PLI, C code should have access to the internal data
structure of Verilog simulator. To facilitate this Verilog PLI provides something called
acc routines or simply access routines.
There is a second set of routines, which are called tf routines, or simply task and function
routines. The tf and acc are PLI 1.0 routines and are very vast and very old. The next set
of routines, which was introduced with the latest release of Verilog 2001 is called vpi
routines. These are small and crystal clear PLI routines and thus the new version PLI 2.0.
You can get Verilog 2001 LRM or PLI 1.0 IEEE document for details of each and every
function provided. Verilog IEEE LRMs are written in such a way that anyone with
hardware background can understand. If you are unable to get hold of the above IEEE
docs, then you can buy the PLI books listed in books section.
How it Works
• Write the functions in C/C++ code.

• Compile them to generate shared libs (*.DLL in Windows and *.so in UNIX).
Simulator like VCS allows static linking.
• Use these Functions in Verilog code (Mostly Verilog Testbench).
• Based on simulator, pass the C/C++ function details to simulator during compile
process of Verilog Code (This is called linking, and you need to refer to the
simulator user guide to understand how this is done).
• Once linked just run the simulator like any other Verilog simulation.
During execution of the Verilog code by the simulator, whenever the simulator
encounters user defined system tasks (the ones which start with $), the execution control
is passed to the PLI routine (C/C++ function).
Example - Hello World
We will define a function hello, which when called will print "Hello Deepak". This
example does not use any of the PLI standard functions (ACC, TF and VPI). For exact
linking details, please refer to simulator manuals. Each simulator implements its own way
for linking C/C++ functions to simulator.
C Code
1 #include <stdio.h>
2
3 void hello () {
4 printf ("\nHello Deepak\n");
5 }
You could download file hello.c here
Verilog Code
1 module hello_pli ();

2
3 initial begin
4 $hello;
5 #10 $finish;
6 end
7
8 endmodule
You could download file hello_pli.v here
Running the Simulation
Once linking is done, simulation is run as a normal simulation as we saw earlier, with
slight modification to the command line options: we need to tell the simulator that we are
using PLI (Modelsim needs to know which shared objects to load in the command line).
Introduction
Well most of the changes in Verilog 2001 are picked from other languages, like generate,
configuration, file operation were from VHDL. I am just adding a list of the most
commonly used Verilog 2001 changes. You may need a simulator with Verilog 2001
support for testing the examples listed below.
Comma used in sensitive list
In earlier version of Verilog ,we used to use 'or' to specify more than one sensitivity list
element. In the case of Verilog 2001, we use comma as shown in the example below.
1 module comma_example();
2
3 reg a, b, c, d, e;
4 reg [2:0] sum, sum95;
5
6 // Verilog 2k example for usage of comma
7 always @ (a, b, c, d, e)
8 begin : SUM_V2K
9 sum = a + b + c + d + e;
10 end
11
12 // Verilog 95 example for above code
13 always @ (a or b or c or d or e)
14 begin : SUM_V95
15 sum95 = a + b + c + d + e;
16 end
17
18 initial begin
19 $monitor ("%g a=%b b=%b c=%b d=%b e=%b sum=%b sum95=%b",
20 $time, a, b, c, d, e, sum, sum95);
21 #1 a = 1;
22 #1 b = 1;
23 #1 c = 1;
24 #1 d = 1;
25 #1 e = 1;
26 #1 $finish;
27 end
28
29 endmodule
You could download file comma_example.v here
We can use the same for edge sensitive code also, as shown in the code below.
1 module comma_edge_example();
2
3 reg clk, reset, d;
4 reg q, q95;
5
6 // Verilog 2k example for usage of comma
7 always @ (posedge clk, posedge reset)
8 begin : V2K
9 if (reset) q <= 0;
10 else q <= d;
11 end
12
14 always @ (posedge clk or posedge reset)
15 begin : V95
16 if (reset) q95 <= 0;
17 else q95 <= d;
18 end
19
20 initial begin
21 $monitor ("%g clk=%b reset=%b d=%b q=%b q95=%b",
22 $time, clk, reset, d, q, q95);
23 clk = 0;
24 reset = 0;
25 d = 0;
26 #4 reset = 1;
27 #4 reset = 0;
28 #1 d = 1;
29 #10 $finish;
30 end
31
32 initial #1 forever clk = #1 ~clk;
33
34 endmodule
You could download file comma_edge_example.v here
Combinational logic sensitive list
Verilog 2001 allows us to use star in sensitive list instead of listing all the variables in
RHS. This removes typo mistakes and thus avoids simulation and synthesis mismatches.
1 module star_example();
2
3 reg a, b, c, d, e;
4 reg [2:0] sum, sum95;
5
6 // Verilog 2k example for usage of star for combo logic
7 always @ (*)
8 begin : SUM_V2K
9 sum = a + b + c + d + e;
10 end
11
13 always @ (a or b or c or d or e)
14 begin : SUM_V95
15 sum95 = a + b + c + d + e;
16 end
17
18 initial begin
19 $monitor ("%g a=%b b=%b c=%b d=%b e=%b sum=%b sum95=%b",
20 $time, a, b, c, d, e, sum, sum95);
21 #1 a = 1;
22 #1 b = 1;
23 #1 c = 1;
24 #1 d = 1;
25 #1 e = 1;
26 #1 $finish;
27 end
28
29 endmodule
You could download file star_example.v here
Wire Data type
In Verilog 1995, default data type is net and its width is always 1 bit. In Verilog 2001 the
width is adjusted automatically.
In Verilog 2001, we can disable default data type by `default net_type none, This
basically helps in catching the undeclared wires.
Register Data type
Register data type is called variable, as it created a lot of confusion for beginners. Also it
is possible to specify an initial value for the register/variable data type. Reg data type can
also be declared as signed.
1 module v2k_reg();
2
3 // v2k allows to init variables
4 reg a = 0;
5 // Here only last variable is set to 0, i.e d = 0
6 // Rest b, c are set to x
7 reg b, c, d = 0;
8 // reg data type can be signed in v2k
9 // We can assign with signed constants
10 reg signed [7:0] data = 8'shF0;
11
12 // Function can return signed values
13 // Its ports can contain signed ports
14 function signed [7:0] adder;
15 input a_in;
16 input b_in;
17 input c_in;
18 input signed [7:0] data_in;
19 begin
20 adder = a_in + b_in + c_in + data_in;
21 end
22 endfunction
23
24 endmodule
You could download file v2k_reg.v here
New operators
Verilog 2001 introduced two new operator that are of interest to designers. They are
• <<< : Shift left, to be used on signed data type

• >>> : shift right, to be used on signed data type
• ** : exponential power operator.
Signed shift operator
1 module signed_shift();
2
3 reg [7:0] unsigned_shift;
4 reg [7:0] signed_shift;
5 reg signed [7:0] data = 8'hAA;
6
7 initial begin
8 unsigned_shift = data >> 4;
9 $display ("unsigned shift = %b", unsigned_shift);
10 signed_shift = data >>> 4;
11 $display ("signed shift = %b", signed_shift);
12 unsigned_shift = data << 1;
13 $display ("unsigned shift = %b", unsigned_shift);
14 signed_shift = data <<< 1;
15 $display ("signed shift = %b", signed_shift);
16 $finish;
17 end
18
19 endmodule
You could download file signed_shift.v here
Power operator
1 module power_operator();
2
3 reg [3:0] base = 2;
4 reg [5:0] exponent = 1;
5 reg [31:0] result = 0;
6
7 initial begin
8 $monitor ("base = %d exponent = %d result = %d", base, exponent,
result);
9 repeat (10) begin
10 #1 exponent = exponent + 1;
11 end
12 #1 $finish;
13 end
14
15 always @ (*)
16 begin
17 result = base ** exponent;
18 end
19
20 endmodule
You could download file power_operator.v here
Port Declaration
Verilog 2001 allows port direction and data type in the port list of modules as shown in
the example below.
1 module ansiport_example();
2
3 reg read,write = 0;
4 reg [7:0] data_in = 0;
5 reg [3:0] addr = 0;
6 wire [7:0] data_v95, data_notype, data_ansi;
7
8 initial begin
9 $monitor (
10 "%g rd=%b wr=%b addr=%b data_in=%h data_v95=%h data_notype=%h
data_ansi=%h"
11 , $time, read, write, addr, data_in, data_v95, data_notype,
data_ansi);
12 #1 read = 0; // why only for read ?
13 #3 repeat (16) begin
14 data_in = $random;
15 write = 1;
16 #1 addr = addr + 1;
17 end
18 write = 0;
19 addr = 0;
20 #3 repeat (16) begin
21 read = 1;
22 #1 addr = addr + 1;
23 end
24 read = 0;
25 #1 $finish;
26 end
27
28 memory_v95 U (read, write, data_in, addr, data_v95);
29 memory_ansi_notype W (read, write, data_in, addr, data_notype);
30 memory_ansi V (read, write, data_in, addr, data_ansi);
31
32 endmodule
33 // Verilog 95 code
34 module memory_v95 ( read, write, data_in, addr, data_out);
35 input read;
36 input write;
37 input [7:0] data_in;
38 input [3:0] addr;
39 output [7:0] data_out;
40
41 reg [7:0] data_out;
42 reg [7:0] mem [0:15];
43
44 always @ (*)
45 begin
46 if (write) mem[addr] = data_in;
47 end
48
49 always @ (read, addr)
50 begin
51 if (read) data_out = mem[addr];
52 end
53
54 endmodule
55
56 // Verilog 2k with notype in port list
57 module memory_ansi_notype (
58 input read,
59 input write,
60 input [7:0] data_in,
61 input [3:0] addr,
62 output [7:0] data_out
63 );
64 reg [7:0] mem [0:15];
65
66 always @ (*)
67 begin
69 end
70
71 assign data_out = (read) ? mem[addr] : 0;
72
73 endmodule
74
75 // Verilog 2k with width and data type listed
76 module memory_ansi (
77 input wire read,
78 input wire write,
79 input wire [7:0] data_in,
80 input wire [3:0] addr,
81 output reg [7:0] data_out
82 );
83
84 reg [7:0] mem [0:15];
85
86 always @ (*)
87 begin
89 end
90
91 always @ (read, addr)
92 begin
93 if (read) data_out = mem[addr];
94 end
95
96 endmodule
You could download file ansiport_example.v here

Introduction
Verification with assertions refers to the use of an assertion language to specify expected
behavior in a design, and of tools that evaluate the assertions relative to the design under
verification.
Assertion-based verification is mostly useful to design and verification engineers who are
responsible for the RTL design of digital blocks and systems. ABV lets design engineers
capture verification information during design. It also enables internal state, datapath, and
error precondition coverage analysis.
Simple example of assertion could be a FIFO: whenever a FIFO is full and a write
happens, it is illegal. So a FIFO designer can write an assertion which checks for this
condition and asserts failure.
Assertions Languages
Currently there are multiple ways available for writing assertions as shown below.
• Open Verification Library (OVL).

• Formal Property Language Sugar
• SystemVerilog Assertions
Most assertions can be written in HDL, but HDL assertions can be lengthy and
complicated. This defeats the purpose of assertions, which is to ensure the correctness of
the design. Lengthy, complex HDL assertions can be hard to create and subject to bugs
themselves.
In this tutorial we will be seeing verilog based assertion (OVL) and PSL (sugar).
Advantages of using assertions
• Testing internal points of the design, thus increasing observability of the design.
• Simplifying the diagnosis and detection of bugs by constraining the occurrence of
a bug to the assertion monitor being checked.
• Allowing designers to use the same assertions for both simulation and formal
verification.
Implementing assertion monitors
Assertion monitors address design verification concerns and can be used as follows to
increase design confidence.
• Combine assertion monitors to increase the coverage of the design (for example,
in interface circuits and corner cases).
• Include assertion monitors when a module has an external interface. In this case,
assumptions on the correct input and output behavior should be guarded and
verified.
• Include assertion monitors when interfacing with third party modules, since the
designer may not be familiar with the module description (as in the case of IP
cores), or may not completely understand the module. In these cases, guarding the
module with assertion monitors may prevent incorrect use of the module.
Normally assertions are implemented by the designers to safeguard their design, so they
code the assertions into their RTL. A simple example of an assertion would be: writing
into FIFO, when it is full. Traditionally verification engineers have been using assertions
in their verification environments without knowing that they are assertions. For
verification a simple application of assertions would be checking protocols. Example:
expecting the grant of an arbiter to be asserted after one clock cycle and before two
cycles after the assertion of request.
In the next few pages we will see simple examples on usage of assertions using Open
Verification Library and PSL assertions.
What You Need?
For using Open Verification Library examples you need Open Verification Library from
Accellera. For running PSL examples you need a simulator that can support PSL.
Then you need a bit of patience to go through the manuals to learn in details Assertions
and try out more examples.
space.gif
../images/main/bullet_green_ball.gif Verilog Quick Reference
This is still in very early stage, need time to add more on this.
space.gif
../images/main/bulllet_4dots_orange.gif MODULE
module MODID[({PORTID,})];
[input | output | inout [range] {PORTID,};]
[{declaration}]
[{parallel_statement}]
[specify_block]
endmodule
range ::= [constexpr : constexpr]
space.gif
../images/main/bulllet_4dots_orange.gif DECLARATIONS
parameter {PARID = constexpr,};
wire | wand | wor [range] {WIRID,};
reg [range] {REGID [range],};
integer {INTID [range],};
time {TIMID [range],};
real {REALID,};
realtime {REALTIMID,};
event {EVTID,};
task TASKID;
[{input | output | inout [range] {ARGID,};}]
[{declaration}]
begin
[{sequential_statement}]
end
endtask
function [range] FCTID;
{input [range] {ARGID,};}
[{declaration}]
begin
end
endfunction
space.gif
../images/main/bulllet_4dots_orange.gif PARALLEL STATEMENTS
assign [(strength1, strength0)] WIRID = expr;
initial sequential_statement
always sequential_statement
MODID [#({expr,})] INSTID
([{expr,} | {.PORTID(expr),}]);
GATEID [(strength1, strength0)] [#delay]
[INSTID] ({expr,});
defparam {HIERID = constexpr,};
strength ::= supply | strong | pull | weak | highz
delay ::= number | PARID | ( expr [, expr [, expr]] )
space.gif
../images/main/bulllet_4dots_orange.gif GATE PRIMITIVES
and (out, in1, ..., inN);
nand (out, in1, ..., inN);
or (out, in1, ..., inN);

nor (out, in1, ..., inN);
xor (out, in1, ..., inN);
xnor (out, in1, ..., inN);
buf (out1, ..., outN, in);
not (out1, ..., outN, in);
bufif1 (out, in, ctl);
bufif0 (out, in, ctl);
notif1 (out, in, ctl);
notif0 (out, in, ctl);
pullup (out);
pulldown (out);
[r]pmos (out, in, ctl);
[r]nmos (out, in, ctl);
[r]cmos (out, in, nctl, pctl);
[r]tran (inout, inout);

[r]tranif1 (inout, inout, ctl);
[r]tranif0 (inout, inout, ctl);
space.gif
../images/main/bulllet_4dots_orange.gif SEQUENTIAL STATEMENTS
begin[: BLKID
[{declaration}]]
end
if (expr) sequential_statement
[else sequential_statement]
case | casex | casez (expr)
[{{expr,}: sequential_statement}]
[default: sequential_statement]
endcase
forever sequential_statement
repeat (expr) sequential_statement
while (expr) sequential_statement
for (lvalue = expr; expr; lvalue = expr)
sequential_statement
#(number | (expr)) sequential_statement
@ (event [{or event}]) sequential_statement
lvalue [<]= [#(number | (expr))] expr;
lvalue [<]= [@ (event [{or event}])] expr;wait (expr) sequential_statement
-> EVENTID;
fork[: BLKID
[{declaration}]]
join
TASKID[({expr,})];
disable BLKID | TASKID;

assign lvalue = expr;
deassign lvalue;
lvalue ::=
ID[range] | ID[expr] | {{lvalue,}}
event ::= [posedge | negedge] expr
space.gif
../images/main/bulllet_4dots_orange.gif SPECIFY BLOCK
specify_block ::= specify
{specify_statement}
endspecify
space.gif
../images/main/bulllet_4dots_orange.gif SPECIFY BLOCK STATEMENTS
specparam {ID = constexpr,};
(terminal => terminal) = path_delay;
((terminal,} *> {terminal,}) = path_delay;
if (expr) (terminal [+|-]=> terminal) = path_delay;
if (expr) ({terminal,} [+|-]*> {terminal,}) =

path_delay;
[if (expr)] ([posedge|negedge] terminal =>
(terminal [+|-]: expr)) = path_delay;
[if (expr)] ([posedge|negedge] terminal *>
({terminal,} [+|-]: expr)) = path_delay;
$setup(tevent, tevent, expr [, ID]);
$hold(tevent, tevent, expr [, ID]);
$setuphold(tevent, tevent, expr, expr [, ID]);
$period(tevent, expr [, ID]);
$width(tevent, expr, constexpr [, ID]);
$skew(tevent, tevent, expr [, ID]);
$recovery(tevent, tevent, expr [, ID]);
tevent ::= [posedge | negedge] terminal
[&&& scalar_expr]
path_delay ::=
expr | (expr, expr [, expr [, expr, expr, expr]])
terminal ::= ID[range] | ID[expr]
space.gif
../images/main/bulllet_4dots_orange.gif EXPRESSIONS
primary
unop primary
expr binop expr
expr ? expr : expr
primary ::=
literal | lvalue | FCTID({expr,}) | ( expr )
space.gif
space.gif
../images/main/bulllet_4dots_orange.gif UNARY OPERATORS
+, - Positive, Negative
! Logical negation
~ Bitwise negation
&, ~& Bitwise and, nand

|, ~| Bitwise or, nor
^, ~^, ^~ Bitwise xor, xnor
space.gif
../images/main/bulllet_4dots_orange.gif BINARY OPERATORS
Increasing precedence:
?: if/else
|| Logical or
&& Logical and
| Bitwise or
^, ^~ Bitwise xor, xnor
& Bitwise and
==, != , ===, !== Equality
<, <=, >, >= Inequality
<<, >> Logical shift
+, - Addition, Subtraction
*, /, % Multiply, Divide, Modulo

space.gif
../images/main/bulllet_4dots_orange.gif SIZES OF EXPRESSIONS
unsized constant 32
sized constant as specified
i op j +,-,*,/,%,&,|,^,^~ max(L(i), L(j))
op i +, -, ~ L(i)
i op j ===, !==, ==, !=
&&, ||, >, >=, <, <= 1
op i &, ~&, |, ~|, ^, ~^ 1
i op j >>, << L(i)
i ? j : k max(L(j), L(k))
{i,...,j} L(i) + ... + L(j)
{i{j,...k}} i * (L(j)+...+L(k))
i = j L(i)
space.gif
../images/main/bullet_green_ball.gif SYSTEM TASKS
* indicates tasks not part of the IEEE standard
but mentioned in the informative appendix.
space.gif
../images/main/bulllet_4dots_orange.gif INPUT
$readmemb("fname", ID [, startadd [, stopadd]]);
$readmemh("fname", ID [, startadd [, stopadd]]);
$sreadmemb(ID, startadd, stopadd {, string});
$sreadmemh(ID, startadd, stopadd {, string});
space.gif
../images/main/bulllet_4dots_orange.gif OUTPUT
$display[defbase]([fmtstr,] {expr,});
$write[defbase] ([fmtstr,] {expr,});
$strobe[defbase] ([fmtstr,] {expr,});
$monitor[defbase] ([fmtstr,] {expr,});
$fdisplay[defbase] (fileno, [fmtstr,] {expr,});
$fwrite[defbase] (fileno, [fmtstr,] {expr,});
$fstrobe(fileno, [fmtstr,] {expr,});

$fmonitor(fileno, [fmtstr,] {expr,});
fileno = $fopen("filename");
$fclose(fileno);
defbase ::= h | b | o
space.gif
../images/main/bulllet_4dots_orange.gif TIME
$time "now" as TIME
$stime "now" as INTEGER
$realtime "now" as REAL
$scale(hierid) Scale "foreign" time value
$printtimescale[(path)] Display time unit & precision
$timeformat(unit#, prec#, "unit", minwidth)
Set time %t display format
space.gif
../images/main/bulllet_4dots_orange.gif SIMULATION CONTROL
$stop Interrupt
$finish Terminate
$save("fn") Save current simulation
$incsave("fn") Delta-save since last save
$restart("fn") Restart with saved simulation
$input("fn") Read commands from file
$log[("fn")] Enable output logging to file
$nolog Disable output logging
$key[("fn")] Enable input logging to file
$nokey Disable input logging
$scope(hiername) Set scope to hierarchy
$showscopes Scopes at current scope
$showscopes(1) All scopes at & below scope
$showvars Info on all variables in scope
$showvars(ID) Info on specified variable
$countdrivers(net)>1 driver predicate
$list[(ID)] List source of [named] block

$monitoron Enable $monitor task
$monitoroff Disable $monitor task
$dumpon Enable val change dumping
$dumpoff Disable val change dumping
$dumpfile("fn") Name of dump file
$dumplimit(size) Max size of dump file
$dumpflush Flush dump file buffer
$dumpvars(levels [{, MODID | VARID}])
Variables to dump
$dumpall Force a dump now
$reset[(0)] Reset simulation to time 0
$reset(1) Reset and run again
$reset(0|1, expr) Reset with reset_value*$reset_value Reset_value of last $reset
$reset_count # of times $reset was used
space.gif
../images/main/bulllet_4dots_orange.gif MISCELLANEOUS
$random[(ID)]
$getpattern(mem) Assign mem content
$rtoi(expr) Convert real to integer
$itor(expr) Convert integer to real
$realtobits(expr) Convert real to 64-bit vector
$bitstoreal(expr) Convert 64-bit vector to real
space.gif
../images/main/bulllet_4dots_orange.gif ESCAPE SEQUENCES IN
FORMAT STRINGS
\n, \t, \\, \" newline, TAB, "\", """
\xxx character as octal value
%% character "%"
%[w.d]e, %[w.d]E display real in scientific form
%[w.d]f, %[w.d]F display real in decimal form
%[w.d]g, %[w.d]G display real in shortest form
%[0]h, %[0]H display in hexadecimal
%[0]d, %[0]D display in decimal

%[0]o, %[0]O display in octal
%[0]b, %[0]B display in binary
%[0]c, %[0]C display as ASCII character
%[0]v, %[0]V display net signal strength
%[0]s, %[0]S display as string
%[0]t, %[0]T display in current time format
%[0]m, %[0]M display hierarchical name
space.gif
../images/main/bulllet_4dots_orange.gif LEXICAL ELEMENTS
hierarchical identifier ::= {INSTID .} identifier
identifier ::= letter | _ { alphanumeric | $ | _}
escaped identifer ::= \ {nonwhite}
decimal literal ::=
[+|-]integer [. integer] [E|e[+|-] integer]
based literal ::= integer " base {hexdigit | x | z}
base ::= b | o | d | h
comment ::= // comment newline
comment block ::= /* comment */
space.gif

You Could Download File D - FF.V

Uploaded by

Document Informationclick to expand document information

Copyright:

Available Formats

You Could Download File D - FF.V

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

You Could Download File D - FF.V

Uploaded by

Copyright:

Available Formats

Introduction

Verilog is a HARDWARE DESCRIPTION LANGUAGE (HDL). A hardware

Verilog Abstraction Levels

This level describes a system by concurrent algorithms (Behavioral). Each algorithm

Designs using the Register-Transfer Level specify the characteristics of a circuit by

Block diagram of arbiter

Code of module "arbiter"

inout read_enable; // port named read_enable is bi-directional

Vector Signals Example -

inout [7:0] address; //port "address" is bidirectional

But wait... hardware does have two kinds of drivers.

(Drivers? What are those?)

• Driver that can store a value (example: flip-flop).

wire and_gate_output; // "and_gate_output" is a wire that only outputs

reg d_flip_flop_output; // "d_flip_flop_output" is a register; it stores and outputs a value

reg [7:0] address_bus; // "address_bus" is a little-endian 8-bit register

• Wire data type is used for connecting two points.

• a = b + c ; // That was very easy

Verilog was started initially as a proprietary hardware modeling language by Gateway

Various stages of ASIC/FPGA

• Specification : Word processor like Word, Kwriter, AbiWord, Open Office.

Figure : I8155 High Level Block Diagram

Micro Design/Low level design

Figure : Sample Testbench Env

Figure : 4 bit Up Counter Waveform

• Formal Verification : Check if the RTL to gate mapping is correct.

Place & Route

Figure : J-K Flip-Flop

Post Silicon Validation

Hello World Program

Hello World Program Output

Hello World by Deepak

Counter Design Block

Counter Design Specs

• 4-bit synchronous up counter.

Counter Test Bench

time clk reset enable counter

Examples of White Spaces

Functional Equivalent Code

Bad Code : Never write code like this.

Good Code : Nice way to write code.

There are two forms to introduce comments.

Verilog HDL is case sensitive

• Lower case letters are unique from upper case letters

Examples of Unique names

1 input // a Verilog Keyword

Examples of legal identifiers

• Escaped identifiers begin with the back slash ( \ )

Examples of escape identifiers

1 // There must be white space after the

Verilog HDL allows integer numbers to be specified as

• Sized or unsized numbers (Unsized size is 32 bits)

Example of Integer Numbers

Example of Integer Numbers

• Verilog supports real constants and variables

Example of Real Numbers

Real Number Decimal notation

Signed and Unsigned Numbers