Lab 7
How to Use Xilinx ISE 12 Project Navigator to Auto Generate a Testbench for performing
Simulations
Acknowledgements:
Developed by Craig Kief, Engineering Faculty at University of New Mexico, Albuquerque, New
Mexico. Funded by the National Science Foundation (NSF) under the ATE Program. This effort
was assisted by Qunlan Cao and Andrew Dodd.
Lab Summary:
The critical (and often most overlooked) part of any large VHDL FPGA project is the testing
phase. In the early days of student’s learning, they will often develop a project and then drop it
onto the hardware for testing. Although this is great when a student is beginning, it is
unacceptable in larger or more professional projects. When delivering commercial products, it
will be expected that complete and accurate simulations will have been accomplished (where
possible). The designer should always strive to write a module, test a module, write a module,
test a module and then, combine the modules into a system and test the system. An average
VHDL module should probably be no longer than a few hundred lines of code so writing an
exhaustive test bench should be possible. It is the vision of the author that an excellent starting
place for beginner engineers or technicians is in writing test benches for more advanced
engineers. Creating properly documented test benches will save a design team countless hours of
a very expensive senior engineer’s time.
Lab Goal:
The goal of this lab is to show the designer how to use the ISE wizard to create a test bench that
can be used to test modules in a larger system. At the end of the lab the designer should have
gained the skills necessary to be able to take any project of any size and begin to tackle the
process of testing it by creating the structure and files necessary for testing.
Learning Objectives
1. Understand the hierarchical “tree” structure of projects and their test modules.
2. Using the wizard, create a test bench for the modules.
3. Create a test bench for the system.
Method of Evaluation: Your grade will be determined by your instructor.
Time Required: 2 hours
Lab Preparation
Read this document completely first before actually accomplishing the lab. This
document was written by someone with many years of experience in this field and a
great deal of effort was put into hoping to impart this knowledge to those looking to
improve their skills.
Equipment and Materials
Access to Xilinx ISE software is all that is needed for this activity.
Software needed
The following items from the Xilinx: www.xilinx.com
 free software ISE WebPACK
Quantity
1
Additional References:
Xilinx ISE 12 Software manuals found on Xilinx web site: www.xilinx.com and hardware
manuals found at the Digilent Corporation’s website at www.digilentinc.com.
Lab Procedure
Introduction
On the website (http://www.cosmiac.org/Projects_FPGA.html) where you found this tutorial it is
also possible to find the file testbenchlab.zip file. Download and unzip this file (of source files)
onto your hard drive. Older versions of the Xilinx software had a serious problem with directory
names or file names that had spaces in them. To this day, older designers will religiously avoid
this practice. I would recommend unzipping the file into a directory called “Temp” or
“Xilinxlabs” or something similar. There is nothing special about this project. The code may not
even be that good. It was chosen due to its size and level of complexity. It is a good place to
start.
Procedure
Download the .zip file. The zip file contains three files. Two of the files are design files and one
file is the UCF file. Create a new project using the ISE software. Once this is done, right click
in the Design Section in the upper left corner of the ISE Design Suite. Choose the “add a copy
of the source” option and add the three files shown below.
2
It should look like the structure shown above. The important part about any project is the ability
to quickly look at the image shown above and make an analysis of what you see. In the case of
the image shown above, I can ascertain that the project contains three design files. I can also tell
that there is a parent child relationship that is involved. The file counter.vhd has two children
associated with the counter module. Those two children are the display_out module
(display_controller.vhd file) and the User Constraint File (counter4.ucf).
The next part of the project is the addition of the test benches. This is where it is important to
spend a few minutes discussing VHDL. VHDL is an IEEE standard. It was not created for
FPGAs. It was designed for other activities but it proved very useful to the FPGA community so
they incorporated it to do FPGA type work. In our world, there are two types of VHDL. The
first is synthesizable and the second is non synthesizable. The first can be used to actually
program an FPGA but the second one cannot. Synthesizable VHDL is often thought of as
something you can go to a parts store and purchase. You can purchase AND gates. Non
synthesizable VHDL is what is developed for testing. We create these files called test benches
for testing our synthesizable designs. Things such as “wait for 50 ns” are viable VHDL code
but it is impossible to buy a “50” nanoseconds in hardware. These are the things we use when
we create a VHDL test bench. Their function is never to actually go to hardware. Their
function is only to test the hardware design files.
It was the belief of the author that there would be a valid role for a technician or junior engineer
to be able to do the following steps of this procedure as a potential employment opportunity. A
senior engineer doing FPGA designs costs a great deal of money. The author envisioned that the
creation of test benches and generating the results for the senior engineer to evaluate would be an
excellent job for someone and a real cost savings for a company. Testing VHDL designs is an
art and skill but one that can be mastered. The first step to this mastery is in this tutorial.
3
Now it is time to create a test bench using the wizard. Right click in the design pane in the upper
left column and choose to add a new source. In the selection window shown above, choose
VHDL Test Bench. As a designer gains years and experience in VHDL and FPGA design, they
tend to create a directory of known good files. The intelligent way to proceed on this is to find a
way to quickly go into this directory and find the modules and their associated test bench. A
module should never be used until it has been fully tested and it should be a trivial effort to go
into a directory and pull out a module and its associated test bench. They should have virtually
the same name. In larger designs the process is to create a module and then test a module. The
first module to have the test bench created for it is the parent (counter). The file name is
counter.vhd. Thus, the test bench file name will be counter_tb.vhd. Note the addition of the
“_tb” to the end of the file name. This will make it easier for the designer to quickly tie the two
files together in a directory of 100 file names.
Next it is necessary to associate the newly assigned test bench name to the appropriate source.
The wizard will scan through the available sources and provide you with a list to choose from.
Since the title is counter_tb, choose the counter to be associated with. IF you click on the
“Simulation” button shown below, you will see all the files.
4
If the “Simulation” button is selected, it is now possible to see how the counter_tb file now
shows up with the counter child underneath it. The counter_tb file shell has been created but not
much of real value is in there. However, it is a great place to start.
This project has two modules. The first module (the parent) is called counter as shown above. It
has a child called display_out. The second test bench to be created is for the display module.
The file name for this module is called display_controller.vhd. Thus to make it easier, the name
that will be given to this test bench is display_controller_tb.vhd.
In the file name type in display_controller_tb in the file name block and proceed just as before
when creating the first test bench. Associate the new display controller with the display
controller module.
Click on the “Simulation” button again to see this shell. What will created next is the shell of
the display_controller_tb file as shown above. If the designer views the file structure below, it
is possible to be able to see that now the counter has a test bench file and the display controller
has a test bench file.
5
By looking at the counter_tb file, it is possible to see that the component declaration shows that
the module has three inputs (clk, reset and pause). Test benches are designed ONLY to
stimulate inputs so that the results of the developed circuitry (outputs) can be observed.
There are two types of simulations that can be run. The first is a Behavioral simulation. This is
where 90 percent of all simulations are performed. As a designer and hardware person, the fact
is that it takes a certain amount of time for signals to get from the input of an FPGA chip to the
output of a chip. We will call this time delta T. This delta T will be different for each chip and
each design. A behavioral simulation sets delta T to equal zero. It has the benefit of allowing
the designer to be able to run a sanity check on their design and look for flaws in their logic. The
second type of simulation is called a timing simulation. The timing simulation is only performed
after Synthesis and Implementation has been completed. This means the design has been placed
into the FPGA logic and then routed to the input and output pins. At this point, the ISE suite has
been able to accurately compute the delta T and knows exactly how long it takes to go from input
pins, through the internal logic and then to the output pins. Once this delta T is known, the
simulation can be run much more accurately. Timing simulations are often not run in
undergraduate courses but it is important for the designer to know that they exist and to
understand the difference between a behavioral and timing simulation. The same test bench can
be used to run both types of simulations.
6
For the counter stimulator, the author chose to make three processes (as shown above) that will
run at exactly the same time. This next part takes a little practice to get correct. Often if the
junior engineer can get to this point, the senior engineer can give them more precise timing based
on the final design of the module or system. As shown above, the author chose to create the
clock process to run a repeating clock at 10 nanosecods. The next process is for the reset. For
this process, the reset will be set to 1 initially. Then it will be kept there for a short period of
time. After 10 nanoseconds, it will be dropped and then kept low for the next 1000 nanoseconds.
This will allow the system to run a long time between resets. The last process is for pausing.
The pause signal is directed to remain low (by default) for 500 nanoseconds. It is then brought
high for a short period of time just to be able to observe what it will do.
These are not critical or rigid times shown above. They are only a starting place to begin to test
the design.
At this point, it is important to spend a few minutes to look into the counter code itself. This
counter runs off of the 50 MHz clock on the Digilent Nexys2 board. If the project were allowed
to run at the full 50 MHz then the digits would display to fast for the user to be able to see a
difference between them. To slow it down it is necessary to create an internal signal called
slow_clk as shown below.
7
This slow_clock is part of a clock divider signal. The clock_divider signal is a very big
counter/number. It has a most significant bit, a least significant bit and many bits in between.
When the program is running, the 21st bit is picked off and used to drive “slow_clock”. The
problem is that if the designer tries to run a simulation for the full time it will take to see the 21st
bit actually change, it would be necessary to run the simulation a massive amount of time. To
make this easier, the counter design file is changed as shown above so that the 4th bit is now used
for driving slow_clk. This allows a simulation to be performed for training. The only thing
that must be remembered is to return the design to its previous state after the simulation is
performed.
Save the simulation design file and then run the behavioral simulation on the test bench.
As can be seen on the simulation above, the counter is actually counting. This is the bare
minimum to do testing. In reality, a variety of different inputs would be chosen in an effort to
make the design fail. It is always better to get a design to fail in simulation rather than in
hardware when a customer is depending on it.
Next, it is time it go into the display unit and create the stimulus for it. In the display test bench
the first thing to do is to examine the component declaration.
8
By looking at the code (between lines 44 and 49) above it is possible to see that the display
controller has six inputs. It has a clock and a reset. It also has four four bit inputs that drive
each of the four seven segment digits up in the counter code. In theory, it is possible to create
much of the test bench for a design without actually fully understanding how the module or
system completely works. Often, if a designer is testing their own project, they miss things.
They tend to test for what they think they believe should happen. Although this is often good, it
sometimes blinds them to what can happen when the unexpected input occurs. For larger
organizations, the tester is often not the designer.
Just as before, a clock and reset signal are used. The times are set as shown above. They were
chosen with no critical time restriction or consideration. This is more about demonstrating the
procedure.
9
Next, the author chose to set the four four bit inputs for the hex digits as shown above. This is an
extremely terse and incomplete series of test stimulus but is good enough to actually prove the
proof of concept and to show the designer where to start. It is important to note the use of hex
values here as doing so properly will save typing time. This x”0” is the same as this “0000”.
Once the changes and additions are complete, the test bench is saved and the behavioral
simulation is run against that test bench. If your inputs show up as red or undefined in the
simulation, odds are that you are running the simulation against your design file and not with the
simulation file highlighted. This is a mistake you will only make a couple of times when first
starting.
10
After this is complete, the design can be saved and then the program file can be generated. It is
not possible or necessary to run a test against the UCF file. Download the project to the
NEXYS2 board and observe it counting. If it doesn’t count then make sure that the digits for
slow clock have been reset to their original values.
11