CENTER OF EXCELLENCE

ADVANCED PROGRAM IN ELECTRONIC AND

COMMUNICATION ENGINEERING

LAB 1
An Introduction to Modeling, Verilog, and Real World Digital Parts

1. Project Objective:
The objectives of this lab are the following:
 To begin to learn to work with data sheets for digital components..
 To learn some of the behaviors of real world logic components and how these
may vary within the range of the specifications given in the data sheets. These
really aren’t like the textbook parts which are a good ideal model…
 To begin to learn the Verilog Hardware Description Language
 To begin to learn to use a modeling language like Verilog to aid in the design of
complex digital systems.
 To learn to develop a test bench and to formulate then run tests on a gate-level
structural model of a system that we are designing. Note, we will use only
structural Verilog in all labs this term.
 To begin to learn to move our design from the modeled version to a real world
implementation in a programmable part.
 To introduce the Altera’s Terasic DE1 development board.
 To learn that the job sometimes takes longer than we think it will.
2. Project Scope:
To meet project requirements, you will need to:
a. Get used with Instrument and Tools for Digital System Design and Analysis.
b. Get through data sheets for some devices.
c. Warm up core and background knowledge and comprehend Verilog language.
d. Draw logic diagram, build truth table and analyze the stimulation results.
3. Lab description:
In this first lab project, we’re going to be doing a lot of things, probably for the
first time for most. Our goal is to introduce the material, some of the tools, and the
concepts that we’ll be working with this term and that we’ll use to design and
develop modern (embedded) digital systems that we find in nearly every commercial
product today.
We strongly encourage you to read the entire lab specification before starting any
work. This is important. However, do not feel over whelmed; we are here to work
with you and we certainly do not expect you to be an expert in everything by the end
of this first project. We do want you to start to become familiar with the ideas,
though.
3.1 Prerequisites:
You must have some typing and programming experience. A basic understanding
of electronics that you will have gotten in your physics classes. You should
understand voltage, current, resistance, and Ohm's law. You must also have some
introduction to Boolean algebra.
3.2 Cautions and Warnings:
Never try to run your circuit with the power turned off. Under such
circumstances, the results are generally less than satisfying.
Since current is dq/dt, if you are running low on current, raise your circuit board
to about the same level as the power supply and use short leads. This has the affect
of reducing the dt in the denominator and giving you more current.
If your circuit is turning on too slowly, lower your breadboard so that it is
substantially below the power supply. This enables the charge to get a running start
before coming into your board. It will now turn on much faster.
Throwing your completed but malfunctioning implementation on the floor,
stomping on it, and screaming ‘work you stupid fool, work’ is typically not the most
effective debugging technique although it is perhaps one of the more satisfying.
When you are debugging you circuit, wiring it, taking it apart, and rewiring again
several dozen times does little to fix what may be a design error. Such an approach
is not highly recommended, but, can keep you entertained for hours….particularly if
you can convince your partner to do it.
Sometimes - but only in the most dire of situations – sacrificing small animals to
the smoke demon living in your circuit does work. However, these are not
included in your lab kit and must be purchased separately from an outside vendor.
Also, be aware that code gremlins are not affected by such sacrifices.
Alternately, blaming your lab partner can work for a short time…until everyone
finds out that you are really to blame.
 Always keep only a single copy of your Verilog code. This ensures that you will
always have a maximum amount of disk space available for games, email, and some
interesting pictures. If a code eating gremlin happens to destroy your only copy, not
to worry, you can always retype and debug it again.
3.3 Instruments and Tools for Digital System Design and
Analysis
There are some helpful traditional instruments and tools that we
will be using in this lab and then when we start working as
practicing engineers.
Digital Multimeter (DMM) / Digital Volt Meter (DVM) Digital Voltmeter
A typical handheld DMM is shown in figure 1. The DMM is a Figure 1
very useful instrument when you are analyzing electronic circuits.
It can be used to check whether or not a certain DC voltage is applied or has the
expected value.
Although you can use a DVM for AC voltages, AC and DC currents, and
resistance as well as DC voltages, to be able to see and truly understand what is going
on in a digital circuit, you must use an oscilloscope or logic analyzer.
Oscilloscope
A multimeter is a useful tool for looking at the value of a
(typically DC) signal. To be able to see how a signal is
changing in time or to analyze its waveform, we must use an
oscilloscope. A Tektronix instrument is shown in figure 2.
Altera Terasic DE1 Development Board
The Altera Development board is typical of the
environments with which one might work during the design,
development, and test of many contemporary digital systems. Oscilloscope
The environment supports a variety of different kinds of Figure 2
components that, during the later phases of a project
development, will be migrated to a system board that will be integrated into the
completed design.
 The picture in figure 3 shows the DE1 board with most of the major components
highlighted. We will be using the various input/output devices located directly on
the board such as the switches and LEDs. Further details will be provided in each
lab. Take note of the large FPGA (Field Programmable Gate Array) that is
highlighted on the board. Later on in the term we will be programming this and
directly interfacing with many the devices on the board. Think of it like a universal
logic unit that all the devices can talk to. For now there is a program loaded into the

DE1 Development Board

Figure 3

FPGA to allow you to use the Input/Output connectors on the board to make the
earlier labs easier.
The FPGA
FPGA is an acronym for Field Programmable Gate Array. Essentially, it is a large
array of logical elements that have been connected together. However, in an FPGA,
the connections between these logical elements can be programmed and
reprogrammed. This means that it can be used to build many different kinds of
hardware all on the same chip.
OK, time to get to work…
3.4 Procedure:
3.4.1 Part 1: Modeling, Simulating, and Testing a Digital Comparator
In the first part of the lab project, we will begin to learn to develop models of our
systems as an integral step in the design process. We will start by working with the
Verilog hardware design language and the Icarus Verilog development environment.
Later, we will also utilize Altera’s Quartus development environment.
File Creation and Simulation
Using the background information provided on Verilog and Icarus, create a
Verilog source file (comparator.v, for example) containing the code provided in
Verilog Source Code Example in the Appendix B of this lab. Tutorial information
can be found online, given in Appendix A of this lab, given in the lab lectures, and
in Appendices A and B of your text.
Once the file has been written, run the Icarus compiler to synthesize your system
model then run your test bench and test vectors (your test inputs) to verify the
accuracy of your design. From your simulation, obtain the following,
1. A hardcopy of the source code that you developed.
2. A hardcopy of the result of running your test bench under Icarus.
NOTE: On your first pass, there may be a couple of simple errors in the program –
these are intentional. If so, use your compiler error messages to find them.
Each team member should complete the initial portion of part 1.
Build
To implement the system, we are going to use the Altera Cyclone II FPGA on
the DE 1 Board.
Although the Quartus tools support graphical entry, for our first design using the
DE 1 Board and Quartus environment, we are going to work with the Verilog code
that we have developed and tested up to this point.
All of that said, read through this section completely before starting your
implementation…
Important First Steps
 First scan through the DE1_user_manual:
This is a very good overview of the capabilities of the board and a handy
reference.
 Start with and follow Tutorial 1in Appendix B of our class text to see how
to get a new project started (also see Recommended Design Approach
below).
Specifically, first read sections B1, B2, and B4; then, from Appendix C,
read sections C1.1 and C1.2.
 The same information is presented in a slightly different form, in the
Altera tutorial in the DE1 tutorials in the document:
tut_quartus_intro_verilog.pdf.
 Bear in mind, that the devices in the Altera tutorial (s) are different from
ours, they may reference the DE2 board, and there may be some
information that we are not using at the moment.
Go through this document to get a step-by-step guided tour of developing
a Verilog entry project in the Quartus environment.
 After you have gone over the tutorials and other background material,
you’re ready to go.

Recommended Design Approach

Working with the two tutorials, we recommend the following general design
approach.
1. Create a new project.
Under the Quartus environment select File →New Project Wizard.
2. Add your Verilog source (no test bench, test module, or delays).
Follow the steps in the wizard and add your Verilog file to the project
It is important that the name of your Verilog file is the same as that
of your project and that the paths contain no spaces.
3. Synthesize your project.
Synthesize your project by selecting
Processing →Start Compilation.
4. Assign pins on the FPGA to your I/O signals
Follow the Altera Verilog tutorial (tut_quartus_intro_verilog.pdf) to
assign pins to all of your input and output signals. The pins associated
with each of the signals are given in the DE1_user_manual.
For now, we’ll take the longer approach. Later, we’ll use a much faster
method.
5. Compile your program once again now that you have assigned the pins
We compile twice because Quartus needs to first figure out the inputs
and outputs to our system. Once those are known, we can assign pins
to each then recompile with full information.
6. Download your project to the Altera chip
Follow the Altera Verilog tutorial (tut_quartus_intro_verilog.pdf) to
set up the JTAG interface to the DE1 board properly to support the
download.
Download your project by selecting Tools →Programmer.
 7. Your design should be running and working perfectly in its new home.

Debug and Test

Verify that your design meets all the requirements in the original
specification.
Part 1 Questions:
To complete part 1 of the lab, please answer the questions below:
1. Draw a logic diagram using the logic gates that were used to build the digital
circuit in the Verilog source code. Use the same signal names indicated in the
source code. Use AND, OR, and NOT gates.
2. Draw the truth table for this circuit. Looking at the waveform from your
simulation may help. A truth table for a logic circuit has an input side and an
output side. The input side lists all of the possible input combinations to the
circuit and the output side lists the value(s) of the output(s) for each input
combination. Figure 4 below shows the logic symbol and associated truth table
for an AND gate. The left hand side of the truth table elaborates all 4 possible
input combinations and the right hand side gives the corresponding output.

A C A C
B A B
AB C B AB C A B
00 0 00 0 0 1
AND Gate OR Gate Inverter
01 0 01 1 1 0
10 0 10 1
11 1 11 1

Figure 4

Figure 7

3. When you run theSeveral Logic Gates

simulation. Doesand
theTheir TruthofTables
output the Verilog program agree or
disagree with your truth table?
4. Please explain the apparently incorrect order in which the results in the output
log are printed; specifically when the output line “Producing Glitch” prints.
5. Change the value of the delay in the program from 10 to 0. Rerun the simulation.
Does the output of the Verilog program agree or disagree with your truth table?
Please explain any differences.
6. Change the delay in the program back to 10 time units. Change the stimDelay in
the test module to 5 time units. What affect does this change have on the outputs
of your simulation?
7. What advantages are there to using a program like Verilog? Name three or more.
Part 1 Report
Your report for part 1 must contain the following,
1. Each team member must include a copy his or her simulation results. Such
results must include source code, waveforms, and text file output.
Note, this does not mean one set of results duplicated three times.
2. One set of answers to all the questions from the team. The answers to the
questions must be typed. The diagrams must be done using a drawing tool
such as Visio.
3. One copy of the design and simulation results for the Comparator.

3.4.2 Part 2: Modeling, Simulating, and Testing a MultiFunction Logic Block

In part 1, we began with a known (almost) good Verilog model of a simple
system, a tester to exercise that system, and the test bench that combined the two.
We synthesized then confirmed the modeled behaviour of the system, and finally
implemented the system using the Altera FPGA. Let’s now repeat that process for
the MultiFunction Logic Block given in figure 5.
File Creation and Simulation
Using gate level Verilog, create the source code for a module that allows the
selection of 3 different 2-input logic functions: AND, OR, and XOR (See figure 5
and Table 1)

SEL1
SEL1 SEL2 RESULT
0 0 Result = A and B
SEL2 0 1 Result = A or B
1 0 Result = A xor B
1 1 Result = 0
A
B

RESULT

Table 1. Truth Table for Result

function
Figure 5
Logic Diagram for the MultiFunction Logic Block

As we saw in the first model, the Verilog module names for these gates are the same
as the gate type, except they should be in lower case. The inverter in Verilog is called
a not gate.
 Follow the circuit diagram and the selection assignments shown above.
  Create the source code for the gate-level (structural) model. To make life
easier, look to the sample Verilog code as an example.
 Use common sense in creating signal names, a person with no prior
knowledge of the lab should be able to tell them apart.
 Create a tester and a test bench then use these to confirm that the design
implements the truth table in table 1.
If the Verilog code from the Comparator design is used as a guide, do not use any
time delays, i.e.: omit the #delay from any gate instantiation. Use module, gate, and
signal names that reflect the current circuit, not those from the Comparator design.
Implementation and Test
After confirming the operation of the design, we now implement the circuit.
In the Quartus IDE, create a new project and enter your MultiFunction source
code file. Be certain not to include your test bench or test code. Assign pins to
connect each of the system inputs to one of the switches and, similarly, each of the
outputs to one of the LEDs on the DE1 board.
Confirm that the functionality of your design agrees with its truth table.
Part 2 Report
Your report for part 2 must contain the following,
1. A copy the Verilog source code for the MultiFunction Logic Block, the
testbench, and the tester.
2. A copy of the simulation results.

3.4.3 Part 3: Working with Real World Devices

Before we begin this portion of the lab, let's go over some of the parts that you
may need now and later in future classes, how they work, and how you will use them.
We'll look at switches, LEDs, the prototyping board, integrated circuit pin
numbering, and resistors.
Background
Using a Mechanical Switch to Model an Input Device
There are several ways that you can generate input signals to a digital system.
One primitive way is to connect wires with either logic "high" or a logic "low"
voltage. That can be really messy and dangerous (you may accidentally ground a
signal or apply a voltage in a wrong place). One better way is to use a mechanical
switch as an input device.
 There are several types of switches. Switches are often classified by the
number of "poles" and the number of "throws" they have. A pole is a lever arm
that provides a contact between two electrical terminals, and a throw is a contact
in which the switch can be positioned. For instance, a DIP switch, as shown
below, is a single-pole single-throw (SPST) switch since its single arm is making
contact in one position but not making contact in the other.
A lock switch (e.g.: the CAP LOCK key in old keyboards that actually lock in)
or a two-position lever-arm switch are considered a single-pole double-throw
Pole Pole
Throws
Throw
Normally Closed
Normally Open

Wiper Wiper

Single Pole - Single Throw Single Pole - Double Throw Double Pole - Single Throw Double Pole - Double Throw

DIP Switch Locking Switch

Figure 6
Switch Examples

(SPDT) switches, since the single arm is making contact in either position. We
see examples of such switches in figure 6.
In this lab, we will be using a DIP switch to assert our logic input states.
It's also important to remember that semiconductors - integrated circuits - are
delicate and static sensitive devices.
To use a DIP switch as a logic input, connect the switch as shown in figure 7.
Observe that we have a pull-up resistor shown. Such a resistor is used to ensure
that we never have an open input (nothing connected) to the circuit input when
the switch is in the open position.
When we start to study sequential circuit design in
Vcc
future labs, we will encounter some problems that are
10K
associated with mechanical switches and we will have
to use a single pole - double throw switch. But for circuit input
now, the setup as shown will be good enough.
Switch Closed - Logic 0
Switch Open - Logic 1

Figure 7
DIP Switch with Pull-Up Resistor
 The DIP switch we will be using in the lab has the same number of pins on
each side. Each switch connects the two terminals that are across from each other.
Depending on the position of the switch, the two terminals are either connected
(shorted) or disconnected (open circuit).
Using an LED as an Output Device Vcc

LED is an acronym for a Light-Emitting Diode. 330 ohms

An LED is a semiconductor device that emits light
+
(much like a light bulb) when the voltage applied at
the anode (+) is larger than (beyond a threshold) what -

is applied at the cathode (-). Under such conditions, a Logic 0

Figure 8
current will flow from the anode to the cathode. Driving an LED

We must regulate the amount of current that flows

into (yes, current actually flows in!) a logic gate by connecting a current-limiting
resistor. The value used is usually 330 ohm. Shown in figure 8 is one method for
connecting the LED to a TTL gate output.
LED's can be obtained in units or banks. We will be using an LED bank,
which is called a "LED Bargraph Display", as a set of indicators for this lab. The
anode on the bargraph displays is the side with the lettering.
To use LED's as indicators, active low circuitry should be used, meaning that
the LED will light up when the output from the circuit is at the "low" state.
Single In-Line Package (SIP) Resistors
For tasks such as pull-ups or termination, one often buys sets of resistors
in a single in-line package, or SIP. They come in various values and have various
interconnections.
A package containing n resistors has n+1 pins
where the extra pin is the supply voltage (or
sometimes, ground) connection. Internally, an 8-
pin, 7-resistor SIP has the schematic in figure 9
Vcc
(note the gray dot's position). Figure 9
Inside a SIP Resistor Package
Chip Pin-Numbering Convention
To standardize circuit-wiring applications, there
is a pin-numbering convention for IC chips. One
way of marking chips is shown in figure 10. 14 13 12 11 10 9 8 14 13 12 11 10 9 8

Notice that there is a small circle on one side but

not the other or round cut-away at the top. To the
left of that is pin number 1. Along that left side,
1 2 3 4 5 6 7 1 2 3 4 5 6 7
the pin numbers increment and wrap around the Figure 10
end without the cutaway (or the circle) until you DIP Package - Top View
With Pin Numbers
reach the pin opposite pin 1. DIP's usually come in packages of 14, 16, and 20
pins.
Usually, the pin opposite from pin 1 is the VCC (voltage supply) pin where a
+5V DC power supply is to be connected. Diagonally across that pin is the GND
(ground) pin. These two pins are placed as far from each other as possible to
prevent any accidental shorting between the two pins, which may damage the
whole chip in an instant.
Remember: when you wire up your circuit, always double-check the connections!
IC DIP Clip
When you are checking the voltage states of the pins of an IC, it is not a good
idea to touch the pins directly with a logic probe - it’s too easy to slip off and
short a couple of pins together. For the purpose, the DIP clip is available. It is
to be clamped over the entire circuit so that it is easier to probe.
"Bad" and "Burned-out" IC's
If an experimental or breadboarded circuit appears defective, the problem is
typically a bad or burned-out IC. Every other possibility should be exhausted
before an IC is replaced. The rule, and this is the hardest one in this lab to
learn, is simply: ALWAYS BLAME YOURSELF FIRST, THE IC LAST. If
you follow this rule, you will find that it saves you time (and money) later on.
Fundamental Rule of Debugging
Tearing a non-working circuit apart and rebuilding it will not yield one that
suddenly starts working. Learn to debug, not rebuild.
Working with Logic Gates
Let's now get started. Using an closed
V1
SN74LS04N, resistor, switch, and LED from I2
open 330 ohm
your lab kit, please build the circuit shown in I1
10 ohms
figure 11.
Figure 11
Place the switch into the closed position. Using Driving an LED

a voltmeter, measure and record the voltage drop

across the 10  resistor then using Ohm's law,
compute the value of the current i1.
 Using a voltmeter, measure and record the voltage drop across the 330 
resistor then using Ohm's law, compute the value of the current i2.
+5 VDC
Disconnect the LED and resistor from the circuit +5 VDC

and using a voltmeter, measure and record the value of 1.0 K

I3
I4 330 ohm
the voltage, V1. closed
V2
Now build the circuit shown in figure 12. open
Figure 12
Place the switch into the open position. Using Driving an LED

a voltmeter, measure and record the voltage drop

across the 1000  resistor then using Ohm's law, compute the value of the current
i3.
Using a voltmeter, measure and record the voltage drop across the 330 
resistor then using Ohm's law, compute the value of the current i4.
Disconnect the LED and resistor from the circuit and using a voltmeter,
measure and record the value of the voltage, V2.
Find the data sheet for the SN74LS04N.
 On the data sheet, find the values for IIL, IOH, IIH, and IOL.
 What are these values (IIL, IOH, IIH, and IOL) telling us?
 Compare these values from the data sheet with what you measured for I1,
I2, I3, and I4?
 On the data sheet, find the values for VOH and VOL.
 What are these values (VOH and VOL) telling us?
 Compare these values from the data sheet with what you measured for V1
and V2?
 Which configuration, that in figure 11 or that in figure 12, gave the
brighter LED display? Why?
Final Report
There is one report per team. The final report is to be typed and formatted
according to the guidelines specified for reports. Your report is due at the start of
the demo of your project.
The report must contain an itemized list for each team member identifying what
he or she contributed to the project. The list must be signed by the team member
attesting to the fact each of the items listed represents his or her own original work.
4. Assessment Plan:
 Performance Areas Performance Criteria Weighting Mark
1. Teamwork 10%
1.1 Clear roles for all team members 40%
1.2 Clear tasks and deliverables assigned to each 60%
member

2. Design and 50%

Implement
2.1 Develop a Verilog entry project in the 20%
Quartus environment
2.2 Figure out the input and outputs of system 40%
2.3 Verify the design meets all the requirements 40%
in the original specification

3. Written report 40%

3.1 Well-organized report structure as required 20%
3.2 Clear answers of all lab questions 40%
3.3 Detailed explanations 40%

APPENDIX A - Verilog Overview - The Verilog Hardware Description Language

What is Verilog?
Verilog is a hardware description language that provides a means of specifying
a digital system at a wide range of levels of abstraction. The language supports
the early conceptual stages of design with its behavioral level of abstraction, and
the later implementation stages with its structural level of abstraction. The
language provides hierarchical constructs, allowing the designer to control the
complexity of a description. Note: this description is an excerpt from the book
Verilog Hardware Description Language, by Thomas and Moorby.

How to use Verilog

In order to perform a digital circuit simulation using Verilog, you need to:
 Create a Verilog source file using a text editor
  Compile and simulate the source file
 Debug if necessary by looking at the simulation output

Some Concepts in a Verilog Source File

Case-sensitivity
Verilog is case sensitive. When you encounter an error while compiling a
Verilog source file, look for case-errors.
Modules
Verilog utilizes the concept of modules. Think of a module as a "black box".
To make a system consisting of modules, you would link up the individual
"black box" with "wires". The concept of module permits the building of
complex systems by linking lower-level designs, and provides a structure for
the design process.
The more modules you have, the more complicated the design becomes. In
such cases, it is convenient to be able to verify functionality module by
module. Here is a sample module declared in Verilog.
module module_name[(outputs_list, inputs_list)];
(declare inputs and outputs, as well as "regs" and
"wires")
(put necessary code here)
...
...
endmodule
The inputs_list and the outputs_list are optional, but you will use them most
of the time. The standard convention in Verilog is that the outputs_lis comes
before the inputs_list when the module is declared. For each item in the
inputs_list and the outputs_lis, the input and output declarations must be made
following the module declaration.
The syntax is as follow:
input inputs_list;
output outputs_list;
reg and wire declarations
These are the two types of "variables" in Verilog. In Verilog code, the value
of a reg (register) can be changed directly by an assignment (an assign
command is used), whereas the value of a wire can only be changed as a result
 of a gate or a behavioral statement driving it. These variables can be declared
as such:
reg reg_list;
wire wire_list;
The variable types reg and wire can also be formed into a bus such as:
reg [msb:lsb] reg_list;
wire [msb:lsb] wire_list;
where msb is the bit index of the most significant bit, and lsb is the bit index
of the least significant bit. Verilog can actually handle a reverse-ordered
notation, but it is better to follow a convention and stick to the traditional
method. The value of the lsb bit index needs to be zero always since bit
position 0 conventionally denotes the least-significant bit. This bus
specification can be extended to input and output lists.
Putting Together a Circuit - The Behavioral Model and The Gate-Level Model
Once you have declared your module and variables, you then need to define the
circuit. There are two ways to define a circuit. You can specify the gates and/or
other modules and all the interconnections in between. That is the gate-level
model. Instead, if you just want to see how a circuit would behave through a set
of equations and instructions, you can use the behavioral model. For the pre-lab,
you will be typing in only the gate-level structural model.
If you require a physical definition of your circuit right before producing a mask
for a production chip, and you need to make sure that the logic is correct, the
gate-level model should be used. However, if you simply want to prototype an
idea for a circuit just to see how it works and do not want to spend time verifying
interconnections, the behavioral model is preferred.
Simulation Time Keeping and Time Units
Since the analysis of circuit timing is such an important issue in the design of
digital circuits, Verilog has its own time-keeping units. It is not in any particular
time unit, but unit time in Verilog can be equated to, say, 10 nanoseconds (10 ns)
in real time. The idea is to run conceptual simulations on a circuit, so you are not
constrained by the ordinary time unit convention. If you have a clock running in
your source code, you can set one half-period of that clock to one time unit in
Verilog, as long as it is the smallest resolution of simulation time needed.
Using the time-keeping units provided in Verilog, we can assign propagation
delays to the gates and modules that are declared in a Verilog source code. The #
symbol functions as a delay assignment operator. Note, where ever the # symbol
 appears in the sample source file, you will type in the proper values for your
delay. Good coding style recommends using symbolic constants instead of what
are called magic numbers.
always and initial
These are two of the many keywords in Verilog which allow you to set stimuli
(user-set input conditions) to the module that you created. always pertains to
a continuous process, and initial pertains to a process that is initiated at start-
up .
Multiple always and initial statements can be put together to have a group of
events happening in a circuit.
These are behavioural statements. We can use these to model more complex
flow of control schemes.
$display and $monitor statements
Both of these statements allow you to see the states of certain signals in your
module in text form. The output is directed to the screen (or window). The
difference between the two statements is that $display only happens when it
is called, whereas $monitor shows the states only when there is a transition
in one or more of the signals that are specified. Here is the syntax:
$display (["string_format"], variable_list);
$monitor (["string_format"], variable_list);
The string_format is optional for both statements. You can format how the
variables will show up by using format fields (%b for binary, %d for decimal,
and %h for hexadecimal). As a convention, a logic "high" is denoted as a 1,
and logic "low" is denoted as a 0, and an unknown state is denoted as an x.
These state output statements must be placed within an always or initial
routine.
Graphical Output Display
The $display and $monitor statements provide ways to verify the behavior of
your digital design. However, looking at a stream of numbers and trying to decide
if your circuit is running correctly can be very tiresome. To make the circuit
verification (and debugging) process more intuitive, a handy waveform viewer is
available as part of the Verilogger simulation package. It allows you to do the
following:
 look at the specified signals, in single bits or busses, as waveforms
 zoom in and out of a time section of your waveform display
 use markers on signal transitions to analyze timing characteristics
 header is the title of the waveform printout,
 begin_time and end_time mark the boundaries of the simulation
portion that you want to print out.
Appendix B - Verilog Source File Example
A Verilog source comprises 3 major elements: a test bench, a collection of stimulus
and measurement modules, and a circuit or system that we are studying. That circuit
of system is made up of a number of logical components. A logical component may
be an atomic device like a logic gate or it may consist of a number of components
that may, in turn, be made up of logical devices. The stimulus module provides
signals into the UUT and the measurement module acquires the corresponding
outputs of the UUT.
As we see in Figure 11 below, a Verilog program is very much like a real electronic
bench with stimulus and measurement equipment connected to the circuit or system
we are studying - Unit Under Test (UUT). Like the real bench, the equipment is
connected to the UUT using wires.

test bench wires

stimulus
UUT
measure

Figure 11

Layout of a Verilog Program

On occasion, in a Verilog program, the stimulus and measurement may be in the

same software module.
Let’s look at a sample program:
/**************************************************************
* Title: Lab 1: Sample Verilog source code A Simple Comparator
* Model type: Gate level
* Description: This Verilog source code simulates all input conditions of a
lesseq than comparison
* Programmer: Your name
* Date: Date typed
**************************************************************/

module testBench;
// wires connect things together

wire lesseq, a, b, c, d;

Comparator myComp (lesseq, a, b, c, d)

TestModule myTester (a,b,c,d, lesseq);

endmodule

// text after a '//' on a line is considered a comment

// multiple line comments are enclosed by '/*' and '*/'

// Define the Comparator module

module Comparator(lesseq, a, b, c, d);

// within the modules, wires are implied…we can put them in if we want to

parameter delay = 2;
output lesseq; // Ouputs: lesseq
input a, b, c, d; // Inputs: to compare, ab
and cd

// We're building a gate level model... with propagation delay

// YOU DO NOT HAVE TO TYPE THESE COMMENT LINES.

// Gate instantiation format:

// name-of-module #(prop. delay) assigned-name (outputs-list, inputs_list)
 and #delay and1(term0, notC, notD);
and #delay and2(term1, a,b);
and #delay and3(term2, a, c, notD);
and #delay and4(term3, b, notC);
and #delay and5(term4, a, notC);

not #delay inv0(notC, c);

not #delay inv1(notD,d);

or #delay or1(lesseq, term0, term1, term2, term3, term4);

endmodule //close Comparator module

/**************************************************************
* Title: Lab 1: Sample Verilog source code A Simple Comparator
* Model type: Gate level
* Description: This Verilog source code simulates all input conditions of a
lesseq than comparison
* Programmer: Your name
* Date: Date typed
**************************************************************/
// text after a '//' on a line is considered a comment
// multiple line comments are enclosed by '/*' and '*/'

/**************************************************************
* Define the test bench module.
**************************************************************/

module testBench;
// wires connect things together
wire lesseq, a, b, c, d;

Comparator myComp (lesseq, a, b, c, d);

TestModule myTester (a,b,c,d, lesseq);

endmodule

/**************************************************************
* Define the Comparator module.
**************************************************************/

module Comparator(lesseq, a, b, c, d);

// within the modules, wires are implied…we can put them in if we want to

parameter delay = 10
output lesseq; // Ouputs: lesseq
input a, b c, d; // Inputs: to compare, ab
and cd

// This is a structural model

// We're building a gate level model... with propagation delay
 // YOU DO NOT HAVE TO TYPE THESE COMMENT LINES.

// Gate instantiation format:

// name-of-module #(prop. delay) assigned-name (outputs-list, inputs_list)

and #delay and1(term0, notC, notD);

and #delay and2(term1, a,b)
and #delay and3(term2, a, c, notD);
and #delay and4(term3, b, notC);
and #delay and5(term4, a, notC);

not #delay inv0(notC, c);

not #delay inv1(notD,d);

or #delay or1(lesseq, term0, term1, term2, term3, term4);

endmodule //close Comparator module

/**************************************************************
* Define the tester module.
**************************************************************/
module TestModule (a,b,c,d, lesseq); // declare test module
// Declare variables:

input lesseq; // Module inputs

output a, b, c, d; // Module outputs
parameter stimDelay = 15; // Delay between generating stimuli
reg a, b, c, d; // regs for setting values for checking
outputs
// a variable must be of type reg
in order to
// assign a value to it

initial // this initial block assigns

initializing
begin // values to the designated
variables
a = 0;
b = 0;
c = 0;
d = 0;
end

// run the simulation

// this block of code is run one time

initial // this initial block will apply the

test vectors

begin // begin initial loop

// * obtain graphical waveform output of signals
// * '$display("…"), simply displays the text that is between quotes to the screen.
// * '$monitor("…",..,..)' displays the variables stated to
// * the right of the quotes-using the format specified between the quotes.
// * Formats for . '$display and $monitor...
// * %b - binary digit output format
// * \t - tab (default: 5 spaces)
 // * $time - Verilog's automatic time keeper variable
// output states of signals to screen
// display the results in an output log

$display("CLOCK\t\t INPUTS \t\t OUTPUT\t\tTIME");

$display("--a-- \t --b--\t --c--\t--d--\t --lesseq--\t\t------");
$monitor(" %b \t %b \t %b \t %b \t\t %b" ,a,b,c,d,lesseq,$time);

// The following is our test code or test vectors.

// begin a second block to perform the simulation

repeat (2) // repeat this process twice for

illustration

begin // begin REPEAT loop

// we write in decimal and the compiler translates to binary

#stimDelay {a,b,c,d} = 0; // a=0, b=0, c=0, d=0
#stimDelay {a,b,c,d} = 1; // a=0, b=0, c=0, d=1
#stimDelay {a,b,c,d} = 2; // a=0, b=0, c=1, d=0
#stimDelay {a,b,c,d} = 3; // a=0, b=0, c=1, d=1

#stimDelay {a,b,c,d} = 4; // a=0, b=1, c=0, d=0

#stimDelay {a,b,c,d} = 5; // a=0, b=1, c=0, d=1
#stimDelay {a,b,c,d} = 6; // a=0, b=1, c=1, d=0
#stimDelay {a,b,c,d} = 7; // a=0, b=1, c=1, d=1

#stimDelay {a,b,c,d} = 8; // a=1, b=0, c=0, d=0

#stimDelay {a,b,c,d} = 9; // a=1, b=0, c=0, d=1
#stimDelay {a,b,c,d} = 10; // a=1, b=0, c=1, d=0
#stimDelay {a,b,c,d} = 11; // a=1, b=0, c=1, d=1

#stimDelay {a,b,c,d} = 12; // a=1, b=1, c=0, d=0

#stimDelay {a,b,c,d} = 13; // a=1, b=1, c=0, d=1
#stimDelay {a,b,c,d} = 14; // a=1, b=1, c=1, d=0
#stimDelay {a,b,c,d} = 15; // a=1, b=1, c=1, d=1
 end // close the REPEAT
loop

// the following code illustrates how we can test for aberrant conditions
// we use the specific SEQUENCE of events to cause a glitch - were there others

begin
$display("Producing Glitch");
#stimDelay {a,b,c,d} = 0; // a=0, b=0, c=0, d=0
#stimDelay {a,b,c,d} = 10; // a=1, b=0, c=1, d=0
end

#(2*stimDelay); // needed to see END of simulation

$stop; // temporarily stops simulation
// goto Verilog interactive mode
// need to type 1.1 or '$finish;'
$finish; // finish simulation

end // close second initial loop

endmodule // close test-module